标题: USART 中断方式接收无响应问题的一种情况 及其处理方法 [打印本页]
作者: 小融1号 时间: 2016-9-29 11:54
标题: USART 中断方式接收无响应问题的一种情况 及其处理方法
问题:
此问题由客户工程师提出,客户在使用STM32F103的USART做串口通讯时,发现了一个问题,当设备正常通信一段时间后,串口不响应外部的通信请求了.
文中配图引用自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时,帧校验肯定是通不过的,不会造成从机误响应.
重要通知 - 请仔细阅读
意法半导体公司及其子公司(“ST”)保留随时对ST 产品和/ 或本文档进行变更、更正、增强、修改和改进的权利,恕不另行通知。买方订货之前应获取关于ST 产品的最新信息。ST 产品的销售依照订单确认时的相关ST 销售条款。
买方自行负责对ST 产品的选择和使用, ST 概不承担与应用协助或买方产品设计相关的任何责任。
ST 不对任何知识产权进行任何明示或默示的授权或许可。
转售的ST 产品如有不同于此处提供的信息的规定,将导致ST 针对该产品授予的任何保证失效。
ST 和ST 徽标是ST 的商标。所有其他产品或服务名称均为其各自所有者的财产。
本文档中的信息取代本文档所有早期版本中提供的信息。
文章来源:微信公众号 融创芯城(一站式电子元器件、PCB、PCBA购买服务平台,项目众包平台)
作者: yhy08090 时间: 2021-9-28 14:10
然后呢?贴就沉了啊
作者: yhy08090 时间: 2021-9-28 15:03
为什么就没有内容了呢,我现在遇到问题了
欢迎光临 (http://www.51hei.com/bbs/) |
Powered by Discuz! X3.1 |