2016-02-13 11:03 AM
Hi,
I recently faced this issue where my interrupt handler for RTC was firing continuously instead of once every second as I thought.Looking at the STM32 RTC example, I noticed that within the IRQ handler they were manually clearing RTC_IT_SEC. Why is the need for that ?Coming from an AVR background, I am used to the interrupt flag being automatically cleared when IRQ handler executes.Also is this something specific to RTC or all the peripherals?2016-02-13 04:10 PM
Depends on the peripheral, for example the USART and ADC auto clear when reading the data register.
Really a matter of whether the state is already latched somewhere in the peripheral (TXE, RXNE) and feed through to the NVIC, or if it is a transient signal that needs to be latched (EXTI)If in doubt, review the reference manual.2016-02-14 02:06 AM
To expand on that, in the ST chips there is the ARM processor, designed by ARM and the peripherals designed by ST. So on AVR it might be possible to ''feedback'' the ''interrupt processing has begun'' part from the CPU to the peripheral, while here that would be outside of the interface between the modules.
In general, interrupts are ''unexpected'' events. You can make the interrupt module ''edge senstive'' or ''level sensitive''. In the last half-century we've learned that ''edge sensitive'' is not a good idea. Before you know it, the device is still requesting service (keeping the signal active), but the CPU just missed the event and returns from the interrupt routine. So then there are no more edges, no more interrupts and a peripheral with data that is never examined. So interrupts must be level-triggered to be reliable, which leads to the interrupt storm that you observed if you forget to indicate ''i've handled the interrupt'' to the module.2016-02-15 07:44 AM
Thank for the explanation. It was a great starting point. I reads up on it and now i am clear :)