STM32L4: Bootloader Jump to App fails depending of optimization level

Hello,

I am trying to write a bootloader for STM32L496(ZGT) and I am pretty new to ARM and RTX.
The Bootloader works over USB HID and uses RTX5 (RTOS 2).
I use µVision V5.36 with compilter V6.16 (With AC5 like warnings).

I encounter a strange behavior.
If I use optimization level o0 my Jump function "failes". I jump but get stuck in the main app. As far as I know at some point where some IRQ should be disabled.
If I use level o1 it jumps.

My Jump funcion:

typedef void (*pFunction)(void);

void JumpToApplication(uint32_t uiAppAdress)
 {
     uint32_t JumpAddress = *(__IO uint32_t*)(uiAppAdress + 4);
     pFunction Jump       = (pFunction)JumpAddress;
 
     HAL_RCC_DeInit();
     HAL_DeInit();
    
         NVIC->ICER[ 0 ] = 0xFFFFFFFF ;
         NVIC->ICER[ 1 ] = 0xFFFFFFFF ;
         NVIC->ICER[ 2 ] = 0xFFFFFFFF ;
         NVIC->ICER[ 3 ] = 0xFFFFFFFF ;
         NVIC->ICER[ 4 ] = 0xFFFFFFFF ;
         NVIC->ICER[ 5 ] = 0xFFFFFFFF ;
         NVIC->ICER[ 6 ] = 0xFFFFFFFF ;
         NVIC->ICER[ 7 ] = 0xFFFFFFFF ;

         NVIC->ICPR[ 0 ] = 0xFFFFFFFF ;
         NVIC->ICPR[ 1 ] = 0xFFFFFFFF ;
         NVIC->ICPR[ 2 ] = 0xFFFFFFFF ;
         NVIC->ICPR[ 3 ] = 0xFFFFFFFF ;
         NVIC->ICPR[ 4 ] = 0xFFFFFFFF ;
         NVIC->ICPR[ 5 ] = 0xFFFFFFFF ;
         NVIC->ICPR[ 6 ] = 0xFFFFFFFF ;
         NVIC->ICPR[ 7 ] = 0xFFFFFFFF ;
        
         SCB->ICSR |= SCB_ICSR_PENDSTCLR_Msk ;
    
         SCB->SHCSR &= ~( SCB_SHCSR_USGFAULTENA_Msk | SCB_SHCSR_BUSFAULTENA_Msk | SCB_SHCSR_MEMFAULTENA_Msk ) ;
    
     SysTick->CTRL = 0;
     SysTick->LOAD = 0;
     SysTick->VAL  = 0;
 
     SCB->VTOR = uiAppAdress;
 
         __set_CONTROL(0x00000000);
    
     __set_MSP(*(__IO uint32_t*)uiAppAdress);
     Jump();
 }

Maybe anyone has an idea why it get stucks?

Thanks Stefan

Parents
  • My guess is, with optimization level 0 the compiler puts some values on the stack and uses them when calling "Jump()", However, when the MSP is changed, that values on the stack are gone. With optimization level above 0 it is more likely, the compiler holds values in registers and so the code runs independent of the stack, which still makes things work.

Reply
  • My guess is, with optimization level 0 the compiler puts some values on the stack and uses them when calling "Jump()", However, when the MSP is changed, that values on the stack are gone. With optimization level above 0 it is more likely, the compiler holds values in registers and so the code runs independent of the stack, which still makes things work.

Children
No data