某STM32用户使用STM32F407芯片开发产品。用到内部3个ADC，其中ADC1与ADC2工作在ADC双模式，ADC3独立工作。运行代码时给FLASH开锁编程后，发现ADC3不工作了（其DR数据寄存器似乎不更新了，倒是用来触发ADC的定时器TIM2依然正常），Flash编程前后ADC3配置寄存器CR1、CR2没有发生改变。如果重新配置ADC3后就能正常工作。

从问题现象来看，初步感觉跟flash编程有些关系。

经了解，客户的确做了flash编程，有一部分参数需要存放在FLASH内。他的ADC3是由TIM2触发的，ADC3的转换结果是通过DMA搬运。

鉴于此，我这边便提醒他，如果不是基于双BANK条件，在flash编程时CPU是堵塞的，此时若发生中断不会得到响应,让他注意这点及因此可能导致的问题。

客户进一步反馈确认：

1：通ADC结果过DMA读取，并非中断方式获取；

2：FLASH编程过程中禁止了所有中断；

3：奇怪的是ADC3改为由软件触发则没有异常现象。用来触发ADC的定时器一直计数正常，并且只要重新配置ADC3（无须对触发定时器重新配置）也能恢复它的正常工作。

先说下客户提到的在flash编程时将总中断关闭动作。其实，从效果来讲，这个关中断没啥用，反正在Flash编程过程中即使有中断发生CPU也不会给予响应。

结合其反馈，软件触发和定时器触发ADC有个明显差别，就在于定时器的触发对于我们用户来讲往往存在些未知性或不确定性，即不知它具体的触发时间点。客户一直强调TIM工作保持正常，对ADC不能被触发感到奇怪。

整体上，通过问题症状结合经验初步判断是ADC3发生溢出事件了，建议客户做进一步检查确认。

后来，他反馈的确是发生了ADC溢出事件。在FLASH编程前暂停TIM2触发就可以避免溢出发生，不再发生ADC功能异常。

按理说他现在ADC结果是DMA传输，TIM触发DMA时应该可以及时读取数据的，怎么还发生了溢出呢？那就有种可能，在某个时刻，当ADC被TIM触发完成转换后，这时的DMA还没有准备好，导致ADC的结果没有被及时取走。

那什么原因会导致ADC结果不能被及时取走呢？若DMA配置在非循环模式，当DMA传输完成一轮数据后，DMA将不再继续实施数据传输，这时CPU往往还会进入DMA中断服务程序做些必要处理或者为下轮传输做准备。若这个DMA传输完成中断发生在FLASH编程期间，这就可能导致问题。由于该期间它本身不能得到响应，下一轮的DMA传输就没法被开启。但此时的TIM还是依然如故地触发ADC,其结果若不能被及时取走，导致溢出就再自然不过了。

当ADC发生溢出后，如果没有对溢出位做清零，后续的ADC转换动作是不会触发DMA的。具体到本案例，严格地讲，后来客户觉得读不到ADC的更新数据，不是因为ADC不工作，其实它一直被定时器触发转换，只是因为发生了溢出，没法正常触发DMA传输，进而无法实现ADC结果的搬运。

所以，在上述应用情况下，在做flash编程前可以先行关闭定时器，之后再打开。或者在DMA传输完成的中断服务程序里，在重新开启DMA之前，先暂时关闭定时器，对并ADC的溢出及出错做检测处理，之后再开启定时器和DMA传输。