I'm working with a Cortex M4 (Freescale's Freedom-K64F dev-board). I'm trying to write a long sequence of data to flash. The state machine for this sequence operates in the interrupt handler. This means that in the handler for the processor's flash-controller interrupt, I launch further flash controller operations. The last of my sequence of data operations is short, and is likely to finish very quickly. Launching a successive flash operation from a IRQ handler means that it is possible (in some cases such as the last operation) for the `successive` operation to complete before the IRQ-handler which launched it; and in fact I do see this happening. The problem is that such a sequence where a an active interrupt is made active_and_pending from an internal peripheral seems to not be working reliably for me. I find that the `active and pending state` does not restart the interrupt handler automatically upon return from the handler.
My application fails to field a successive interrupt when a `successive` operation launched from an active interrupt handler completes early. The only way I have been able to reason about it is by arguing that returning from an interrupt clears the pending flag and therefore causes my application to miss pending IRQ-handling.
To support my hypothesis further, I've re-written my IRQ handler in the following fashion:
void IRQ_Handler(void)
{
do {
handleCompletedOperationsAndProgressStateMachine();
} while (NVIC_GetPendingIRQ(...) != 0);
}
This does help, but there is still a small window between while (NVIC_GetPendingIRQ(...) != 0); and the actual return of the IRQ where the interrupt could be set as pending again and be lost.
Is it a processor-implementation thing that the pending status of an interrupt is cleared upon interrupt return?
The problem was in my software. I had accidentally disabled all interrupts at one point before returning from my completion handler. The system was unable to handle pending Interrupts in that state. Sorry for have taken up time.