1、背景

         前段时间在做一个CAN转USART的网关，使用的是STM32F412RET6，软件框架使用的是RT-Thread操作系统，主要外设资源使用了CAN1、CAN2、UART2、UART3，在做通信压力测试时，发现CPU程序运行卡死了，通过STM32 ST-LINK Utility工具，排查到了程序陷入死循环：串口轮询发送阻塞等待发送完成标志位，bad core如下如所示：

因排查了有些时间（代码白盒测试感觉已经查到头了），找不到根源，暂时加了超时机制措施，问题也暂时不复现了。

2、问题描述

         ① 串口发送完成标志位因为什么没有被置位?

3、排查过程简述

         问题表象为串口发送完成标志位未置位，所以认为主要的排查方向有：

① UART被关了

② UART配置被写坏了

③ UART时钟被关了

④ TC位被误清了

以上①~③点，在试验的是出现“卡死”现象时，使用了stlink读取了相应寄存器信息，很遗憾，都正常。

④点代码白盒走查，查到头了，也没有发现程序任何时序链路能够清除TC标志位。

4、补充

① 代码白盒走查，演绎程序时序链路，分析TC位置位情况，感觉是正常的，附TC位在发送时行为时序图：

② 在stm32 Errata sheett里有描述如下

有可疑点

○ 数据还在传输当中

是否硬件上有错误，有可能串口的发送移位寄存器往TX线上传送数据一直未完成？

○ 在数据传输过程中打断数据传送

误操作将发送失能？但是监控到关于串口寄存器相关是正常的。。。。
  另外，CAN会影响UART吗？（好像共用一个时钟源，芯片内部总线有无冲突导致TC不被置位？）

社区各位大佬，在开发过程中有无遇到类似的问题？有什么建议的排查方向？

ST的F4系列MCU出了差不多10年了，串口方面一直都在用，硬件应该没什么问题。 另外在时钟出错的可能性不大，发过来推测，时钟出错最多也是波特率变化或者外设停止。但实际上都没有看到。
同时在官方的库里看到对TC标志的判断就如同大家说的，用了超时判断，兼容性更强，建议楼主改成官方库的形式。

用USART+DMA试试啊

为了防止各种问题的发生，我在这里会有超时判断。因为系统现在有很多的中断处理，或者任务调度没有做好互斥后，导致同样的代码在重复执行。可以在操作的时候，增加一个互斥量，保证上一次操作完成后，再执行后面的操作。

yklstudent 发表于 2023-1-6 22:10
用USART+DMA试试啊

感谢回复，因为初期软件架构使用了libmodbus协议栈，其与硬件深度绑定，在初始化时就默认的将串口设置为中断接收轮询发送，如果要使用DMA模式，软件要改动较大。后续我会试试更为轻量级的agile_modbus协议栈+自己实现底层串口DMA。

废鱼 发表于 2023-1-7 09:34
为了防止各种问题的发生，我在这里会有超时判断。因为系统现在有很多的中断处理，或者任务调度没有做好互斥 ...

感谢回复，确实在系统层面中断和任务调度会引入未知风险，代码白盒走查演绎程序运行时序链路很难做到穷尽，您所说的互斥我理解为具体在主贴bad core展示的阻塞等待TC位，确实为一个临界资源，在此加入互斥量临界保护，我觉得软件实现比较困难（水平不够哈哈），所以还是参照了官方HAL库的阻塞发送超时机制，做了优化处理。

butterflyspring 发表于 2023-1-9 09:59
ST的F4系列MCU出了差不多10年了，串口方面一直都在用，硬件应该没什么问题。 另外在时钟出错的可能性不大， ...

感谢回复，主贴所说的超时机制，我也是查看官方HAL库里的形式，得到的暂时的解决方法。