Hi,
I'm using STM32CubeIDE 1.3.1 (6291_20200406_0752) with a STM32H7A3 Nucleo Board and have problems after enabling SWV when the CPU sleeps. If I click the "Start Trace" button in the SWV Console and then continue execution the processor halts, all registers read as 0xA05F0001, and the debugger console outputs:
Program received signal SIGTRAP, Trace/breakpoint trap.
0xa05f0000 in ?? ()
If I single step continue, the debugger seems to behave correctly again, and the registers display expected values again. Searching on 0xA05F0001 locates several descriptions of it being a default value returned by the DAP when the relevant power domain is not enabled (e.g. https://community.st.com/s/question/0D50X0000BSasPE/buggy-example-project-stm32cubefwh7v150projectsstm32h747idiscoexamplesgpiogpioextiewarm)
If the CPU does not sleep, then the problem is not observed. If SWV Trace is not started, the problem is not observed and the code runs happily between sleeping and servicing the systick interrupt.
If I manually enable the DBGSLEEP_CD bit in DBGMCU_CR after clicking "Start Trace", and executing then I don't observe the problem. If I enable DBGSLEEP_CD manually and the click "Start Trace", I notice (after a single step to force re-read of registers) that the DBGSLEEP_CD bit has been reset. I suspect that STM32CubeIDE is resetting this bit when it attempts to enable the TRACECLKEN bit?
Is this a bug in STM32CubeIDE, or am I missing a setting somewhere? I have "Debug in low power modes" enabled in my debug configuration, which would be my obvious guess for relevant configuration. (And I see the same behaviour if configured for "No configuration" or "Disabled" as well.)
Thanks,
Paul
