STM32H743双FDCAN在RTX5下的并发通信架构与工程实践

1. 项目概述：为什么需要两路FDCAN同时工作？

在嵌入式开发，尤其是汽车电子、工业控制这些领域，CAN总线是连接各个节点的“神经系统”。传统的CAN控制器（bxCAN）在应对高速、大数据量的场景时，有时会显得力不从心。STM32H743这颗高性能MCU内置的FDCAN（Flexible Data-rate CAN）控制器，不仅兼容经典CAN，更支持最高5Mbps的仲裁段速率和最高8Mbps的数据段速率，带宽和效率都上了一个台阶。

但很多朋友在实际项目中会遇到一个更现实的需求：我需要同时使用两路FDCAN，并且它们都要稳定、高效地工作。比如，一路FDCAN1连接车内高速主干网（如动力总成），另一路FDCAN2连接车身舒适网络或诊断接口。这两路网络的数据流量、实时性要求、报文优先级可能完全不同。如果处理不好，轻则丢帧、延迟，重则总线错误、系统卡死。

更棘手的是，当系统复杂度提升，引入了RTOS（如RTX5）来管理多任务时，问题会变得更加立体。中断如何分配？任务优先级如何设定？消息队列和邮箱怎么用才不会成为瓶颈？这些都不是CubeMX点几下配置就能完全解决的，需要一套从硬件配置到软件架构的完整方案。

这个项目要解决的，就是如何在STM32H743上，借助CubeMX和RTX5，构建一个让两路FDCAN都能长期、稳定、高效并发工作的系统。这不是简单的“能通”，而是追求在复杂工况下的“可靠”与“高性能”。

2. 核心思路与架构设计

要让两路FDCAN在RTX5环境下和谐共处，核心矛盾在于资源竞争和实时性保障。我们不能让两路CAN的中断服务程序（ISR）互相阻塞，也不能让处理CAN报文的任务饿死其他关键任务。

2.1 总体架构：中断+任务+消息队列

经过多次项目迭代，我总结出一个比较稳健的架构，可以概括为“中断只做最紧急的事，任务负责繁重的处理”。

1. 中断层（ISR）：这是速度的保障。FDCAN的接收中断（Rx FIFO 0/1中断）和发送中断（Tx中断）优先级必须设置得当。当一帧报文到达时，ISR的核心工作只有三件：

   • 从FDCAN的接收FIFO中快速读取报文数据（ID、DLC、数据场）。
   • 将读取到的原始数据包（通常是一个结构体）放入对应的消息队列（Queue）中。
   • 清除中断标志位。绝对禁止在ISR中进行复杂的数据解析、大量的内存拷贝或调用可能阻塞的API（如osDelay）。ISR的执行时间要尽可能短。

2. 任务层（Thread）：这是逻辑的主体。我们为每一路FDCAN创建一个专用的处理任务（例如FDCAN1_Process_Task和FDCAN2_Process_Task）。这些任务在一个while(1)循环中，主要工作就是：

   • 阻塞式地从自己的消息队列中获取报文数据包。
   • 对报文进行解析、校验、业务逻辑处理。
   • 根据处理结果，可能需要组织新的报文，并通过另一个发送队列或直接调用发送函数进行回复。 任务的优先级需要仔细考量，通常高于普通应用任务，但低于关键的控制任务。

3. 通信层（Queue/Mailbox）：这是解耦的关键。消息队列是连接中断和任务的“管道”。它实现了数据的缓冲和异步通信，确保了即使某一瞬间报文爆发，ISR也能快速退出，任务可以按顺序处理，不会丢失数据。

这个架构的优势在于清晰的分层和职责分离，中断响应快，任务处理稳，系统可预测性强。

2.2 关键设计决策与取舍

• 为什么用队列（Queue）而不是邮箱（Mailbox）？邮箱更适合传递单个消息指针。而CAN报文往往需要传递一个包含ID、数据长度、数据内容的结构体。队列可以缓冲多个这样的结构体实例，在报文突发时提供更好的缓冲能力，防止丢帧。对于CAN通信这种可能产生连续多帧的场景，队列是更合适的选择。

• 两路FDCAN的中断优先级如何设置？这是一个需要结合具体应用场景的问题。基本原则是：实时性要求更高的那一路，中断优先级设置得更高。例如，FDCAN1用于电机控制指令，要求极低的延迟，那么它的接收中断优先级应设为最高（如抢占优先级0）。FDCAN2用于参数配置，延迟要求稍低，优先级可以设低一点（如抢占优先级1）。

  注意：确保两路FDCAN的中断不要拥有相同的抢占优先级和子优先级，否则可能引发不可预期的行为。同时，FDCAN中断的优先级应高于其处理任务的优先级，以保证中断能及时唤醒任务。

