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

[YSaif.11]

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?

[TDK]

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.

[YSaif.11]

I added video with this case.

https://youtu.be/A2WYFZO2SlI

[YSaif.11]

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

[Markus GIRDLAND]

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]

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.

[TDK]

How was your project and run configuration generated?

[YSaif.11]

Project generated by STM32CubeIDE, C++, selected one nucleo board.

Run configuration generated by adding it in Run Configurations with options on screenshots below.

[mattias norlander · Accepted solution]

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]

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 ;)