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 Paulgiangrossi,
You shouldn't need to be doing that. As the other contributors mentioned, there are a few circumstances in which accesses will be repeated, but these are nevertheless harmless. (If the target address was volatile, the compiler should not have accessed it with a multiple access.) For normal memory, repeating the write of the same register to the same address is acceptable behavior. However, you seem to be saying that a register has been written to two different addresses, ie. stacked twice in consecutive locations.
This is not a known errata for the processor, and I am pretty sure it would have been seen in validation if it were generally true. So it follows that you have hit an unusual corner case in some respect. Can you tell us something more about the chip you are using? Do you know anything about the memory system, for example what wait-states it presents? Where is your stack located in memory? How are you observing the incorrect stack frame contents? Can you tell us about what that interrupt handler does? Does it interfere with the stack pointer in any way?
Hi Paul, I see your company has a technical support entitlement and you have submitted this issue as a support case, so I suggest we continue the investigations in that channel where we can more openly discuss non-public technical details with you. I am just setting up the scenario you have described in my simulation testbench.
Hi Paul, I have simulated the test case as you described the details, but the processor is behaving normally. Please review the waveforms attached in the support case. The STM was interrupted at the point where it stacked r7. The EPSR correctly indicated that r8 would be the continuation point on return from exception, and that is exactly what happened.