STM32WL5x: unable to restart code on second core

[AJ528]

While attempting to debug code on the Cortex-M0+ core of my STM32WL55 microcontroller, I realized I am not able to restart code execution. I am able to attach to the already-running core in GDB, but when I send the start command, it fails to restart the program with the error Running the default executable on the remote target failed; try "set remote exec-file"?. BMDA error log says Attach failed.

Attempting to load a new program also generates a BMDA warning of remote_v4_adiv5_mem_read_bytes error around 0xe000edf0 but GDB doesn't complain at that point. But it's not possible to step or continue after that point, the execution freezes.

The BMP is version v2.0.0-rc1-47-g3148437e, Hardware Version 6.

The issue can be replicated on a WL55JC Nucleo board. A minimal reproducible example can be found at this github repo, in the bmp_bug branch. The repo has a submodule. Simple compile the code using make, load the code for both cores on the MCU, then reload and try to debug the M0+ core. Even though the M4 core is enabling it immediately, you are still unable to restart the M0+ program in GDB.

Let me know if there is any other information that would be helpful to know.

[dragonmux]

We'll give it a look and aim to fix this for the v2.0.0 final release.. this looks like an issue with halting the target or so as 0xe000edf0 is DHCSR.

When BMDA says the attach failed, this is why start is not happy as while GDB thinks its attached to the core, it's not really if that message occurs. Similarly, when load fails with a DHCSR error, that's why step/continue don't work as target comms is gone at that point.

[mean00]

Not sure this is related but just in case :
I've noticed attach issue when using multi drop target appearing with the change at the bottom
Reverting it fixed the problem for me (i use a chip with a complicated configuration where the target core is held in reset)
Again, this might be completely off topic.

40dd20b
cortexm: Make proper use of the halt checking machinery in cortexm_attach() so we can be sure we actually halted the core before doing things that require it to be halted

[dragonmux]

It is worrying that 40dd20b caused you problems (though this should be a separate issue we think) as cortexm_halt_poll contains code that does a matching operation which is why the removal of that other write was deemed harmless.