cancel
Showing results for 
Search instead for 
Did you mean: 

after calling __set_MSP the local variables get corrupted

ELitv.2
Associate II

Hello,

First, I am sharing some basic information.

The target - STM32G0, compiler Keil C11.

I am trying to jump from a Bootloader to an application. The scenario is very frequent and there are many questions about that on the web, but unfortunately I failed to find a solution to my problem. One of the problems I haven't yet resolved is corruption of the local variables right before the jump as result of __set_MSP which stores in the stack the base address of the applicatio, where I am trying to jump to.

You see here 2 pictures.

On the 1st picture you can see that appJumpAddress is 0x800515D, which is correct.

On the 2nd picture , after calling __set_MSP, written in asm, you see that appJumpAddress is already wrong and therefore my BL jumps to the wrong place in Flash memory .

The operation is standard , described everywhere. What I might did wrong?

Thanks!

P.S.

If someone here has an implementation of such a jump in Keil, can you please share these 3-4 lines?

8 REPLIES 8

No kidding... half this stuff is coded by people who barely know what they are doing.

The use of statics/globals would have been safer.

Look, don't set the MSP here, it's not coming back. Explicitly load the SP as the first thing you do in the Reset_Handler of the *Application*. Some of the GNU startup.s examples do this.

Reset_Handler   PROC
                EXPORT  Reset_Handler             [WEAK]
                IMPORT  SystemInit
                IMPORT  __main
 
;                LDR     SP, =__initial_sp 
 
                LDR     R0, =__initial_sp ; Cortex-M0(+) method
                MOV    SP, R0
 
                LDR     R0, =SystemInit
                BLX     R0
 
                LDR     R0, =__main
                BX      R0
                ENDP

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Also the interrupts shouldn't be disabled at the MCU level, nothing enables them again.

And don't change the SCB->VTOR here. That should be handled in the App side SystemInit() with a symbol the linker can fix up.

extern uint32_t *__Vectors;

SCB->VTOR = (uint32_t)(&__Vectors);

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Piranha
Chief II

A complete solution:

https://community.st.com/s/question/0D50X0000AFpTmUSQV/using-nvicsystemreset-in-bootloaderapplication-jumps

P.S. The line 229 perfectly describes almost all ST's firmware related code in general!

Actually, SCB->VTOR I changed in the SystemInit in the App, because Keil changed it to the FLASH_BASE which is 0. Thus, setting VTOR before the jump is redundant.

Thank you for your help!

Thank you!

Loading MSP for the app is popular because of ARM (Keil) and IAR. Their startup files neglect to initialize MSP like gcc's.

https://github.com/STMicroelectronics/STM32CubeG0/blob/f4e8c0a878aebc1b873b8590fd29563404759694/Drivers/CMSIS/Device/ST/STM32G0xx/Source/Templates/arm/startup_stm32g030xx.s#L121

https://github.com/STMicroelectronics/STM32CubeG0/blob/f4e8c0a878aebc1b873b8590fd29563404759694/Drivers/CMSIS/Device/ST/STM32G0xx/Source/Templates/iar/startup_stm32g030xx.s#L114

As for SCB->VTOR: now I'm setting it in the beginning of main(). Just got tired patching SystemInit().

Andrew Neil
Evangelist III

You're right and I appologize for not providing pictures of good quality. It is because I asked the question with my phone and had these pictures because i discussed the issue with my friends on Telegram. Next time i will do a better job. Thank you!