This repository was archived by the owner on Jan 24, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 24, 2022. It is now read-only.
Add force-setting of stack pointer in startup code #254
Description
During experimenting with new unsafe code I realized that the stack pointer can easily be corrupted, and this can propagate and stick after a system reset while having a debugger connected.
This causes preinit to automatically hardfault if using the stack and the zeroing/init of RAM under no optimization also directly hardfaults.
I propose we add the code to always hard-load the stack pointer from the vector table.
It will cost a few bytes, but I argue that it is a price worth to pay to have stable debug/implementation runs.
Currently it is trivial to get into a very hard to debug state.
Activity
jonas-schievink commentedon Mar 20, 2020
How/Why does this situation happen, exactly? I wouldn't want to work around issues we don't fully understand in cmrt.
adamgreig commentedon Mar 20, 2020
The architecture reference manuals seem pretty explicit that SP is always initialised from the vector table on any power-on or reset, with no mention of exceptions, so something definitely seems wrong here. Do you have a short reproducible example?
korken89 commentedon Mar 20, 2020
Sadly I'm far gone from this issue right now, but I'll look into reproducing it.
The issue is not on the Cortex-M core or the reset itself though, it's the debuggers. It seems some do not implement reset correctly, for example the stlinkv2, which after reset
mon reset halthad the old stack pointer in some cases (especially after HardFault).jonas-schievink commentedon Jan 8, 2021
I believe we discussed this at some point (or a similar issue) and concluded that this is a bug in the debugger that we don't really want to work around at this point, so closing this.