STM32CubeProgrammer gives error: "No STM32 target found!"

[APagl]

I have a custom board with one STM32H743ZIT6 (“Control MCU�?) and six STM32H7V43VIT6 MCUs. The idea, eventually, is for the Control MCU to reset the six slave MCUs.

Right now, after an initial flashing of the slaves with a “bring up�? blinky program they run after reset. However, I cannot now flash anything to them. For example, in SW4STM32 Workbench on my MacBookPro ….

With the debug cfg file with “Connect under reset�? or “Hardware reset�? or “Software system reset�?, I get STLINK_SWD_AP_WDATA_ERROR and auto_probe failed errors in the console.

So, I now have STM32CubeProgrammer installed, version 2.5.0. Besides it’s randomly crashing from time to time, when it behaves, I cannot connect to any of the slaves. CubeProgrammer gives the error: “Error: No STM32 target found!�?

BTW, each slave MCUhas a 10-pin JTAG connector properly wired up (3.3V from the board, GND, SWCLK, SWDIO, SWO, RST). I have done connectivity tests along the route from the ST-LINK/V2 module all the way to the 10-pin header connector.

After Googling around, I seem to get the impression that I should use CubeProgrammer to erase the MCU and reload with the debug pins configured (via, for example, CubeMX). However, since I constantly get the No STM32 target found upon trying to connect to the MCU, I seem to be stuck. 

The slaves have their NRST pins pulled down with 10K (so that the Control MCU can reset them when needed).

I see things that suggest pulling RST high or BOOT0 high, but I’ve tried those while trying to connect via CubeProgrammer. 

Questions:

• Do I indeed want to first erase the the chips?
• How do I do that if CubeProgrammer can’t find the MCU?
• Do I then want to configure code with the debug pins set up and flash that?
• How do I flash that new code if CubeProgrammer (or evidently SW4STM32 Workbench) can’t find the MCU (which is what I assume “auto_probe failed�? means)?

Any way out of this Catch-22?

Thanks.

[Tesla DeLorean]

NRST is driven internally with an Open-Drain, you're supposed to pull-up, and NEVER drive the signal high with a push-pull on this or other parts of the circuit.

Pulling BOOT0 High allows the ROM loader to run, preventing errant user code running.

Does your code interfere with the JTAG/SWD pins, disable the interface, or go into low power modes?

Getting the SMPS/VOS settings wrong can make it very difficult to connect to the core.

If you can't get in via JTAG/SWD, you could try other ROM loader methods via USART

[TDK]

If these are brand new chips, there should be no need to erase/configure anything before you can connect with SWD. Try a lower SWD clock speed.

The SWCLK/SWDIO lines for each header are only connected to a single chip, right? Not the same net for all chips?