[SOLVED] Unable to reprogram STM32 flash without full erase

    I am unable to reprogram an STM32 microcontroller unless I perform a full erase before programming. The below code uses CLion, but the same error also happens using the command line version of arm-none-eabi-gdb and JLinkGDBServer.
    GDB: arm-none-eabi-gdb (also occurs with CLion's bundled GDB)
    Compiler: arm-none-eabi-gcc and arm-none-eabi-g++
    Microcontroller: STM32L433CC (also happens with STM32F411RC)
    I am using USB for this. When I use ethernet, I get an error like "Failed to download RAMCode")

    The error is below. The program still starts, but with the previous code. If I attempt to flash it one more time, the flash is corrupted until I perform a full erase.

    I believe I have the same or a similar issue. My setup consists of a custom PCB with an STM32L476RG as the target. I am also using CLion, but am using v7.22 of the Segger suite of tools. This error seems to occur on several versions as I have tried several others with the same result. My output looks like this:

    I did some experimenting and found a workaround that allows me to continue development:

    1. Open up a Jlink Commander window and connect to the board.
    2. Reset the target with 'r'...this also halts the processor.
    3. Debug/Reflash the application, it should succeed this time.

    I would leave the Commander window open and just reset the board anytime I wanted to re-flash the device.

    I also tried running the same code via an ST-Link and using the STLink-gdb server that is packaged with the STM32CubeIDE. In CLion I added the STLink-gdb server as a external gdb server. I was able to successfully program and debug my application multiple times without a programming error. Sadly my application is based on freeRTOS and is multithreaded(the st-link + stlink-gdb server doesn't support multi-thread applications) so I need to continue using my workaround. My team has experienced a similar issue with CLion before but we able to fix it by modifying the .gdbinit script that CLion uses. More info on that here.

    Hi all,

    We are not aware of such an issue in recent versions.
    I just gave it a quick try here using two different evaluation boards but I cannot reproduce any problems.

    Test setup:

    • NUCLEO-L432KC / NUCLEO-F411RE
    • J-Link software V7.22
    • arm-none-eabi-gdb (8.0.50.20171128)
    • J-Link GDB Server CL started via command line (included in the test suite linked below)
    • Embedded Studio project (included in the test suite linked below)

    The test suite is available for download here:
    https://download.segger.com/Erik/210609_ST…4_TestSuite.zip

    1) Could you please give the project / files above a quick try and provide feedback?
    2) Could you please check if adding a "monitor reset" right before loading the application via GDB resolves the reported issues in your custom setups?


    Short feedback would be appreciated.


    Thanks
    Erik

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

    After some debugging and head bashing I figured out what my problem was. CLion has a menu for modifying the debug configurations for a given target. In the "Advanced GDB Server Options" I tried adding the monitor reset command but that did not function as expected. I had to use the following Clion gdb init script to get the jlink to actually run the monitor reset command.

    Clion gdb-monitor commands

    In my project directory I have a file titled ".gdbinit" that contains the same commands listed in the above link. For Clion to recognize these commands I also had to add a ".gdbinit" file to my C:\Users\me\ directory with the line:

    add-auto-load-safe-path C:\path\to\project\.gdbinit

    I have this same setup on several other projects each with their own line in the file and it works perfectly. The reason it was not working on this project was because of a typo in the path. After fixing the typo, the script was properly executed and it all worked well.

    Thanks for your help!

    Hi,
    Thank you for taking the time to share your solution to the problem with the community.

    We will close this thread now, as the issue is resolved.

    Best regards,
    Fabian

    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login