We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am seeing stack corruption running a Cortex M4 that seems to be related to interrupting multicycle instructions.
The interrupt occurs during a STMDB sp!, {r4, r5, r6, r7, r8, r9, sl, lr}
The ICI bits at the time of the interrupt equal 7. This means that the STM was partially completed, and should be resumed starting at r7.
However, if I look at the stack at the time of the interrupt, I see 4 words were written by the interrupted STM, namely r4, r5, r6, and r7. This means that
r7 will be written again when the processor resumes the STMDB instruction.
This does not happen all the time. But it forces me to disable interruption of multicycle instructions.
Hi, this happens if the STMDB instruction is part of an If-Then instruction block, in this case the instruction is restarted from the beginning after interrupt completion.
It should not corrupt the stack but may generate problems if the accessed memory is in the peripheral´s region and you unintentionally write twice to a peripheral.
The reason is because ICI and IT bits are in the same place.
Could you verify if your multicycle instruction is inside an IT instruction block?, If so, just change the code to avoid it, instead of disabling interrupts.
The STMDB is not part of an if-then. The core supports interrupting an STM, LDM, PUSH and POP mid-operation. The instruction is not restarted from the beginning, but rather from the register indicated by the ICI bits.
You must ensure that if r4, r5,.., r11 are modified by the exception handler, they should be stacked at the beginning of this handler and de-stacked at the end of it, because they are not automatically saved by the processor.
As in your case r7 has been altered by the exception handler, the value that will be stacked is the new (wrong) r7. But the problem is not limited to multiple Load/Store instructions, it will also happen with any instruction which uses r7 after the exception.
You should re-write the exception handler and be sure to restore r4,..,r9 to their original values before leaving the handler.
Interrupt handler does not modify r4-r11. r7 has not been modified by the exception handler.