文章分享了两个STM32开发中遇到的问题及解决方法：1)FLASH编程偶发性失败，原因是编程宽度与电源电压不匹配，调整为单字节编程解决了问题；2)芯片偶发性死机，是由于UART接收溢出中断未正确处理，优化中断代码和优先级配置可避免死机。
前不久，几乎举国上下在同一时间段内整齐划一地被感染了新冠。
很多人感染后都不同程度地出现味觉、嗅觉失灵的情形。本人也有相同经历。这几天，味觉恢复，嗅觉也在慢慢恢复中。既能闻到诱人的煎饼香，也能闻到清新的花香了。
今天在此分享两个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接收发生溢出时的确也会产生接收非空中断。下图为STM32 USART的各个中断请求事件及中断使能控制位。从下图可以看出，当使能RXNEIE时，RXNE和ORE事件都可产生接收中断。
用户虽然在UART接收中断里有对RXNE标志清零，但当发生溢出事件而进入中断时，他并没有对ORE标志做检测及相应的清零操作。
实际上，用户根本就没有意识到发生ORE事件时也可以产生接收中断，在其代码里根本没有对ORE标志进行检测，更没有对ORE标志做清零，导致UART接收中断没完没了的进入，感觉芯片犹如死机一般。
为什么关闭定时器中断能防止死机现象发生呢？ 我们知道，UART接收产生溢出是因为数据接收到后不能及时取走才产生的，而定时器中断的存在,因为中断竞争的原因导致了UART接收中断的及时性受到影响，进而容易发生溢出。如果关闭定时器中断或或将UART接收中断的优先级配置成可以抢占定时器中断就可以避免UART接收不及时的问题，也就不会发生溢出。这样的话，即使用户的UART接收中断里没有对ORE事件的处理也无所谓。
当然，我们做UART的中断接收时，中断代码里最好加上对ORE事件的检测处理,当发生溢出事件时，及时对ORE事件标志清零。否则,万一发生溢出，就可能因ORE事件而发生没完没了进中断的问题，进而导致功能异常。
具体到本案例，再顺便提醒一点，除非片内FLASH采用双BANK结构，FLASH编程也是会影响中断响应的。即该操作也可能让UART的接收中断的响应因临时堵塞而发生接收溢出。
好，今天的分享到此打住。也愿这里的分享能给有需要的人带来一些帮助。
目前尚是冬季，大家注意防寒保暖并保证休息,以利新冠康复。如有咳嗽，除了使用适当药剂外，尽量避免说话，尤其是高声说话。
待到山花烂漫、绿柳如烟时，魑魅魍魉尽遁去。九州华夏重抖擞，东方旭日耀寰宇。~~~~~~一起加油！~~~~~
*************************************
往期话题阅读链接：
扫一扫
718
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
