STM32F767 NRST held to VSS

[ombedko]

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:

 

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

[PGump.1]

Hi,

Your diagram is not clear here. However, it is most likely that the NRST pin has failed due to Lactchup. This is usually caused by a bias voltage placed on the NRST pin when VCC is transitioning from 0 to 3.3V...

I hope this helps...

Kind regards
pedro

[ombedko]

Thanks for that. If I understand correctly, you mean there have been a high voltage (=bias?) input from the ST link while the Vcc was transitioning? In normal boot-up of the MCU I thought the onboard POR should manage this situation, e.g. hold the MCU in reset until Vcc stable (PDR_ON is connected to Vcc in my circuit). 

Is it plausible that this situation could arise from mistakenly disconnecting the STM while the MCU was powered up? Trying to understand why this happened, if its some "finger problem" on my part while working on the board, or a design flaw in my PCB that needs to be corrected.

Edit: Could it be a power design issue? I dont have any chokes or any TVS protection or similar on the power input. Its a 5V bench supply with a LM1117 3V3 LDO regulator on it (with decoupling and tank caps ofc).

[PGump.1]

Hi,

Any system where pins are interconnected between parts of that system that are powered separately, need additional design consideration.

In your case, a possible scenario could be - Your ST-Link is powered up (via USB), you plug it into your board while VCC is 0V, then turn your board On...

Without knowing what the NRST drive circuit is, I can't solve this for you. However, often just a clamp diode between the pin and VC is enough, but it may also require a series resistor...

I don't connect the NRST to ST-Link. I use the software reset option.

I hope this helps.

Kind regards
Pedro

[ombedko]

Thanks again for your input. It is very helpfull.

I attached my full schematic in PDF form to the original post.

The ST-Link pins are connected via 22 ohm resistors, including the pin that goes to the NRST pin on MCU (based on some reference design I worked from). There is no other drive circuit on the NRST other than a 10k pullup and a 100nF debounce cap, which I believe is  correct according to design guidelines? I do have a pushbouton that pulls NRST to GND for hard reset, but with the debounce cap and the pullup, that should be fine, I would think...

Interesting about not connecting NRST, I didn't know that was possible. I can do that too by removeing the 22ohm resistor on the NRST line from ST link interface.

[ombedko]

Another guess:

Re-reading the design guidelines, I see some mention of potential latchups caused by VddA comming up after Vdd. In my design I power VddA through a ferrite bead (again based on some reference design, which may or may not be good), with  100nF decoupling. I am missing the recomended 1uF additional cap on VddA.

Could a ferrite bead in serries powering VddA cause something like this?

I gues not since the "getting started" guide recomends it (I dont have the 47 ohm resistor t Vref though):

 

[PGump.1]

Hi,

Although Latchup can cause chip-wide damage, the damage is usually limited to the pin(s) affected. Chip-wide damage often comes with over current, over temperature, and sometimes smoke... Most modern silicone fabrication techniques have an inherent damage limiting characteristic.

For the NRST limit resistor, I would use the maximum resistance that still gives the logic low requirements for the RESET function.

I hope this helps...

Kind regards
Pedro

 

[ombedko]

Thanks for the input. I added the missing tantalum cap on VddA and used 100 current limiting resistors in series with the SWD and NRST signals from ST Link. Lets see if that prevents another latchup of NRST :) Curious problem thogugh. Ive not seen damage to MCU's from disconnecting in-circuit debuggers before (assuming ofc thats what this is...).

[PGump.1]

Hi,

I think you misunderstand - it is NOT disconnecting that is the issue. It is connecting, and the power On sequence that is the issue...

Kind regards
Pedro

[ombedko]

Ah, thanks for the clarification. So that means one should not connect the JTAG while the MCU is powered off? Or indeed power off the MCU while the JTAG is connected? (Sorry for beeing slow about this :D I have not so much experience with the STM32 familly. Other MCUs Ive worked with was not particularly sensitive to the order of connection/power up)

 

[David Littell]

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

[PGump.1]

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

 

[ombedko]

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?

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