如题所述：
STM8S设置成活跃停机模式，使用红外下降沿唤醒并解码，IO具体配置为，PC4浮空输入，外部上拉，下降沿触发。
8M外部晶振，TIM2 32分频 2us时基 无溢出中断，用于两个下降沿之间的时间计数，正常的话前导码13.5ms,逻辑1
2.25ms,逻辑0 1.12ms

问题描述：
未进入活跃停机之前，红外中断触发正常，如图接收32bit红外码（忽略第一个数据），码值是0x0202d02f

之后，进入活跃停机后，再按下遥控，除了唤醒的第一个中断外，其余中断都变的不正常，
完全不匹配红外的时间间隔，时间间隔貌似大了十倍，如图是halt()后，用红外唤醒的中断间隔数据

软件描述：
软件的处理比较简单，以验证为主，上电后awu_flag为真就进入活跃停机状态，进入前关闭无关中断，把系统时钟切换到内部HSI，2分频 8M,等待遥控唤醒，如果解析按键成功，awu_falg置1，又进入休眠。

红外的IO下降沿中断主要就是对下降沿的时间进行计数，对每个计数的结果保存到数组里观察，解析过程冗长就不粘贴上来了。现象是halt()后第一次按下遥控，无法正确接收到数据,这时候已经被唤醒了，之后再次按下，正常接收到32bit数据，只有第一次唤醒的时候无法正确接收。

目前通过前面的这些数据得出的推论是，唤醒后MCU的中断会工作异常,是否有我不熟悉的内核内幕，我试过使用TLI做为红外中断，得到的结果也是类似，唤醒后会有快速的几个中断响应，跟红外的波形完全对不上，不知是否有这方面的前辈提点一二，甚是感激。

halt()后接收到中断间隔数据如0x15f4,0xbd3e之类的是红外的重复码的前导码，和两个重复码之间的空白间隔，分别是11.25ms和98.75ms,说明halt()后的这次红外信号的前导码和整个客户码数据码都丢失了。。。。
就算唤醒时间长达1ms也不应该出现这种状况，难道真是MCU的内核问题。。。也没个手册啥的可以参考啊

自己给他顶一顶

建议检查一下，HAIL 唤醒后执行中断时，STM8的时钟是否需要恢复成HALT前的。一般恢复时钟是需要一定时间的，所以这时候如果计算时间会不准的