I am attempting to use the on-board ST-LINK V3e on a Nucleo-H723ZG development board (MB1364E) to communicate with a STM32H723 on my custom board. I have found what I think is a bug or oversight when I use the MIPI10 connector (CN5) with a Tag-Connect TC2030-CTX-STDC14 to connect the Nucleo ST-LINK to my custom hardware. First, I need to power down the Nucleo H723 processor (by removing jumpers on JP5 & JP4).
The reset signal on the CN5 connector (pin 12 - NRST/T_NRST) is connected to the ST-LINK via JP3. That signal is also connected without any option to disconnect to the Nucleo on-board STM32H7 processor and to the ethernet controller. The reset signal is driven or held low when the Nucleo board is powered up which also does the same to my processor because the signal is the same through the CN5-Tag-Connect cable. Because NRST is low, my processor is also held in reset and the CubeProgrammer lets me know this problem (TARGET_HELD_IN_RESET). When I cut the trace from JP3 that goes to the embedded processor (and continues to the ethernet controller), the ST-LINK debugger is then able to successfully communicate with my processor.
So the question is: why did ST provide an external connector where the reset signal may not respect the external board? I am using SWD so technically I don't need to connect NRST but the cable that I have does so automatically. I realize that I also have many options like cut the pin on the cable, disconnect the reset line on my custom board, etc but the simplest option would have been to provide a SB (solder bump) option to enable the disconnection of reset from ST-LINK to all on-board consumers of that signal. That is similar to what ST does do on the Nucleo-G071RB board (MB1360) with a solder bump option.
What am I missing?