• 任务优先级与堆栈大小估算FDCAN处理任务的优先级应设置为“高于普通任务，低于最关键的硬实时任务”。例如，系统中有电机PID控制任务（优先级osPriorityHigh），那么FDCAN处理任务可以设为osPriorityAboveNormal。 堆栈大小需要实际测试。一个粗略的估算方法是：任务函数局部变量 + RTOS任务控制块开销 + 函数调用深度。对于CAN报文处理任务，建议初始值设为512字（对于ARM Cortex-M7，1字=4字节，即2KB）。然后通过RTX5的运行时堆栈分析工具（如svcEvent事件）来观察实际使用量，并留出50%左右的余量。

3. CubeMX工程配置详解

理论说再多，不如动手配一遍。下面我们一步步在CubeMX中搭建这个双FDCAN+RTX5的工程骨架。

3.1 时钟树配置：性能的基石

STM32H743最高主频可达480MHz（通过锁相环PLL）。FDCAN的时钟来源于hclk（AHB总线时钟）。为了达到较高的通信速率，需要保证核心时钟稳定且高速。

1. 在Clock Configuration标签页，选择时钟源（通常用外部晶振HSE）。
2. 配置PLL，将系统时钟（sysclk）推到400MHz或480MHz。这会同步提升hclk。
3. 找到FDCAN Clock Source，它通常由PLL1_Q或PLL2_Q分频而来。确保FDCAN的时钟源频率在配置波特率时，能计算出精确的分频值。例如，如果FDCAN时钟源是100MHz，要配置1Mbps的仲裁段波特率，那么分频值就是100。

3.2 FDCAN1与FDCAN2参数独立配置

在Pinout & Configuration标签页，找到FDCAN1和FDCAN2。

• Mode：都选择Activated。
• Parameter Settings：
  • Nominal Bit Rate（仲裁段波特率）：根据你的网络要求设置，如500Kbps, 1Mbps。
  • Data Bit Rate（数据段波特率）：仅在启用CAN FD模式时配置，且必须大于等于仲裁段波特率。如果只用经典CAN，此项不生效。
  • Nominal Sync Jump Width：通常设为1。
  • Nominal Time Seg1和Nominal Time Seg2：这两个参数与采样点有关。对于1Mbps，一个常见的配置是Time Seg1 = 13,Time Seg2 = 2，采样点约在87.5%。你可以使用像CANHacker或PCAN-View附带的位时间计算器来精确计算。
  • Frame Format：选择Classic CAN或CAN FD。如果选FD，务必确认对端设备也支持FD。
• NVIC Settings：
  • 勾选FDCAN1 Interrupt和FDCAN2 Interrupt。
  • 配置它们的抢占优先级（Preemption Priority）。如前所述，将更关键的一路（如FDCAN1）设为更高的优先级（数字更小）。

3.3 RTX5（CMSIS-RTOS2）的集成与配置

在Middleware分类下，找到FREERTOS，将其改为CMSIS-RTOS2 (API v2)，这其实就是RTX5的CubeMX接口。

• Configuration：
  • Global Dynamic Memory size：这是RTX5的堆空间，所有任务、队列、信号量的动态内存都从这里分配。对于双FDCAN加若干应用任务的系统，建议初始设置为32768字节（32KB）。如果后续创建对象失败，再适当调大。
  • Default Task Stack size：默认任务栈大小，可以保持128字。
  • SysTick Timer frequency：系统节拍定时器频率，保持1000Hz（1ms心跳）即可，兼顾了响应速度和功耗。
• Tasks and Queues： 我们暂时不在CubeMX里创建任务和队列，因为CubeMX生成的代码结构有时不够灵活。我们更倾向于在main.c或单独的文件中，用纯代码的方式创建，这样对资源的控制力更强。

3.4 GPIO与引脚分配

根据你的硬件原理图，在FDCAN1和FDCAN2的引脚配置中，分别指定RX和TX引脚。例如：

• FDCAN1:PB8->CAN1_RX,PB9->CAN1_TX
• FDCAN2:PB5->CAN2_RX,PB6->CAN2_TX

