Why Reset_Handler() generated by CubeMX2 set PSP not MSP

[Higashitani_Yuki]

Hi, I find the startup file generated by CubeMX2 for my STM32C551xx MCU doing something weird that I couldn’t understand. 

/**
  * @brief  This function is the Reset Handler called on controller reset.
  * @param  None
  * @retval None
  */
__WEAK __NO_RETURN void Reset_Handler(void)
{
  __set_PSP((uint32_t)(&__INITIAL_SP));

  __set_MSPLIM((uint32_t)(&__STACK_LIMIT));
  __set_PSPLIM((uint32_t)(&__STACK_LIMIT));

  SystemInit();         /* CMSIS System Initialization */
  __PROGRAM_START();    /* Enter PreMain (C library entry point) */
}

The code shown above reset the PSP pointer rather than MSP. I’m not sure if I do some misunderstanding about the stack pointer, as PM0264 indicated that MSP should be the one reset to the value retrieved by the reset handler.

 

[Saket_Om]

Hello ​@Higashitani_Yuki 

I reported your question internally and will get back to as soon as possible. 

Internal ticket number: CDM0066080 (This is an internal tracking number and is not accessible or usable by customers).

[Saket_Om]

Hello ​@Higashitani_Yuki 

STM32C5 device startup files are aligned with CMSIS 6.3.0

https://github.com/ARM-software/CMSIS_6/blob/45dab712ad84f8cbbf2b7bfc089c19088507df6f/CMSIS/Core/Template/Device_M/Source/startup_Device.c#L115

 

Reset_Handler does not explicitly initialize the MSP.

The MSP is initialized automatically by the Cortex-M hardware during reset:

1. The processor reads vector table entry 0, __INITIAL_SP.
2. It loads that value into the MSP.
3. It reads vector table entry 1 and branches to Reset_Handler

[Higashitani_Yuki]

Hello ​@Saket_Om 

Thank you for your reply. 

In fact, I meet a critical problem when I keep my STM32C5 board power on and try to download a different firmware with totally different stack requirement. As shown in the following screenshot, the PSP was set to the __StackTop(0x200031b8), but the MSP was not initialized. As a result, the process crashed with a STKOF fault after setting the MSPLIM into  __StackLimit(0x200011b8).

 

Parts of the compiling map about the stack address is shown below:

 *(COMMON)
                0x200009b8                        . = ALIGN (0x8)
                0x200009b8                        _ebss = .
                0x200009b8                        __bss_end__ = _ebss

.heap           0x200009b8      0x800 load address 0x0800ca68
                0x200009b8                        . = ALIGN (0x8)
                0x200009b8                        __end__ = .
                [!provide]                        PROVIDE (end = .)
                0x200009b8                        _heap_start = .
                0x200011b8                        . = (. + HEAP_SIZE)
 *fill*         0x200009b8      0x800 
                0x200011b8                        . = ALIGN (0x8)
                0x200011b8                        _heap_end = .
                0x200011b8                        __HeapLimit = .

.stack          0x200011b8     0x2000 load address 0x0800ca68
                0x200011b8                        . = ALIGN (0x8)
                0x200011b8                        __StackLimit = .
                0x200031b8                        . = (. + STACK_SIZE)
 *fill*         0x200011b8     0x2000 
                0x200031b8                        . = ALIGN (0x8)
                0x200031b8                        __StackTop = .
                0x200031b8                        _estack = .
                0x200031b8                        __stack = .

 

[harp]

Does MCU reset after downloading firmware? Does “download a different firmware” mean firmware live update in final product, or download firmware in debug environment?

[Higashitani_Yuki]

Good question!

Firmware download is in debug environment.

I noticed that the 4-wire SW interface I’m using for debug, excluded the hardware reset signal. I’m not familiar with the download process, after the flash erasing and programming, maybe there’s no soft reset triggered.

Anyway, by reset the MCU with the pin RST after crashed and it solved the problem.

 

[harp]

The reason is the debugger settings. E.g. in STM32CubeIDE debugger settings if the Reset behavior is Connect under reset (default) MCU will be reset after flash programming, others will result in no reset. So if you select the appreciate option in debugger settings, there should be no need to manually reset after flash programming.