今天在此分享两个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的接收中断的响应因临时堵塞而发生接收溢出。

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