分享两个STM32应用中的实战案例

描述

前不久,几乎举国上下在同一时间段内整齐划一地被感染了新冠。

很多人感染后都不同程度地出现味觉、嗅觉失灵的情形。本人也有相同经历。这几天,味觉恢复,嗅觉也在慢慢恢复中。既能闻到诱人的煎饼香,也能闻到清新的花香了。

今天在此分享两个STM32应用中的实战案例,权作提醒,以免重蹈覆辙。

案例1:

系统联机工作时,Flash编程偶发性失败

有人使用STM32F4系列芯片做开发,代码里涉及到FLASH编程。他发现FLASH编程过程中时不时地出现编程错误,即提示HAL_FLASH_ERROR_PGP错误。

他的产品系统有用到CAN通信。当他不将芯片做系统联机工作时不会发生该错误,只有在做整体联机测试时才可能发生编程异常。

起初,客户使用4字节编程模式,平常单独就flash编程功能测试也正常,整体联机运行时才可能出问题。后来,无意中尝试将FLASH单次编程宽度调整为1个字节后则异常消失。

那是为什么呢?

定时器

其实,在做FLASH编程时,选择不同的编程宽度所需的芯片供电电压是不一样的。上面截图来自STM32F4系列参考手册。从图中不难看出,选择的编程宽度越宽,芯片所需供电电压越高。

若不运行其它功能,只是单独就芯片做flash编程,功耗需求相对较小、电源波动也小。当联机工作时,系统功耗、串扰都有所增大,电源波动也可能加剧,这时很可能出现电源难以保证支持4字节编程方式的稳定需求。由于单字节编程模式所需电源电压相对较低,在系统联机工作时,相同的电源条件下,即使电源有所波动,但完全可能依旧能提供满足单字节编程的稳定电压需求,因而不会出现因供电问题导致的编程异常。

案例 2:

芯片工作时偶发性出现死机现象

有人在做STM32芯片做产品开发,会偶发性地出现芯片进入死机状态的现象。

代码里有做FLASH编程操作,有UART的收发动作及相关中断,另外还开启了某定时器更新中断。经过测试发现,如果关闭定时器中断,FLASH编程、UART收发动作保持的情况下,则不会出现死机的现象。可是定时器中断怎么会导致芯片死机呢?感觉没有找到根本原因。后来,进一步跟踪调试发现,芯片出现死机,实际上是程序不停地进入UART接收中断。

用户代码里的确使能了UART收发中断,但在中断代码里程序实实在在有对接收非空标志【RXNE】做清零处理,不应该没完没了地进接收中断啊!经进一步确认,发生死机现象时总是对应着UART接收溢出事件【ORE】。哦,如果这样,当UART接收发生溢出时的确也会产生接收非空中断。下图为STM32USART的各个中断请求事件及中断使能控制位。从下图可以看出,当使能RXNEIE时,RXNE和ORE事件都可产生接收中断。

定时器

用户虽然在UART接收中断里有对RXNE标志清零,但当发生溢出事件而进入中断时,他并没有对ORE标志做检测及相应的清零操作。

定时器

实际上,用户根本就没有意识到发生ORE事件时也可以产生接收中断,在其代码里根本没有对ORE标志进行检测,更没有对ORE标志做清零,导致UART接收中断没完没了的进入,感觉芯片犹如死机一般。

为什么关闭定时器中断能防止死机现象发生呢? 我们知道,UART接收产生溢出是因为数据接收到后不能及时取走才产生的,而定时器中断的存在,因为中断竞争的原因导致了UART接收中断的及时性受到影响,进而容易发生溢出。如果关闭定时器中断或或将UART接收中断的优先级配置成可以抢占定时器中断就可以避免UART接收不及时的问题,也就不会发生溢出。这样的话,即使用户的UART接收中断里没有对ORE事件的处理也无所谓。

当然,我们做UART的中断接收时,中断代码里最好加上对ORE事件的检测处理,当发生溢出事件时,及时对ORE事件标志清零。否则,万一发生溢出,就可能因ORE事件而发生没完没了进中断的问题,进而导致功能异常。

具体到本案例,再顺便提醒一点,除非片内FLASH采用双BANK结构,FLASH编程也是会影响中断响应的。即该操作也可能让UART的接收中断的响应因临时堵塞而发生接收溢出。

好,今天的分享到此打住。也愿这里的分享能给有需要的人带来一些帮助。

目前尚是冬季,大家注意防寒保暖并保证休息,以利新冠康复。如有咳嗽,除了使用适当药剂外,尽量避免说话,尤其是高声说话。

待到山花烂漫、绿柳如烟时,魑魅魍魉尽遁去。九州华夏重抖擞,东方旭日耀寰宇。~~~~~~一起加油!~~~~~

审核编辑:汤梓红

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分