I have a problem with ARM LPC2378 revision B, configured with CPU clock frequency at 72 MHZ. I have the following configuration: - an IRQ interrupt function linked to CPU timer 0 (vectored interrupt). It is invoked with a period of 1 ms - an FIQ interrupt function linked to the half-empty flag of RX queue of MCI bus controller (the bus used to communicate with SD-MMC cards).
During the reading of a file from an SD card CPU switches to "Data Abort" or "Prefetch Abort". While CPU is in this error condition I very often see that IRQ stack pointer is corrupted, i.e. it points to an invalid address. However this doesn't happens every time, but only very often.
I've controlled that stack dimension of each mode is well sized.
Inside the IRQ function some other functions are invoked. If I rewrite the code of these inner functions as "inline code" inside the IRQ function the system doesn't crash! It seems the problem to be the call of a function inside the IRQ function but I'm not sure of this conclusion.
The problem happens both with MAM fully enabled and MAM partially enabled.
Any suggestions?
Thanks and have a nice day!
Demis
I meant that the loop is long, of course...
I understand your observation but function duration is not the cause of the problem. The loop is only a dummy loop. I mean that I've written that loop only to waste time inside IRQ function. I've measured the duration of that function with my oscilloscope and I've found that it lasts 100 microseconds, while it's period is 1 millisecond.
There are no nested calls of that routine...
As already noted, it isn't nice with a huge loop in an ISR. The ISR should be quick. Very quick. Extremely quick. You must always guarantee that you have exited your ISR before the hw needs to generate the next IRQ of the same type. If you can't promise that, then you can no longer guaranttee that you do not loose interrupts.
When you have multiple ISR, you must make sure that the total runtime of all ISR does not need more than 100% of your CPU capacity, and that no single interrupt source at any time gets delayed enough that the processor trigs a new interrupt before the previous interrupt from that source has been detected and the ISR called.
Another thing. fast-interrupt handler makes use of a pointer: p_sd_data_rx. Where is it initialized? How do you proove that it doesn't overflow any destination buffer? Your code never tests it's value so every interrupt will step it further and further forward, possibly overwriting unknown data in memory. If the stack (or another pointer is overwritten), your program is lost.
Do you have many interrupt source firing at the same time? Do you support nested interupts? I think your stack is 15 levels deep.
Are you saying that you intentionally want to loose 10% of your CPU capacity (while running the processor at maximum power consumption)?
Note that the fast interrupt has higher priority than your delay, so 100us may be the minimum delay time. But if the FIQ happens during the delay, you may get a longer delay. Have you looked into running a second interrupt with 100us offset from the first timer IRQ?