2块板子是靠串口通信的，MCU为103RCT6，我们一个项目在做破坏性测试的时候，TXD,RXD短接起来，并且用一个USB转TTL以10ms速率一次发大几百，上千个数据，过几分钟最多十几分钟那块作为串口主机的那块板子就发不出数据了（DMA发送），我们用的HAL库1.8.4，软件排查下来是huart结构体有个gstate处于busy状态了，而理论上发送完成后进入串口中断就会置为ready，往上排查是不知什么原因是把TCIE（发送完成中断）关闭了导致无法置为ready，但是感觉没啥地方是关TCIE中断的，我把HAL库升级到1.8.6就好了，我想咨询下，对于我刚刚描述的问题，HAL库1.184，1.186两者之间串口优化了什么？怎么解决上述我出现的问题的？我需要和客户那边解释，谢谢！

这里的gstate状态量，当UART在通信时会被软件设置为busy，当通信完毕或基于特定事件会被配置为reset或ready，准备下次启用。


只要程序按照HAL库设计的逻辑流程运行一般是不会有啥状况的。如果说程序运行偶尔跑乱而没能及时重置gstate状态的话，是可能因为


gstate的busy而无法再次启用uart。


我这边也查看了HAL库1.8.6版本的相关更新记录，它的确有针对UART通信中因为OVR超时错误处理方面做了API的重新设计，之前版本


的API可能会在发生溢出错误时卡住，导致程序无法继续运行。换言之，通过重新设计API即使在遇到溢出错误时也能正确处理并继续运行，


从而提高了系统的稳定性与可靠性。结合到这里，API重新设计后之前可能出现的状态变量不能及时重置的，现在可以了。说得通俗点，就是


程序方面加强了应急处理，让运行更稳健。


你的代码，如果发送时检查到gstate若为busy，不妨给个超时，超时到了还不行，你完全可以在启动UART发送前手动将gstate改为ready,


至于你跟客户怎么解释，这个没什么。软件做些完善是很正常的事情，相信你可以解释。

xmshao 发表于 2025-3-20 09:26
这里的gstate状态量，当UART在通信时会被软件设置为busy，当通信完毕或基于特定事件会被配置为reset或ready ...

我也看了更新的，但是我们用的是dma发送，您上面提到的超时没有用dma的。我们的客户不好糊弄的，不是说我说1.8.4有漏洞，需要加个超时保护就好，我们要给他们解释前面的程序为什么会卡死，1.8.6的库为什么不会出了，改动的地方在哪，逻辑要分析的透透彻彻，清清楚楚，这问题才会翻篇的

小吃 发表于 2025-3-20 14:33
我也看了更新的，但是我们用的是dma发送，您上面提到的超时没有用dma的。我们的客户不好糊弄的，不是说我 ...

嗯 也是应该的。 这个可能要结合代码细看下， 相信可以找到原因。