SWD interface locks up after cold reset with user code, works after warm reset.

[Robert Sexton]

I've got a strange problem. My custom-built board has SWD problems after cold reset with my code. I don't think that my code is directly responsible for altering the SWD interface.

I'm using an in-house SWD probe that has a long history. JTAG/SWD are my areas of professional expertise. When SWD fails, I mean that SWD initialization fails at the lowest level - the SWD interface doesn't respond to the initial SWD probes.

Heres what I know:

• SWD works when I assert BOOT0 and use the in-rom boot loader.
• SWD drops out when I reboot into my code.
• If I add a software breakpoint to my code after all SOC hardware init, SWD keeps working, and works after I remove the breakpoint.
• If I cold reset the board SWD fails.
• I've verified that the code readout protections are not turned on when the board is in an unreachable state.

My best guess is that something is going wrong with the DAPCLK. My code is already using SRAM4, so I know that D3 is powered up.

My board is modeled on the STM32H725 dev board, although I'm actually using a STM32H735. I'm using the oscillator and clock config from that project. I get the same results with the auto-generated clock config from the STMCube utility.

[Robert Sexton]

Added: I've also checked the DBGMCU registers. They are the same in both cases.

[Robert Sexton]

There don't appear to be any applicable RCC registers.

[Robert Sexton]

Also: JNRST is in Alternate mode #0, so hooked up. I can ground it and see the IO change. It has no effect on the state of SWD.

[Piranha]

Everything points to your code just failing at initialization. Most likely some issue with configuration of clocks, buses or FLASH. And yes, HAL/CubeMX code is a broken bloatware.