What actually happens during a semantic operation of vTaskSuspendAll? I see that it just increments a variable, where is that variable taken into account? What happens to the stack pointer - does it move to the MSP during the suspension?
What I’m really driving at is I really want a scheduler full stop. I have a firmware update routine that is going to blow away the flash and reset. Once it starts, it crushes 4k of RAM that is being used as a buffer to transfer the new image from an EEPROM to the flash.
I want to make sure that the stack pointer has moved back to the MSP in lieu of lingering on the stack area of that last running task which may well be in the 4k that gets crushed.
Will:
vTaskSuspendAll();
__disable_irq();
be adequate to begin this operation or would it be safer to put all of this in the NMI ?
What vTaskSuspendAll does is set the flag that says the scheduler is stopped. This says that any interrupts that happen will not actually touch the actual task lists, but just record tasks that need to have there scheduler state changed so that happens when the scheduler is restarted.
If you actually disable all interrupts, then as long as that task doesn’t make any calls itself that would cause a rescheduling, nothing else can get run anyway.
The system uses vTaskSuspendAll when it doesn’t want to block interrupts for as long as it needs control of the system.
vTaskSuspendAll just suspends the task scheduler but keeps everything in place with ISRs enabled and ready to be resumed.
Depending on the port or MCU the MSP is not the task stack pointer (it’s the PSP). MSP is used as ISR stack pointer e.g. for Cortex-M MCUs.
If your FW update messes up something FreeRTOS resp. your application runtime relies on you’ll likely run into problems. You don’t want to shoot yourself into the foot
For things like that usually a dedicated application (e.g. a bootloader) outside the affected flash/RAM range is used.
Yes, this is a cortex-m3 part. I am aware of the consequences of crushing the RAM but once this code is entered, there is not intent of going back to the scheduler - succeed or fail, the part resets.
So to clarify here, if I suspend and stop interrupts and want the stack pointer at the MSP, I must do that myself (this is a cortex-m part) - true?
Alternatively, is it a true statement that regardless of the state of the scheduler, if I invoke the NMI and end that ISR with a call to reset the system, the kernel cannot interfere with what I am doing there?
Yes, both points are right. When branching to the update code requiring main / ISR stack area, you could set a suitable IRQ by software, __disable_irq in the ISR and do the update procedure ending up with reset or use the NMI.
Once you’re in the highest prio ISR or __disable_irq was done by any prio ISR nothing else is able to run.
