How to improvement work flow efficiency on dual-core µC such as STM32H7 in CubeIDE?

[Hansel]

My debug workflow feels pretty inefficient and I was hoping to learn from this community how to improve it. My code framework is built using the embedded CubeMX which leads to default code where the CM7 starts the clocking while CM4 is waiting, then the CM4 comes up and finally CM7 continues after the semaphore was released.

Here is the order of things that bug me most:

A. After compiling and flashing both CPUs, I often need to restart the code for debugging purposes. However, when I stop debugging, it seems there is no other choice but to recompile. Is there a way to restart the code for both CPUs without the need to reflash all the time?

B: Somewhere on youtube I found the sequence how to bring up the two CPUs so I can debug my code while it's running. This works decent but requires a few steps that I have to use each and every time:

1. First I compile the code for CM7
2. Then I need to wait for a while before I can compile the code for CM4
3. Then I have to select the two main() functions in the debug window
4. Now I can hit the start button to get the code running.

I don't mind that it takes a while to execute but I have to pay attention all the time until each step is done before I can take the next step. Is there a more automated way to compile the codes and get the processes started on my µC?

C: I don’t have a clean way to program the two CPUs in release mode. Sometimes it works, most of the time it doesn’t because some sort of error pops up. In most cases I have to reset my CPU. It doesn’t work straight out of CubeIDE.

So how does it work for you? What advice do you have to speed up my debugging/release workflow?

I use STM32CubeIDE version 1.9.0 (build 12015_20220302_0855) on Windows 10.

[TDK]

A) In Debug (or Run) configuration, you may disable autobuilding here:

 

To start a debug session without re-downloading it:

Go to Debug Configurations... -> Startup -> select load image -> Edit... -> uncheck Download

Not sure if you asked, but to debug without resetting the device first:

Go to Debug Configurations... -> Debugger -> in Reset Behavior, select "None"

B) Not real sure, but there are pre- and post- build steps which you may be able to use to craft a solution.

C) You could certainly add an "External Tool" which would upload both CM4 and CM7 releases by using the STM32CubeProgrammer CLI. What errors do you get?

All of these things take time to setup and learn. Developing with dual-core is unfortunately much much slower than with a single core chip.

[Pavel A.]

> when I stop debugging, it seems there is no other choice but to recompile.

Even if you select in debugger settings DISABLE auto build?

[Hansel]

@TDK​, @Pavel A.​, thanks for your help. Disabling auto build helped avoid reflashing if the code hasn't changed. Thanks a bunch.

@TDK​, regarding C), it essentially gets stuck in the reset handler. Maybe I should rephrase my question: how do I set up the release process for CM4 and CM7 so that the µC starts out clean upon flashing?

[Pavel A.]

>  how do I set up the release process for CM4 and CM7 so that the µC starts out clean upon flashing?

Try this:

• Define a place in your code where you want to start debugging instead. For example create a small function named "DebugHere".
• In debug settings, put this function name instread of main in "set breakpoint at main"

[Hansel]

@Pavel A.​, thanks for your reply. My question C) is unrelated to debugging. The question is related to how to flash both CPUs with release code for non-debugging purposes. As if I want to flash the µC for final release.

[Pavel A.]

CubeIDE does flashing in the same way that loads the program for debugging.

You can think of it as start debugging and detach immediately after loading the program.

That's all.

There are also other tools that can flash the program, thru the debugger interface and via the built-in bootloader interfaces (serial, USB DFU...)

[Hansel]

OK, thanks for the info.