重要提示：STM32H743的FDCAN引脚通常有重映射功能。如果默认引脚被占用，记得在Alternate列选择正确的复用功能（如AF9for FDCAN1）。

完成以上配置后，点击Generate Code生成工程。接下来，才是真正体现方案的“软件部分”。

4. 软件实现：从驱动到应用

CubeMX生成了硬件和RTOS的初始化代码，但核心的通信逻辑需要我们亲手搭建。

4.1 定义统一的数据结构

首先，在main.h或一个独立的头文件（如can_comm.h）中定义报文结构体和队列句柄。

// can_comm.h #ifndef __CAN_COMM_H #define __CAN_COMM_H #include "main.h" #include "cmsis_os2.h" // CAN报文结构体 typedef struct { uint32_t id; // 标准ID或扩展ID uint32_t id_type; // 标识符类型：FDCAN_STANDARD_ID 或 FDCAN_EXTENDED_ID uint32_t frame_type;// 帧类型：FDCAN_DATA_FRAME 或 FDCAN_REMOTE_FRAME uint8_t data[64]; // CAN FD支持最多64字节数据 uint8_t dlc; // 数据长度码 } CanRxMsg_t; // 声明全局队列句柄 extern osMessageQueueId_t can1_rx_queue; extern osMessageQueueId_t can2_rx_queue; extern osMessageQueueId_t can1_tx_queue; // 如果需要异步发送，也可以创建发送队列 extern osMessageQueueId_t can2_tx_queue; // 函数声明 void FDCAN1_Init_User(void); void FDCAN2_Init_User(void); void StartFDCANTasks(void *argument); #endif

4.2 初始化与启动：超越CubeMX的生成代码

CubeMX生成的MX_FDCAN1_Init()函数只完成了最基础的配置。我们通常需要在其后调用自己的初始化函数，进行更精细的设置，比如配置过滤器、启动中断和CAN控制器。

在main.c的/* USER CODE BEGIN 2 */区域：

/* USER CODE BEGIN 2 */ // 初始化FDCAN外设（用户自定义部分） FDCAN1_Init_User(); FDCAN2_Init_User(); // 创建消息队列 // 队列深度需要根据报文流量评估，这里设为32，每个元素大小是CanRxMsg_t can1_rx_queue = osMessageQueueNew(32, sizeof(CanRxMsg_t), NULL); can2_rx_queue = osMessageQueueNew(32, sizeof(CanRxMsg_t), NULL); can1_tx_queue = osMessageQueueNew(16, sizeof(CanRxMsg_t), NULL); // 发送队列可以小一些 can2_tx_queue = osMessageQueueNew(16, sizeof(CanRxMsg_t), NULL); // 创建FDCAN处理任务 const osThreadAttr_t fdcan_task_attr = { .name = "FDCAN_Processor", .stack_size = 1024 * 4, // 4KB 堆栈 .priority = osPriorityAboveNormal, }; osThreadNew(StartFDCANTasks, NULL, &fdcan_task_attr); /* USER CODE END 2 */

然后，在fdcan_user.c中实现FDCAN1_Init_User：

// fdcan_user.c #include "can_comm.h" osMessageQueueId_t can1_rx_queue; osMessageQueueId_t can2_rx_queue; osMessageQueueId_t can1_tx_queue; osMessageQueueId_t can2_tx_queue; void FDCAN1_Init_User(void) { FDCAN_FilterTypeDef sFilterConfig; // 1. 配置过滤器：接收所有标准帧和扩展帧 sFilterConfig.IdType = FDCAN_STANDARD_ID; sFilterConfig.FilterIndex = 0; // 使用过滤器0 sFilterConfig.FilterType = FDCAN_FILTER_MASK; sFilterConfig.FilterConfig = FDCAN_FILTER_TO_RXFIFO0; // 过滤到的报文放入RX FIFO 0 sFilterConfig.FilterID1 = 0x000; // ID sFilterConfig.FilterID2 = 0x000; // 掩码：0x000表示全接收 if (HAL_FDCAN_ConfigFilter(&hfdcan1, &sFilterConfig) != HAL_OK) { Error_Handler(); } // 也可以为扩展帧配置另一个过滤器... sFilterConfig.IdType = FDCAN_EXTENDED_ID; sFilterConfig.FilterIndex = 1; sFilterConfig.FilterID1 = 0x00000000; sFilterConfig.FilterID2 = 0x00000000; if (HAL_FDCAN_ConfigFilter(&hfdcan1, &sFilterConfig) != HAL_OK) { Error_Handler(); } // 2. 配置FIFO水位线中断：当FIFO中有1个报文时产生中断 if (HAL_FDCAN_ConfigFifoWatermark(&hfdcan1, FDCAN_CFG_RX_FIFO0, 1) != HAL_OK) { Error_Handler(); } // 3. 激活FIFO中断和错误中断 if (HAL_FDCAN_ActivateNotification(&hfdcan1, FDCAN_IT_RX_FIFO0_NEW_MESSAGE | FDCAN_IT_BUS_OFF | FDCAN_IT_ERROR_WARNING | FDCAN_IT_ERROR_PASSIVE, 0) != HAL_OK) { Error_Handler(); } // 4. 启动FDCAN控制器 if (HAL_FDCAN_Start(&hfdcan1) != HAL_OK) { Error_Handler(); } }

