No response from SWD on STM32H750VBT6 V

[Fitzharrys]

Hi. I am running out of ideas with this problem. I have an STM32H750VBT6 V on a custom PCB. A previous version of this circuit (v1) and PCB worked just fine. I made some minor circuit fixes and improvements and modified the PCB from a 2 layer to a 4 layer design (v2). I am unable to get any response from SWD on the v2 (confirmed down to electrical level).

All VDD, VBAT and VDDA have 3.3V, all VSS and VSSA are connected to ground. Verified from circuit voltage levels and from meter continuity. All the 100nF and 4.7uF capacitors are in place very close to the MCU. I have reset and BOOT0 wired to microswitches. When I press reset, I can see activity on some pins - rising to near 3.3V shortly after reset, with some digital activity, for example on pin 92, PB6. I take this as proof that the bootloader is attempting to make contact with peripherals, which are mostly not wired in. USB however is wired in, though it never appears as a USB device for DFU on my host (that's not my main issue right now).

I want to connect to it using SWD, which is wired in similar way to the nucleo board, with an ESD device, leading to a 4 pin header, which is connected with very short (~5cm) flying leads to a genuine ST Link v2. I am testing with STM32CubeProgrammer. This exact method communicates fine with my v1. I have tried various speeds, fast and slow, and connecting under reset and not. In all cases there is no response. Using a scope I can see the SWD "conversation" on SWCLK and SWDIO on the MCU pins. They look the same between my working v1 and my non working v2 up to the point that SWDIO goes high impedance for the board to respond - then there is nothing from the v2 board. Voltage levels and rising and falling edges look very very similar between the working v1 and the non working v2.

nrst remains consistently high except when I press my reset button. I can see very close to 1V on VCAP1 and VCAP2.

I have tried replacing the ESD device with 22R resistors for improved impedance matching to no avail. I admit I have not carefully considered the impedance of the SWD traces, but they are very short, and as I say, things look good on my scope.

I have built 3 of the v2 boards, which all behave the same way - no response to SWD. This seems to rule out build issues or a single duff MCU.

The MCUs on my v2 boards are from Aliexpress, as I was not able to source them any other way. Could there be a bad batch? The MCU on my working board came from a different source a year previously so maybe is a different batch.

The minor circuit improvements between v1 and v2 are things like: VDDA is derived in a different way in v2 (but clearly present), I added a BOOT0 switch, I removed an unneeded HSE crystal, and fixed a couple of errors. This doesn't seem material.

The analogue circuitry you see on the PCB and the schematic is not populated, other than to provide VDDA.

The MCUs are new so not previously programmed, therefore, I assume they reset directly to the bootloader regardless of BOOT0. I don't see any way the SWD pins could have been reprogrammed to IO, which in any case connecting under reset would solve and doesn't.

Update: I've added a photo of my scope showing the edges on SWCLK and SWDIO at the chip. The time scale is 20ns and 0.5V per division. It looks pretty clean to me.

Ideas?

[RhSilicon]

I had something similar with STM32F407VGT6 where the ST-link V2 could no longer find the MCU. And I hadn't done any hardware modifications. I was using Linux and STM32CubeIDE, so I came up with the idea of using the STlink Utility Tool for Windows, and it was the only Software that managed to find the MCU again. After performing the complete MCU Flash Erase using STlink Utility, the STlink recognized the MCU again using Linux.

A tip for not having to handle the BOOT0 pin on F4 (I don't know if it applies to other lines) is this:

Note: If the pins PA13 (SWDIO) and PA14 (SWCLK) are used (configured for another option other than the default state) it may prevent the ST-Link from working, to solve this problem, keep the BOOT0 (pin 94) in logical state high (3.3V) before energizing (reset the microcontroller). To not need to manually change the BOOT0 pin, keep the pins PA13 (SWDIO) and PA14 (SWCLK) unused, it also cannot be configured as input.