2026-02-03 8:51 AM
In an effort to track down an unrelated problem, I switched back to using my H7 DISCO board and the HSEM_CoreSync sample application. If I debug only the CM7 code, or only the CM4 code, I can step through any/all lines. However, if I try to multi-core debug, single stepping on the CM7 says it is performing a step:
(before hitting F5)
(after hitting F5)
but it really doesn't. As you can see by the left red circle, it claims it is performing a step. In reality it did not step into MPU_Config, it actually performed a continue and is in the Error_Handler call shown in the right hand red circle.
Even if I set breakpoints in MPU_Config, hitting any step/continue button will cause it to skip the breakpoint(s) and end up in the Error_Handler. Pausing the CM7 shows the stack as calling that instance of the Error_Handler, and the Fault Analyzer always shows no faults.
The compiler options are all set to maximum (-g3), so this shouldn't be a problem of trying to debug optimized code.
Does anyone have a solution to this problem?
Thanks
C-Coder
2026-02-18 12:22 AM
Hello @C-Coder
Let me thank you for posting.
I recommend that you take a look at this Knowledge Article.
It shows how to implement inter-processor communication between CM7 and CM4 cores on the STM32H7 series using the hardware semaphore (HSEM).
Thanks.
Mahmoud
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2026-02-18 5:29 AM
Thanks for the response, but I recommend you re-read my post. I'm using an ST demo board and an ST demo application. Also, my problem in this post isn't about the communication between the two cores, it is about the fact that trying to perform a STEP does not work.
Thanks,
C-Coder
2026-02-19 6:40 AM
Hello @C-Coder,
Run the CM4 target first => The domain2 will go in Stop mode (and thus, the M4 CPU in DeepSleep mode). Then, you shouldn't end in the ErrorHandler
If this comes after a reset, it should be because you have reset from the M4 target => the M4 has stopped on its Reset_Handler function or on the start of its main function. The M7 has started and felt in the Error_Handler. In this case, reset from the M7 target.
Anyway, be aware of the limitation 146043 concerning STM32CubeIDE. The workaround to avoid this is to always reset from the M7 target.
Best regards