-
Notifications
You must be signed in to change notification settings - Fork 85
VTOR and initial stack for debuggers #283
Comments
See also #55 where this was discussed previously. I think there have been similar discussions on the chat before too but not sure if they made it into issues. Do you have a specific debugger where this is a problem? I don't understand why using a debugger should require changing VTOR. It seems like a correct debugger should ensure SP is initialised if it's jumping code execution to the reset vector manually; otherwise it could use the AIRCR register to trigger a local reset. Previously it's been mentioned in the context of bootloaders which might fail to change VTOR (and SP, I suppose) before jumping into the application, but really that seems like a defect in the bootloader. User applications can change VTOR in On Cortex-M0 there's no support for VTOR and instead remapping the vector table is done in some chip-specific fashion, for example by remapping SRAM to address 0 and writing a vector table to the start of the SRAM. We can't implement that in cortex-m-rt because it's entirely application and MCU specific, and requires corresponding updates to the user's In the context of bootloaders I was fairly sure we shouldn't try and fix them in cortex-m-rt, since it's very platform specific and we can't make all the right guesses, but I hadn't considered debuggers too. I'd be interested in hearing about why a debugger needs the user code to set up SP/VTOR for sure. |
Makes sense, but i think that at least the stack pointer -afaik common to all cortex m processors- can be set at reset, leaving the rest for the preinit, where it can be easily adjusted with some unsafe blocks. Or what about inlining the preinit? In our environment we are using an nxp s32g debugged with a trace32 + lauterbach for cortex-m cable. For sure the code will work perfectly once flashed, but when loaded (through data.load.elf) directly to RAM, it takes the VTOR and MSP it has by that moment, producing funny results when any interrupt/exception arrives. |
Do you modify I think there could be compelling arguments for this, perhaps it helps our memory safety case if we do always set the stack pointer in our Reset vector to whatever was configured in our linker script rather than only relying on hardware to do it for us, but I worry there are situations where having this crate set the SP at reset causes more problems. I'm not sure if there's any good way to make this user configurable either (short of adding a default Cargo feature which is a bit heavy-handed). |
From this weeks discussion: We have a feeling this is quite vendor specific and there's very little we can do universally about it. Changing the SP would require a Since we don't have any other report about requiring to reset the stack pointer we feel inclined to close this as a "won't fix". |
To add a little more context:
Adding some way to let the user perform this sort of initialisation behaviour is tricky too, because their function would also need to be It might yet be possible to provide a good way to allow the user to customise the reset vector entirely; in the worst case the user can provide their own |
In
crt0.s
you'll usually find statements like the next one at the very beginning of the code:ldr SP, =_stack_start
To set the initial stack pointer to the correct value. You'll find it along with code to set
VTOR
, and other tasks considered as protective programming. This allows to mimic the HW reset behavior to start off in the same environment when the software is launched from a debugger (ie. lauterbach)Can this be implemented in
fn Reset() -> !
?One can argue that this can be implemented inside the preinit function, but in the stack pointer case it wont work as the stack has already been used by that moment and on function epilogue it will be incremented causing an incorrect mem access. Setting it using the debugger is also possible, but is not very clean to have this values (IVT location or stack start) in the debugger context.
The text was updated successfully, but these errors were encountered: