STM32H745 STLINKV3 SWD won't connect at 24000 KHZ

[Joyabb]

Hi,

We have build a custom board with STM32H745XIH6. I am using STLINKV3 debugger over SWD interface to connect to the target. When I connect to the board for the very first time, the STLINKV3 is able to connect at 24000 KHz clock using both STM32CubeProgrammer and STM32CubeIDE. Once I load any firmware on the flash and run it, the debugger is never able to connect to target using 24000 KHz. If I down the SWD frequency to 8000 KHz, everything works as normal.

Our first assumption was that the running firmware is affecting the SWD lines, and not allowing it to run at 24000 KHz. We did a mass erase of internal flash, to bring the board back to factory setting, without any firmware. The strange part is that even in this configuration, the SWD can not connect to target at 24000 KHz. It only works at 8000 KHz.

Anyone knows any reason for this observation?

The STM32CubeIDE shows following error.

STMicroelectronics ST-LINK GDB server. Version 5.7.0

Copyright (c) 2020, STMicroelectronics. All rights reserved.

Starting server with the following options:

Persistent Mode : Disabled

Logging Level : 1

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Disabled

SWD Debug : Enabled

InitWhile : Enabled

ST-LINK Failed to get target status

Error in initializing ST-LINK device.

Reason: Unknown. Please check power and cabling to target.

Thanks,

Joyab

[Uwe Bonnes]

It seems you are useng off-board connection. You do not tell what cables. But often refections, capacitance and ground bounce defeat connection at high speed.

[Joyabb]

We are using Tag-Connect cable to STLINKV3 debugger SWD lines.

[Tesla DeLorean]

Yeah, not sure here, the core should be able to sustain 24 MHz unless you're reconfiguring the clocks in your code

If pulling BOOT0 High whilst cycling the power makes the problem go away then it is likely your code causing an issue.

On the H7 the reset via NRST is not thorough, also note that unsuitable LDO/SMPS and VOS settings can also cause the core to block. The symptom here is complete non-responsiveness, and is recovered by a few power cycles into the system loader via BOOT0=HIGH