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
PGump.1
Senior

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

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

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
Senior

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

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

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.

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):

ombedko_0-1714472469430.png

 

PGump.1
Senior

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

 

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.
ombedko
Associate II

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
Senior

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

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

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)