|
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不被置位?)
社区各位大佬,在开发过程中有无遇到类似的问题?有什么建议的排查方向?
|
如需获得 STM32F412RET6 等器件的更多信息,请点击链接或 点击此处 联系在线客服!
ST的F4系列MCU出了差不多10年了,串口方面一直都在用,硬件应该没什么问题。 另外在时钟出错的可能性不大,发过来推测,时钟出错最多也是波特率变化或者外设停止。但实际上都没有看到。 同时在官方的库里看到对TC标志的判断就如同大家说的,用了超时判断,兼容性更强,建议楼主改成官方库的形式。
用USART+DMA试试啊
为了防止各种问题的发生,我在这里会有超时判断。因为系统现在有很多的中断处理,或者任务调度没有做好互斥后,导致同样的代码在重复执行。可以在操作的时候,增加一个互斥量,保证上一次操作完成后,再执行后面的操作。
用USART+DMA试试啊
感谢回复,因为初期软件架构使用了libmodbus协议栈,其与硬件深度绑定,在初始化时就默认的将串口设置为中断接收轮询发送,如果要使用DMA模式,软件要改动较大。后续我会试试更为轻量级的agile_modbus协议栈+自己实现底层串口DMA。
为了防止各种问题的发生,我在这里会有超时判断。因为系统现在有很多的中断处理,或者任务调度没有做好互斥 ...
感谢回复,确实在系统层面中断和任务调度会引入未知风险,代码白盒走查演绎程序运行时序链路很难做到穷尽,您所说的互斥我理解为具体在主贴bad core展示的阻塞等待TC位,确实为一个临界资源,在此加入互斥量临界保护,我觉得软件实现比较困难(水平不够哈哈),所以还是参照了官方HAL库的阻塞发送超时机制,做了优化处理。
ST的F4系列MCU出了差不多10年了,串口方面一直都在用,硬件应该没什么问题。 另外在时钟出错的可能性不大, ...
感谢回复,主贴所说的超时机制,我也是查看官方HAL库里的形式,得到的暂时的解决方法。