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.
This is assembly code generated from GCC. Most functions push registers on the stack, and this results in many STMs with the stack as the destination. If a register is stored twice on the push because of an interrupt, and only popped once on the pop, the stack is corrupt and the program invariably crashes. This is the behavior I am seeing. It is very problematic.
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.
Hi paulgiangrossi,
I'm sorry for late reply. Do you say that the re-start address of the STM was incorrect after returning an ISR? If it is true, It should be a problem. Could you change the Cortex-M4 part? It might be a defective product.
Best regards,Yasuhiko Koumoto.
It's may be an idiot response but, an assembler code generated with GCC can indeed present complexities due to many non- necessary instructions. This is by no means a problem related to the processor. I understand that you are looking to encode access your stack inline later ... Do not get can get the same result using the library GCC, in order to keep the same line of programming?