FDCAN2_Init_User函数与之类似，只需将&hfdcan1替换为&hfdcan2。

4.3 中断服务程序：快进快出

CubeMX已经为我们生成了中断服务函数FDCAN1_IT0_IRQHandler和FDCAN2_IT0_IRQHandler，并在其中调用了HAL_FDCAN_IRQHandler。我们需要在stm32h7xx_it.c中找到这些函数，并添加我们自己的回调处理。

更优雅的方式是利用HAL库的回调机制。在main.c的初始化部分，重写接收完成回调函数：

/* USER CODE BEGIN 4 */ // FDCAN1 接收FIFO0回调函数 void HAL_FDCAN_RxFifo0Callback(FDCAN_HandleTypeDef *hfdcan, uint32_t RxFifo0ITs) { CanRxMsg_t rx_msg; FDCAN_RxHeaderTypeDef rx_header; uint8_t rx_data[64]; if((RxFifo0ITs & FDCAN_IT_RX_FIFO0_NEW_MESSAGE) != RESET) { // 从FIFO0读取报文头和数据 if(HAL_FDCAN_GetRxMessage(hfdcan, FDCAN_RX_FIFO0, &rx_header, rx_data) == HAL_OK) { // 填充自定义结构体 rx_msg.id = rx_header.Identifier; rx_msg.id_type = rx_header.IdType; rx_msg.frame_type = rx_header.RxFrameType; rx_msg.dlc = rx_header.DataLength; memcpy(rx_msg.data, rx_data, rx_msg.dlc); // 根据是哪个FDCAN，放入对应的队列 if(hfdcan->Instance == FDCAN1) { // 放入队列，如果队列满则等待最多10个时钟节拍 osMessageQueuePut(can1_rx_queue, &rx_msg, 0, 10); } else if(hfdcan->Instance == FDCAN2) { osMessageQueuePut(can2_rx_queue, &rx_msg, 0, 10); } } } } /* USER CODE END 4 */

这个回调函数由HAL库在中断上下文中调用。注意，osMessageQueuePut的最后一个参数timeout我设置为了10个tick。这是一个非常重要的细节：如果队列已满，ISR不能无限等待，必须设置一个超时。如果超时，意味着下游任务处理太慢或队列深度不足，此时可以选择丢弃该帧报文（通过检查返回值），并记录错误，这比导致整个ISR阻塞、系统崩溃要好得多。

4.4 任务处理函数：业务逻辑的核心

这是整个架构的“消费者”。我们创建一个任务，内部通过两个无限循环分别处理两路CAN的队列，也可以创建两个独立任务。

