cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F767 NRST held to VSS

ombedko
Associate II

I have a custom PCB based on STM32F767 which has been working for about 2-3 weeks, through about 100 re-programming cycles (doing debugging). Now, after last attempt to flash, the NRST pin is "stuck" to VSS. I lifted the pin of the trace, e.g. NRST pin of MCU is now not connected to anything on the PCB anymore. The PCB's NRST trace is measured to 3.3V, while the NRST pin of the MCU (no longer connected to anything) is now 0V. 

 

If I measure resistance between NRST pin on MCU and VSS pins (connected to GND) i get ~0.5 ohm (probably not accurate reading, but lets call it "low ohmic resistance"). 

 

Since the NRST pin is free floating (literally up in the air, off the PCB), and still measured at 0V wrt VSS, it seems the MCU's internal NRST mechanism is now fused to VSS?

This is the second identical board this happened to. The previous board also functioned for weeks, before breaking in exact same way. 

I suspect it has to do with I built the ST-Link interface (using spring loaded TAG_CONNECT connetor). I may have disconnected the ST link while the PCB was powered on (though not while flashing, obviously), don't see why that should brick the MCU, but I have no other explanation. I cant see anything obviously wrong in the design thoguh ...

Any help would be much appreciated:

ombedko_0-1714459993897.png

 


BTW: Measured VDDA to 3.3V and both VCAP pins to 1.13V, PDR_ON tied to VDD(3.3V) and BOOT0 pulled down to VSS by 10k.

Edit: Highlighted the NRST net

Edit: pdf schematic added




12 REPLIES 12

If the MCU is powered it's never a good idea to either connect or disconnect a JTAG/SWD debugger.

PGump.1
Senior

I would conditionally agree with @david Littell…

 

If your target MCU and debugger don’t share a come ground, yes, this can be problem. If you have a project where you need this functionality, then use a connector style that connects the GND signals first. Or, setup a procedure, perhaps with a cliplead, that achieves the required result.

 

If your debugger is powered by the MCU’s VCC – connecting the debugger will cause the VCC to dip momentarily. This dip will lower the MCU’s latchup immunity proportionately, which can be problematic, particularly with IO pins that have caps connected. If you need this functionality – diodes can be your friend…

 

I hope this helps.

 

Kind regards

Pedro

 

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.

Thanks again for all the input. In my case, the ST Link is connected via a 10pin cable which includes common GND between my PCB and the debugger. 

Not connecting/disconnecting while the MCU is powered seems like a good advice in general, and is by no means required for my current application. I've previously worked with much simpler Microchip MCU's for which I would routinely connect ICD/programmer while the chip was already powered (without any consideration to this on the PCB design), so I did not consider that this could potentially damage the STM32 MCU I'm now working with.

As for protecting the MCU against this problem, would something like this work?

ombedko_0-1714640382435.png


In my current design (of which two prototypes now was broken due to latching NRST pints) I already have in-line resistors for the SWD and NRST signals (they where 22ohm as per STM's design guide, but I uped them to 100 now). If I clamp all four signals with a BAT46w(0.3 Vf) Schottky, that should prevent the SWG signals and NRST pin of the MCU getting pushed above Vcc.

I see now in the ESD guidelines of STM's AN5612 appnote they suggest another setup for ESD protection using a 4channel TVS, but that would not protect against this specific case where the ST-Link is applying voltage to NRST or SWD pins above the MCU's Vcc (e.g. the PCB is not powered).

Im not too worried about ESD for this project in general as it will be mostly used in lab conditions, so protection against inadvertently messing up the connection procedure for ST-Link debugger is more important.

From what I have learned in this thread, it should be safe as long as:
1. The MCU is powered down during connect/disconnect of the ST-Link
2. No programming from ST-Link is done while the MCU is powered down