Why is STM32CubeIDE so much slower than STM32CubeProgrammer for programming chips?

[BarryWhit]

This is a small but annoying issue.

In Cube32Programmer, after you connect to your board, the connection remains active, and the latency for programming the chip is almost imperceptible.

In STM32CubeIDE on the other hand, every time I program the chip there are several seconds of delay, while it launches gdb, and then waits to connect, and then connect again, and then programs, and the verifies.

I do this dozens of times a day and believe it or not, those extra 5 five second i lose each time are really distracting.

To solve this, I tried several things:

1. skip verification - it helps a little, and is usually safe to turn off during development. But most of the delay is not in verification, but the startup time.

2. I tried using "shared programmer" mode. I thought if I could connect Cube32Progammer, and have it share the connection with STM32CubeIDE, I could avoid the startup overhead. But It doesn't change anything.

3. i tried setting up the st-link in "persistent mode". You run the gdb server manually outside of STM32CubeIDE and it listens on a tcp port. Then, Cube32IDE connects to it instead of launching a new instance. This is cumbersome, and I ran into weird issue where I had to restart the process manually. It was not a happy experience. And to top it off, it still wasn't as fast as Cube32Programmer.

Dear ST - why can't we have nice things??

Update:

Linking partial workaround for non-debug session case

HOWTO: Download programs 30x faster to STM32 from STM32CubeIDE

[BarryWhit]

I investigated this some more.

1. One of the multiple "Waiting for debugger connections" is due to "Live expressions" being turned on. It does not make a big difference. You need a debugger connections for Live expressions to work. (so that's why  "Live expressions"  work even when SWV (SWO pin) is not enabled. It uses the debug channel. Seems obvious in retrospect.)

2. CubeIDE launches CUbe32Programmer_CLI on its own to download the new program (even though you could do it with gdb 'load' command)

3. If you're not starting a GUI debug session, and you're not using "Live Expressions", and CubeIDE already launches Cube32Programmer to do the actual programming, I don't understand why there needs to be any debugger connection established. It seems to be thrown away immediately.

4. Most of the delay is a pause after the build completes, to start the debugger, and then a pause where it takes gdb a moment to connect to gdbserver (which is also launched).

5. from the command line, with openocd running, connecting with GDB, downloading the program and disconnecting was timed at 3.1 seconds, GDB seems to take some time to connect to gdbserver. Download takes no time at all.

6. from the command line, with gdbserver running, connecting with GDB, downloading the program and disconnecting was timed at 4.0 seconds. GDB again seems to take some time to connect to gdbserver. Download takes no time at all.

7. CubeIDE, even without the delay after the build, seems to add several seconds more to the connection process, I don't know why and haven't been able yet to get a good profile, or to log the GDB commands the inferior gdb session uses.