Cortex-M3 NVIC, When to clear the interrupt flag

> I did check the errata, it did not mention anything about Timer or "bus cycle for
> accessing the interrupt flag".

As Andrew noted before, the reason is that this wouldn't be an erratum. It is a feature inherent in the architecture. I'll spare you the details, but simply put, Cortex-M3 has two independent bus interfaces for instructions and data respectively. Your memory access is using the data port (and waits for the APB bus cycle to finish), while the instruction port keeps fetching more code which gets executed. The ISR return might execute before the data bus access has completed, so NVIC thinks that the (still) active IRQ was a new one.

--
Marcus

> I did check the errata, it did not mention anything about Timer or "bus cycle for
> accessing the interrupt flag".

As Andrew noted before, the reason is that this wouldn't be an erratum. It is a feature inherent in the architecture. I'll spare you the details, but simply put, Cortex-M3 has two independent bus interfaces for instructions and data respectively. Your memory access is using the data port (and waits for the APB bus cycle to finish), while the instruction port keeps fetching more code which gets executed. The ISR return might execute before the data bus access has completed, so NVIC thinks that the (still) active IRQ was a new one.

--
Marcus

void TIMER0_IRQHandler(void)
{
        LPC_TIM0->IR = (1u<<0);
        LPC_GPIO2->FIOPIN ^= (1<<7);      //=> LPC_TIM0->IR cleared already.
}
//===========================================> The ISR return.

void TIMER0_IRQHandler(void)
{
        LPC_GPIO2->FIOPIN ^= (1<<7);      //=> instruction port: done.
        LPC_TIM0->IR = (1u<<0);           //=> instruction port: done; data port: not yet, LPC_TIM0->IR not cleared.
}
//===========================================> The ISR return.
//===========================================> NVIC works on next Interrupt Handling.
//===========================================> NVIC gets a LPC_TIM0->IR flag.

void TIMER0_IRQHandler(void)
{
        LPC_GPIO2->FIOPIN ^= (1<<7);
        LPC_TIM0->IR = (1u<<0);
        NVIC_ClearPendingIRQ(TIMER0_IRQn);//=> LPC_TIM0->IR cleared already.
}
//===========================================> The ISR return.

Many thanks to Marcus.

I guess,
If I am really trying to identify the interrupt source first, then clear the related interrupt flag right after, this symptom will not occur. Because before the ISR returns, all the interrupt flag updating has been done already.

I just joined the new company around two months. The trial period of new employee is generally three months. Somehow I can not get any available hardware for my development. (Just like in my ex-company.) So my supervisor let me use my private evaluation board, which I bought from eBay/ruten last year for personal study purpose. My supervisor asked me to do some basic practices like Key-Input and De-bounce, RTC based Date/Time Displaying. Actually most people here, don't know anything about ARM. I was told that, if I prefer ARM and I can handle ARM, I can use ARM for new projects; but it is quite doubtable. And in the Taiwanese culture, it is not wise to do something unusual, or ask for outside training of new technology, when you are the new guy.

RTC doesn't work, Strange Timer behavior, sounds like you are a quite lousy programmer.

MCU/Embedded System is very platform dependent; Yes, I know.

Good luck with the new job then.

This issue has been seen in other Cortex-M3 microcontrollers.
Normally the Cortex-M3 wait until the previous write is completed before the interrupt return. However, some microcontrollers has a write buffer in the peripheral bridge. The write buffer accelerates single write transfers to peripherals so that the processor don't have to wait until the transfer is done (peripheral bus might be running at slower clock speed).

However, for clearing an interrupt request, the write buffer reply to the processor that transfer is done, while the actual write transfer actually haven't been completed in the peripheral. So the processor executed interrupt return, and found that the interrupt request from the peripheral is still high and think that it is a new interrupt request.

Adding memory barrier instruction (e.g. DSB) doesn't always help because the buffer is outside the processor. But it might introduce just enough delay to allow the interrupt to be cleared.
Calling a function to clear the interrupt pending register NVIC also introduce some extra clock cycles of delay. So the interrupt request is deasserted when interrupt return is executed.

Another way to solve this problem is to carry out a dummy access to the peripheral, e.g. a read access to the same peripheral, to ensure that the previous write is completed before executing the interrupt return.

Hope this help.

Hi Joseph,

Though I often get helps from Experts via this Keil Discussion Forum. But it is surprising that I would get a reply from Joseph Yiu. I think you are not a regular visitor of this forum. Many Thanks for your help.

I would have considered that, adding a memory update is enough to avoid such a synchronization problem,

void TIMER0_IRQHandler(void)
{
        if ( LPC_TIM0->IR & (1u<<0) )
        {
                LPC_TIM0->IR = (1u<<0);    // Reset the MR0 Interrupt; Writing a zero has no effect.

                Timer0_Counter++;
        }
}

now I know that, a memory update might not be good enough. A dummy access to the peripheral register would be better.