iap15f2k61s2adc中断查询次序号

IAP15F2K61S2ADC是一款基于8051内核的单片机芯片。对于中断查询次序号，一般来说是指中断向量表中的位置序号。在IAP15F2K61S2ADC的中断向量表中，各中断源的中断查询次序号如下：

0：外部中断0（INT0） 1：定时器0中断 2：外部中断1（INT1） 3：定时器1中断 4：串口中断 5：看门狗定时器中断 6：ADC中断

当某个中断源产生中断信号时，芯片会根据该中断源对应的中断查询次序号到中断向量表中查询中断服务程序的入口地址搭顷。例如，当ADC中断发生时，芯片会根据中断查询次序号为6，在中断向量表中查询中断服务程序的入口地址。

需要注意的是，在编写中断服务程序时，需要参考芯片的数绝枝液据手册和相关开发工具的文档，确保对中断源和中断向量表的使用是正确的，并物以避免可能存在的潜在问题。

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传输。

---