Jumping from app back into bootloader after scheduler started

Hi ,
I’m working on cortex m-7 and i’m trying to jump back to bootloader after app already started scheduler.
If i jump back to bootloader before scheduler started all seem to work as expected.
but if i jump back to bootloader after scheduler started i get some weird un-expected exception.
i did disable interrupts using cpsid i but still it doesn’t help.
Any idea what am i doing wrong or what should i do to make it work ?

Since you don’t disclose a single line of your bootloader, how on earth is anybody here supposed to guess what happens? Do you think this is Hogwart’s?

The question was in general concept of action , are they correct.

pseudo code :

bootloader () {
__asm volatile ("cpsid i");
..... //Logic
__asm volatile ("cpsie i");

TaskCreate( Task1);

void jump_to_bootloader(void)
    __asm volatile

    	    "ldr       r3, bootloader            \n"
            "bx        r3            \n"
            ".align    4                    \n"
            "bootloader: .word <addr>    \n"

Task1() {

The above is example of the failure.
If i use jump_to_bootloader() from main before the scheduler starts it all works.

You should disable all interrupts (maybe including clear all pending) before starting an other program and let the newly started program enable the interrupts as needed.
In your case disable all interrupts before starting the bootloader and in the bootloader do not enable interrupts before starting the application.

how do i clear pending interrupts ?
So you suggest that my problem is that i get the assertion between the time i enable the interrupts and jump back to the app?

bootloader () {
__asm volatile (“cpsid i”);
… //Logic

__asm volatile (“cpsie i”); <— this is the problem ?


Sure. An interrupt can occur before the other application is ready to handle it properly, right ?
Clear pending interrupts ? Know your MCU :wink:
Cortex-M MCUs have a NVIC. NVIC has an ICPR register.
There is also a CMSIS interface NVIC_ClearPendingIRQ which can be used.

This is a potential problem. If your application runs FreeRTOS, you must allow the FreeRTOS init code to execute with interrupts disabled (we had this several times before). FreeRTOS will enable interrupts as the last step of action before kicking off the scheduler.

One thing to remember is that every machine I know of starts with all interrupt disabled and at least most devices in a reset state, and most programs expect that. If one program has run and then you go back through the boot process, it can leave the device ‘active’, and that can cause problems if the device interrupts before the new application is setup for it.

Ideally, either the boot loader or the program jumping to it would reset all the devices to put them back into the just started state. If that isn’t possible, then it might be good to at least go and clear the interrupt enable for all the devices in the NVIC so that nothing can generate an interrupt until the new application is ready for it.