Nucleo-H745 / CubeIDE: Application doesn't run while debugger is connected

[O'li]

When running my application from the debug session for CM7 (CPU1), the CM4 (CPU2) isn't detected as being in "Stop Mode", which leads to a timeout and therefore an error detection.

If the debug session is stopped, the application runs as expected after a reset.

When launching debug for CM7, then for CM4:

• step-by-step debugging on CM4 can lead to a successful application run
• direct start from main's breakpoint can lead to the address 0xa05f0000

I'm using the code generated by CubeMX (Board Selector with H7 package v1.6.0), an out-of-the-box NucleoH745ZI, and debug configurations were made by following the AN536.

Does this ring some bells?

[Tesla DeLorean]

The debugger has been observed to block access to the DBGMCU DEVID registers on the H7 parts, which determines some code function/settings.

[O'li]

Is there a known workaround to properly debug an H7 device?

Does it mean that another debug setup (another IDE and/or another probe) is recommended?

Does ST intends to provide a fix for the next versions?

[AShri.1]

Hey @O'li​ : did you find a fix/workaround/solution for you problem? I'm having the same problem, and I'd really love to know if you made any progress.

step-by-step debugging on CM4 can lead to a successful application run

This is the only thing that stops the M4 from crashing, but it is rather tedious.

I made a reference blinky with my settings: https://github.com/AnielShri/H745_Nucleo/blob/master/Documentation/dual_core_debugging.md

[O'li]

Hi AShri,

I did find the issue for my setup: in my debug configuration, I was checking the "Halt all cores" option, thinking that it would insure the debug launch to reset CPU2 and start both cores at the same time. But actually it was preventing the CPU2 from booting, leading the CPU1 application to go in error. I might also have been mislead by the application note AN536, page 14, where we can see the box checked.

I solved my problem by simply unselecting "Halt all cores" in the debug configuration. The Reset driven by the debug launch affects both cores simultaneously, so they're starting together anyway.