Skip to main content
O'li
O'li
Associate II
January 28, 2020
Question

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

  • January 28, 2020
  • 4 replies
  • 1343 views

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?

This topic has been closed for replies.

4 replies

Tesla DeLorean
Tesla DeLorean
Guru
January 28, 2020

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

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
O'li
O'liAuthor
Associate II
January 29, 2020

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
AShri.1
Associate
February 18, 2020

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
O'liAuthor
Associate II
February 18, 2020

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.

Terms & ConditionsAccessibility statement