完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
问题： 文中配图引用自STM32F103的中文版本用户手册,下载链接为: 调研: 一、经过调研: 1.1 客户除了使用USART做串口通信，还开启了定时器中断来进行数据采集. 1.2 定时器的优先级比串口接收的优先级高. 1.3 定时器处理数据操作也比较频繁. 1.4 客户使用的STM32F1标准库(版本V3.5.0). 二、经过问题复现和使用ST-LINK在线调试和定位发现: 2.1 在出现这个问题的时候，程序不断的进入串口接收中断,不能够运行到main主函数处理其他任务了. 2.2 发现ORE标志为‘1’，也就说明程序是发生了串口溢出错误. 2.3 客户在进入串口中断后会调用USART_GetiTStatus(USART2, USART_IT_RXNE)来获取RXNE的值.如果RXNE为1则去读取DR数据寄存器的数据,读取后RXNE为0，但是ORE的标志依然为1,依然进入了串口中断. 三、经过分析以及我们可以通过我们芯片的用户手册可以得到以下信息: 3.1 程序不断进入串口中断是因为ORE标志始终为1,没有被用户清除掉: 从上图红色部分我们可以看到，如果串口接收中断开启了，那么ORE为1时就会产生中断. 3.2.从下图我们可以看到，顺序执行对USART_SR和USART_DR的操作就会清除ORE的标志,客户在中断中执行了以下操作，那为什么ORE标志还没有被清除呢?(R1执行了读USART_SR操作，R2执行了读USART_DR操作). 3.3 我们可以看手册中下表的解释: 3.3.1 ORE表征的是一个历史事件，当ORE为1时，表明至少有1个数据已经丢失. 3.3.2这有2种可能发生的情况,RXNE为1的情况R3和RXNE为0的情况R4,如下图中的解释. 3.3.3我们从上图可以看出，3.2图中的R1+R2操作只能处理RXNE为1的情况； 当RXNE为0的特殊情况, 就是在读序列器件(在USART_SR寄存器读访问和USART_DR读访问之间)接收到新的数据，数据SR虽然被读过了,但是overrun事件依然发生了，以上操作是不能够处理的： 3.4 因此我们要在应用中对ORE标志进行处理，即当判断发生ORE中断的时候，我们再读一次USART_DR的值，这样如果没有新的Overrun溢出事件发生的时候，ORE会被清除,然后程序就不会因为ORE未被清除一直不断的进入串口中断了,代码处理如下: 结论： 对于这种情况，我们可以看到USART串口接收中断使能了，那ORE中断也就开启了；为了消除在通过读序列(USART_SR/USART_DR)的过程中产生的溢出错误，我们可以尝试在应用程序中需要针对ORE标志做一个处理来清除ORE标志，使得串口通信可以正常的继续工作. 建议客户在做串口通信时需要增加帧检验功能，如CRC校验等...,当发生ORE时，帧校验肯定是通不过的，不会造成从机误响应. 
3
|
|
|
相关推荐
|
|
|
|
|
|
|
|
|
|
|
只有小组成员才能发言，加入小组>>
物联网工程师必备：怎么选择不同的无线连接技术，本指南帮你忙！
3262 浏览 1 评论
【DFRobot TinkerNode NB-IoT 物联网开发板试用连载】WIFI功能测试
3911 浏览 0 评论
【DFRobot TinkerNode NB-IoT 物联网开发板试用连载】Arduino的替代SublimeText3+STino
3419 浏览 0 评论
使用端口扩展器轻松高效地向IIoT端点添加具有成本效益的子节点
3968 浏览 1 评论
20608 浏览 11 评论
模组有时候复位重启后输出日志为“REBOOT_CAUSE_SECURITY_PMU_POWER_ON_RESET”的原因？
751浏览 2评论
939浏览 2评论
965浏览 1评论
1086浏览 1评论
362浏览 1评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
5369
淘帖
143
发表评论
赞
回复
