Sorry…I meant to ask how would you monitor the value of MSP to determine if the stack got corrupted and you’re trying to access something that doesn’t exist inside an IRQ handler (which I was doing…)
the startup code? isn’t that what really calls the main itself? I interpreted that it’d be the stuff before the scheduler is invoked.
I don’t understand the question, sorry
Just trying to understand how you could have determined whether the IRQ handler was trying to access a corrupted stack via MSP
well, yes. If you look at it the way hs2 described:
then it amounts to the same thing. Normally the scheduler is started somewhere within main(), so the startup code somewhat continues past the main until the scheduler starts. You may also look at the scheduler start as the pivot point in which everything that happened before executed on the startup stack. Everything afterwards executes either on the task stacks (tasks) or the “freshly wiped” (at scheduler start time) startup stack which of course has lost its history as the scheduler started (interrupts). One corollary of this architecture is that you can not cleanly terminate the OS in the sense that it “could go back” because there is nothing to “go back to.”
The way I’ve organised things is that the startup code sets up the processor, copies data to RAM where it’s expected, clears bss, then creates a task to run main(), then starts the scheduler. I see that that’s the last thing that (apparent) function does; I do hope that vTaskStartScheduler() never returns!
1 Like