Skip to main content
YSaif.11
YSaif.11
Associate
January 24, 2022
Solved

How to disable opening startup_stm32.s file after using Run configuration.

  • January 24, 2022
  • 5 replies
  • 7704 views

I use STM32CubeIDE and every time, when I use Run configuration to build and flash MCU, IDE opens startup_stm32<mcu>.s file (startup_stm32g431kbtx.s for example).

Project has been generated by STM32CubeMX.

Settings in Run configuration are default.

How to disable that behavour?

    This topic has been closed for replies.
    Best answer by mattias norlander

    This is actually expected when you use ST-LINK GDB server.

    In the launch sequence we do the following:

    1. IDE: Launch ST-LINK GDB server
    2. ST-LINK GDB server connects to the MCU
    3. IDE: Launch GDB-client and connects to remote ("remote", regardless if same host or not) ST-LINK GDB server
    4. IDE: Apply the "load" command to have a generic way to manage loading elf-files regardless of GDB-server back-end.
    5. ST-LINK GDB server receives the load command. It does not load the image to target, instead it forwards the binary data to CubeProg_CLI which flashes the image to target.
    6. When CubeProg_CLI is done flash loading, ST-LINK GDB connects back to target applying the reset strategy.
    7. At this stage the IDE will apply breakpoints, set the PC counter and issue the Continue command (if applicable).

    The issue you observe happens somewhere inside step 3-5 above. It is the Eclipse framework which is notified that we actually have a debug session running. The framework will then try to suspend the CPU and fetch the current PC to update the editor with which line we are currently executing. Whether this Eclipse debug event update will happen or not is timing sensitive which is why it may be hard to re-produce. Maybe more likely to happen when we have to process a larger image file during step 5.

    I don't think we have a work-around for this. We use the Eclipse/CDT debug launch mechanism in a way it was not originally designed for, and this is the penalty. I doubt this is something we can fix.

    But as always, the more complaints we get, the higher priority to fix. But our position is that we have more painful defects to attend than this one. :)

    5 replies

    TDK
    TDK
    January 25, 2022

    FWIW, I can't replicate this behavior on a new F4 project. Not sure why it would be opening that file unless you're debugging.

    "If you feel a post has answered your question, please click ""Accept as Solution""."
    YSaif.11
    YSaif.11Author
    Associate
    January 25, 2022

    I added video with this case.

    https://youtu.be/A2WYFZO2SlI

    YSaif.11
    YSaif.11Author
    Associate
    January 25, 2022

    I solved that by reinstall IDE (Ubuntu) and re-generate project by IDE, not from CubeMX.

    Markus GIRDLAND
    Markus GIRDLAND
    ST Employee
    January 25, 2022

    Hello there,

    So just for clarification, if you are using CubeIDE with Ubuntu and generated the project through CubeMX and import it into CubeIDE you run into this problem?

    But if you create the project from CubeIDE directly this problem does not appear?

    YSaif.11
    YSaif.11Author
    Associate
    January 26, 2022

    Now that bahaviour appears again.

    Some time it works perfectly. But after some dubug-session, IDE began opens randomly stm32xxx_hal.c, startup_stm32xxx.s. And it highlights for a some momens randomly any line, like breakpoint or start of session.

    I think, IDE try to run some debug-features when I use Run configuration.

    mattias norlander
    mattias norlanderBest answer
    ST Employee
    March 1, 2022

    This is actually expected when you use ST-LINK GDB server.

    In the launch sequence we do the following:

    1. IDE: Launch ST-LINK GDB server
    2. ST-LINK GDB server connects to the MCU
    3. IDE: Launch GDB-client and connects to remote ("remote", regardless if same host or not) ST-LINK GDB server
    4. IDE: Apply the "load" command to have a generic way to manage loading elf-files regardless of GDB-server back-end.
    5. ST-LINK GDB server receives the load command. It does not load the image to target, instead it forwards the binary data to CubeProg_CLI which flashes the image to target.
    6. When CubeProg_CLI is done flash loading, ST-LINK GDB connects back to target applying the reset strategy.
    7. At this stage the IDE will apply breakpoints, set the PC counter and issue the Continue command (if applicable).

    The issue you observe happens somewhere inside step 3-5 above. It is the Eclipse framework which is notified that we actually have a debug session running. The framework will then try to suspend the CPU and fetch the current PC to update the editor with which line we are currently executing. Whether this Eclipse debug event update will happen or not is timing sensitive which is why it may be hard to re-produce. Maybe more likely to happen when we have to process a larger image file during step 5.

    I don't think we have a work-around for this. We use the Eclipse/CDT debug launch mechanism in a way it was not originally designed for, and this is the penalty. I doubt this is something we can fix.

    But as always, the more complaints we get, the higher priority to fix. But our position is that we have more painful defects to attend than this one. :)

      YIzAKat
      YIzAKat
      Associate II
      July 23, 2023

      Absolutely a low priority - but it catches me every time :)  

      My muscle memory anticipates the debugger pausing at the start of main() and I usually automatically hit F5 to continue (I don't want to disable this because sometimes I need it to stop there)

      My eyes see the pause in the startup.s file and my finger automagically hits F5 which, of course, then tries to start another session and causes the debugger to bail out.

      For completeness, my project is written using just CMSIS so this has nothing to do with the Cube code generation.

      The insidious aspect is that, as stated,  this seems to be timing-related and doesn't happen every time - I have to watch more carefully now.  Life is so unkind to engineers sometimes ;)

      Terms & ConditionsAccessibility statement