// fdcan_task.c #include "can_comm.h" void StartFDCANTasks(void *argument) { CanRxMsg_t rx_msg; osStatus_t status; for(;;) { // 处理FDCAN1队列 status = osMessageQueueGet(can1_rx_queue, &rx_msg, NULL, 0); // 非阻塞获取 if(status == osOK) { Process_FDCAN1_Msg(&rx_msg); } // 处理FDCAN2队列 status = osMessageQueueGet(can2_rx_queue, &rx_msg, NULL, 0); if(status == osOK) { Process_FDCAN2_Msg(&rx_msg); } // 短暂让出CPU，防止空循环占用所有资源 osDelay(1); } } // 具体的报文处理函数示例 static void Process_FDCAN1_Msg(CanRxMsg_t *msg) { // 这里实现FDCAN1报文的业务逻辑 // 例如：解析ID，根据ID执行不同操作 switch(msg->id) { case 0x100: // 电机转速指令 // 解析数据，更新电机控制变量 break; case 0x200: // 系统状态查询 // 组织回复报文，并调用发送函数 Send_FDCAN1_Response(0x201, system_status_data, 8); break; default: // 未知ID处理 break; } } static void Process_FDCAN2_Msg(CanRxMsg_t *msg) { // FDCAN2的报文处理逻辑，可能与FDCAN1完全不同 // 例如：处理诊断请求、车身控制信号等 } // 发送函数示例（同步发送，简单场景用） uint32_t Send_FDCAN1_Response(uint32_t id, uint8_t *data, uint8_t dlc) { FDCAN_TxHeaderTypeDef tx_header; tx_header.Identifier = id; tx_header.IdType = FDCAN_STANDARD_ID; tx_header.TxFrameType = FDCAN_DATA_FRAME; tx_header.DataLength = dlc << 16; // 转换DLC为寄存器格式 tx_header.ErrorStateIndicator = FDCAN_ESI_ACTIVE; tx_header.BitRateSwitch = FDCAN_BRS_OFF; // 经典CAN模式 tx_header.FDFormat = FDCAN_CLASSIC_CAN; tx_header.TxEventFifoControl = FDCAN_NO_TX_EVENTS; tx_header.MessageMarker = 0; // 使用HAL库发送，注意这个函数可能阻塞（直到发送邮箱有空闲） if(HAL_FDCAN_AddMessageToTxFifoQ(&hfdcan1, &tx_header, data) != HAL_OK) { return HAL_ERROR; } return HAL_OK; }

对于发送，如果系统中有多个任务需要发送CAN报文，或者发送频率很高，为了避免在发送函数中阻塞，可以引入发送队列和专用的发送任务，架构会更清晰。

5. 性能调优与稳定性保障

让两路CAN跑起来只是第一步，让它们在高负载下稳定、高效地运行才是挑战。

5.1 中断与任务优先级的精细调整

之前我们粗略地设置了中断和任务的优先级。在实际压力测试中，你需要观察：

• 系统延迟：使用GPIO翻转和逻辑分析仪，测量从报文进入RX引脚到任务开始处理的时间。
• 丢帧率：在总线持续高负载（如80%以上）时，统计发送和接收的报文数量。

如果发现FDCAN1的报文处理延迟过大，可以：

1. 进一步提高FDCAN1_IT0_IRQn的中断抢占优先级。
2. 提高FDCAN1_Process_Task的任务优先级。
3. 检查Process_FDCAN1_Msg函数内部是否有耗时操作（如浮点运算、大量内存拷贝），将其优化或移到低优先级任务中。

5.2 内存管理与队列深度

• 队列深度：osMessageQueueNew的第一个参数。深度设置太小，在报文突发时容易丢帧；设置太大，浪费内存。可以通过监控队列的使用率（osMessageQueueGetCount/osMessageQueueGetCapacity）来动态调整。一个经验值是：按照总线在最大负载下，任务最长处理周期内可能积累的报文数来设定，并乘以一个安全系数（如1.5）。
• 堆栈溢出：这是RTOS系统最隐蔽的杀手。务必使用RTX5提供的调试功能，例如在RTX_Config.h中启用OS_DEBUG_EVR（事件记录器），然后通过Event Recorder工具查看任务堆栈的最大使用量。确保实际使用量不超过分配大小的80%。

5.3 错误处理与总线恢复

工业环境复杂，总线可能遇到短路、开路、强干扰等问题。FDCAN控制器有丰富的错误状态指示（Error Passive, Bus Off等）。我们必须处理这些错误，尝试恢复。

在中断回调中，我们只处理了接收中断。实际上，错误中断同样重要。我们需要扩展回调函数：

