Stack pointer STM32F411VE

[Blutti]

When building a project using VisualGDB (I’m using version 5.2 r6) for the STM32F411VE microcontroller the stack pointer is 0x20002e58 on start-up, while _estack = 0x20020000. Resulting in variables being allocated on the stack at this address over other variables and corrupting my memory.

I eventually got around  this by defining “sram_layout” which forces the stack pointer to be set to _estack in startup_stm32f411xe.c and fixing my issues.

Now my question is: is it intentional that the stack pointer gets set to this (seemingly) random value?
And if so, why?
Is it some weird optimisation I don’t get, or am I missing something?

[support]

Hi,

It’s hard to say what is causing this without more details. Normally when VisualGDB runs the ‘mon reset init’ command (unless you have disabled chip reset via Debug Settings), the stack pointer should be reset based on the contents of the interrupt table.

Please try running the ‘mon reset init’ command manually and check if the output shows the correct sp value:

xPSR: 0x01000000 pc: 0x080026bc msp: 0x20020000

If yes, please check that the OpenOCD window contains similar text at the beginning of the log:

adapter speed: 1800 kHz
stm32f4x.cpu: target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800027c msp: 0x20020000

[Blutti]

Ok I found (atleast part of) the issue.

With my current setup it does run it in the OpenOCD window, but instead of those values it gives me (both when I manually run ‘mon reset init’ and in the OpenOCD on startup):

adapter speed: 1800 kHz
stm32f4x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff4252 msp: 0x20002e58

The program counter doesn’t point to FLASH but to System memory (0x1FFF 000 ~ 0x1FFF 7A0F). This is because we use the bootloader function provided by STM (by pulling the boot pins to curtain voltages). It appears that when the bootloader exits and jumps to the application code, it doesn’t reset the stack pointer.

If I remove the jumpers so the micro boots normally I get the following (correct) output

adapter speed: 1800 kHz
stm32f4x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08003dc8 msp: 0x20020000

So my problem is a weird interaction between debugging and the bootloader.

[support]

Hi,

Thanks for confirming this. In this case the best solution is indeed to ensure that the manual stack pointer assignment in the startup file gets compiled.

[Author]

Posts