Stack pointer STM32F411VE

Sysprogs forums Forums VisualGDB Stack pointer STM32F411VE

This topic contains 3 replies, has 2 voices, and was last updated by  support 7 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #9986

    Blutti
    Participant

    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?

    #9995

    support
    Keymaster

    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:

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

    #10053

    Blutti
    Participant

    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.

    #10062

    support
    Keymaster

    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.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.