|
STM32F103长时间运行,串口发送失败,目前定位到一致卡在USART_FLAG_TC判断那里,我们采用轮询的方式发送数据,然后判断USART_FLAG_TC是否发送成功,在大量发送后出现了一次发送后USART_FLAG_TC没有置位,然后就一直卡在这里了,这可如何是好? |
STM32CubeMX配置STM32F103C8T6 RTC分频器问题
请教STM32F103的DMA空闲接收问题
STM32F103VCT6通过串口1烧录程序问题
F103的IIC支持高速400K频率吗?
为什么用cubemax生成f103c8t6的freertos在编译时会报错
CUBEIDE打开一个工程,怎么改变主控芯片的同系列型号?
STM32F103 使用PA9输出PWM问题
STM32F103C8T6是否支持TIM3的PWM边沿触发AD采集
HAL_I2C_Mem_Read 一直返回 BUSY
STM32F103 class b 使用demo
微信公众号
手机版
定时喂狗?当USART_FLAG_TC置位后喂狗成功 超时不喂直接重启
嗯,目前只能这样,这个时间还不太好确定,太长会影响正常的连续性,太短会每次都就如,感觉字节与字节大发送间隔是ms级别的
我其实不喜欢用看门狗,直接重启的系统应用的连贯性损失太大
如果对串口发送的实时性要求不高 可以加一个error判断 进入error后打断此次循环/函数
但是这只是一个保险措施 还要找找其他原因,这个方案只能说是躲开了问题 但是没有解决
可以看一下是不是其他程序干扰到了 一点点把程序屏蔽掉
[md]这不现实啊,程序太多了,只能加个超时机制了
能接受其实也没问题,下次设计的时候预留那个error接口
这样就算有问题也可以计时处理