void HAL_FDCAN_ErrorCallback(FDCAN_HandleTypeDef *hfdcan) { uint32_t error_status = HAL_FDCAN_GetError(hfdcan); if(error_status & FDCAN_IR_BUS_OFF) { // 总线关闭状态，最严重的错误 // 1. 记录日志 // 2. 尝试自动恢复：执行HAL_FDCAN_ResetErrorCounters和HAL_FDCAN_Start if(HAL_FDCAN_ResetErrorCounters(hfdcan) == HAL_OK) { // 等待一段时间（如100ms） osDelay(100); if(HAL_FDCAN_Start(hfdcan) != HAL_OK) { // 恢复失败，需要更高级别的故障处理 System_Enter_Safe_Mode(); } } } else if(error_status & FDCAN_IR_ERROR_PASSIVE) { // 错误被动状态，发送能力受限 // 记录警告，但通常可以继续运行 Log_Warning("FDCAN%d Entered Error Passive State", (hfdcan->Instance==FDCAN1)?1:2); } else if(error_status & FDCAN_IR_ERROR_WARNING) { // 错误警告状态，收发错误计数器较高 // 记录信息，提示可能存在问题 Log_Info("FDCAN%d Error Counters High", (hfdcan->Instance==FDCAN1)?1:2); } }

6. 实测踩坑与经验实录

纸上得来终觉浅，这套方案是我在多个车载控制器项目上踩了无数坑才总结出来的。分享几个最典型的：

坑一：FDCAN时钟源配置错误导致波特率不准

• 现象：通信不稳定，偶尔能收到数据，大部分时间错误帧很多。
• 排查：用示波器测量CAN波形，发现位时间宽度和计算值对不上。
• 根源：CubeMX时钟树配置中，FDCAN的时钟源（fdcan_ker_ck）选择错误，或者PLL分频系数计算有误，导致实际输入给FDCAN的时钟频率不是预设值。
• 解决：在Clock Configuration界面，仔细检查FDCAN Clock Mux的来源，并使用STM32CubeMX自带的位时间计算器或手动验算：Nominal Baud Rate = fdcan_ker_ck / (NominalPrescaler * (NominalTimeSeg1 + NominalTimeSeg2 + 1))。

坑二：中断优先级嵌套导致系统卡死

• 现象：当两路CAN同时有大量数据涌入时，系统偶尔会完全死机。
• 排查：使用调试器暂停程序，发现程序卡在某个中断或调度器里。
• 根源：FDCAN中断的优先级设置高于SysTick中断（RTOS的心跳）。当FDCAN中断服务程序执行时间过长，阻塞了SysTick中断，导致RTOS的时间片无法正常推进，任务调度停滞。
• 解决：遵循原则：SysTick中断的优先级必须设为最高（数字最小）。在CubeMX的NVIC Configuration中，将SysTick的抢占优先级设为0。然后将FDCAN1和FDCAN2的中断优先级设为1和2。确保所有中断服务程序的执行时间尽可能短。

坑三：队列溢出导致最新数据被覆盖

• 现象：在连续高速接收时，发现收到的报文序列号不连续，中间有丢失，但总线分析仪显示对方确实发送了。
• 排查：在osMessageQueuePut后检查返回值，发现有时返回osErrorResource（超时）或osErrorNoMemory（队列满）。
• 根源：处理任务被更高优先级的任务长时间抢占，或者Process_FDCANx_Msg函数本身处理太慢，导致消费速度跟不上生产速度，队列被填满。ISR中osMessageQueuePut超时后，新报文被丢弃。
• 解决：
  1. 增加队列深度：这是最直接的方法，但会消耗更多内存。
  2. 优化处理任务：提高其优先级，确保它能及时被调度；简化Process_FDCANx_Msg函数，将非实时性的处理（如数据存储、上传）拆分到更低优先级的任务中。
  3. 使用多个队列：可以为高优先级的报文（如ID小的）单独设立一个队列，并让处理任务优先处理这个队列，保证关键报文不丢失。

坑四：DMA发送配置不当导致发送阻塞

• 现象：调用HAL_FDCAN_AddMessageToTxFifoQ后，函数长时间不返回。
• 根源：FDCAN的发送FIFO只有3个邮箱。如果连续快速调用发送函数，当3个邮箱都占满后，函数会等待直到有空闲邮箱。如果总线负载很高或对方不回复ACK，等待时间会很长。
• 解决：
  1. 检查返回值并处理：在非关键线程中调用发送函数时，可以考虑使用带超时的版本（如果有）或先检查状态HAL_FDCAN_GetTxFifoFreeLevel。
  2. 启用发送完成中断：配置FDCAN_IT_TX_COMPLETE中断，在中断回调中释放信号量或通知任务，实现非阻塞发送。这才是更专业的做法。结合发送队列和专用发送任务，发送任务在队列中取报文，尝试发送，如果邮箱满则等待发送完成信号量，这样整个发送流程就是完全异步和非阻塞的。

最后，调试双FDCAN系统，一个CAN总线分析仪（如PCAN-USB, ZLG CAN卡）是必不可少的。用它来监控总线上的真实数据，对比发送和接收，是定位问题最快的方式。同时，善用STM32H743的ITM（Instrumentation Trace Macrocell）和Event Recorder来输出调试信息，可以让你在不干扰实时性的情况下，洞察系统内部的运行状态。