2023-01-15 08:47 AM
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?
Solved! Go to Solution.
2023-07-25 12:43 PM
In case anyone comes across this old post and wonders how I fixed it - I ordered some MCU chips from a reputable supplier. They took 6 months to come (supply chain), but the circuit works perfectly now. So the issue appears to have been the chips I sourced via AliExpress. Either they were faulty, or preprogrammed in some way that prevented SWD from responding.
2023-01-15 09:16 AM
Your SWD pinout is minimal = miss NRST line
Used U4 IC for protection seems not bee good remove it and solder jumpers 43 16 pins.
BOOT0 read AN2606 for boot patterns
FYI USB bus is impedance low system = impossible for SWD
2023-01-15 09:24 AM
I can manually hold reset during SWD connection, with no success. With my v1 board, I didn't need the reset line in SWD.
As I said I replaced U4 with two series 22R resistors (and also two series 100R) resistors to no avail.
BOOT0 is documented as high for bootloader, low for flash boot - but there is nothing in flash so I assume it boots from the bootloader either way.
2023-01-15 09:38 AM
Read AN2606 on H7 BOOT0/1 use option addr0/1 for start and default is ...
remove 10k from SWCLK and IO and place 0R instead U4 , check if you dont swap CLK and IO on v2 ...
And NRST is more better connet to STLink ...
Last if you have short circuit on U4 then you kill MCU or STLINK
2023-01-16 03:19 AM
I tried removing the 10K pulldown in SWCLK, replaced U4 with a pair of 0R resistors, and wired nrst to SWD and tried connecting with a hardware reset. No joy.
It's hard to believe that three boards could have a faulty U4 that would blow them up?
I see the right signals on the pins of the MCU for clock and data, so I don't think they are swapped.
2023-01-16 03:24 AM
No hardware reset, but change connection mode to under reset
And remove tooo pull UP to Vdd 10k on SVDIO and maybe show photo image how you replace and connect ...
2023-01-16 03:50 AM
Yes, I changed the connection mode in STM32CubeProgammer to connection under reset.
2023-01-16 03:57 AM
If this all not help then last test is replace IC from working v1 to v2 and handle if problem is fake ICs or PCB , ofcourese you can place new ICs into v1 ...
too VDDa is critical for internal clock need stable and right sequencing on power on.
2023-01-16 04:00 AM
VDDA is present and correct, looks good, and I have tried different sources for it.
Could be a fake IC - though as I say, I do see encouraging activity on some of its pins. Resoldering is hard work, perhaps I will order one from a reputably supplier on back order.
Thank you for your suggestions.
2023-07-25 12:43 PM
In case anyone comes across this old post and wonders how I fixed it - I ordered some MCU chips from a reputable supplier. They took 6 months to come (supply chain), but the circuit works perfectly now. So the issue appears to have been the chips I sourced via AliExpress. Either they were faulty, or preprogrammed in some way that prevented SWD from responding.