Questions about standby current defects during production

[pkr2258]

hi

We have developed it to the specifications below and are preparing for mass production.

We would like to inquire about a 10% standby current test defect occurring in pre-production (100EA).

1. Specifications

- nRF52832

- SDK 17.1.0

2. Self-review results

- PCBs with standby current defects continue to defect (100%)

- Normal PCB with no standby current defects continues to be normal (100%)

- If you retouch the nRF52832 IC with a heat gun, the standby current will return to normal for a while and then increase again.

- Changing peripheral devices such as crystal, LDO, etc. does not solve the problem.

- Normal current: 100uA -> defective PBA 230uA

=> Is there anything you can guess as the cause?

[Sigurd]

Hi!

Did you try to do a swap test?

Take 1 good unit and 1 bad unit.

Then take the nRF52832 from the bad unit, and place it on the good unit PCB.

Then take the nRF52832 from the good unit, and place it on the bad unit PCB.

Then check if the behavior follows the nRF52832 or the PCB.

[pkr2258]

HI

I tried replacing the nRF52832 on the defective PCB with a new chip, but the result was the same.

And as you advised, I replaced the defective and good PCBs, but the same symptoms still appear.

Whether you change a defective PCB to a new chip or replace a chip in a good PCB, it is always defective.

However, if you look at the PCB alone, you cannot tell the difference between a good product and a defective product.

Even though ICT was used, there was no difference between defective and good products.

And the differences in the PCB cannot be found with the naked eye.

Under the circumstances, it is true that the defective symptoms follow the PCB, but I cannot understand the reason.

Is there any way to get to the root cause through debugging mode or other methods?

[hmolesworth]

Pin 13 VDD appears to be unconnected, which may affect operation though not in a predictable manner. Worth setting all 32 i/o pins to outputs and pull-ups disabled and drive all 32 pins low (unless some other circuit disallows that) and measure the supply current; it should be very low; is it different?

[pkr2258]

HI 

I found the cause of the rising quiescent current on some PCBs.

.

In conclusion, the cause was current consumption at the UART's RX Pin.

.

1. Basic settings

- HW

In UART PIN, a 1k ohm resistor is connected directly to the connector in series.

( Pull-up/pull-down resistor not used )

.

-SW

buttons_leds_init(); 

NRF_UART0->TASKS_STOPRX= 1;
NRF_UART0->ENABLE = 0;

( In SW terms, RX is stopped to reduce standby current consumption. )

2. Causes and solutions

If you change the RX PIN setting to default, PCBs with standby current problems will also be

The current is the same as that of a normal PCB.

----> nrf_gpio_cfg_default( RXD);

3. Additional questions

I am wondering if the nrf_gpio_cfg_default setting in rxd that I found is the root cause.
Because so far, we have produced PCBs more than 10 times for 100 EA each, and this problem has not occurred.

And, PCBs that have problems will occur, but PCBs that do not will have problems regardless of whether nrf_gpio_cfg_default is present or not.

It works normally.

So, is it possible that there are other factors in the PCB that affect the rxd side?

I have this doubt. Is declaring nrf_gpio_cfg_default the fundamental problem and solution?

[hmolesworth]

This issue has been raised dozens of times over the years in one format or another, and relates to a floating Rx pin (sometimes with an external device with separate power supply back-driving the VDD via Rx). The fundamental issue was identified back in 1980 where a floating CMOS or MOSFET input pin can cause feedthrough from internal VDD to GND of typically 130uA when the voltage on the pin floats to the FET thresholds. Why would the input pin float to the threshold voltage? The input impedance on the pin is very high, and any electrical fields or miniscule stains on the PCB from the assembly and cleaning process can cause induced voltage or leakage sufficient to move the input voltage to the FET threshold. The nRF52 series input pin has effectively a bus-hold feature, details unknown, but this does not stop the pin from floating due to such external effects. The solution is trivial in many cases, as you note: simply enable the internal pull-up to remove effects of stained board leakage (or high-humidity leakage) and remove the power from an external device or use a level-shifter in the case of a connected driver. In my view the problem historically arose from all the nRF52 examples using the default uart settings with the pull-up not enabled, both in the SDK52 and nRFConnect. Why is the Rx pin more susceptible than other unused pins? Typically there is a trace on Rx to a connector or other device, so it is more susceptible to stain leakage, whereas usually there are no traces on unused pins.

See my notes here: potential-risks-if-voltage-is-applied-to-a-gpio-pin-when-the-chip-is-not-powered-vdd-0-0v

TI App Note on Feedthrough: App Note scba004e

Other ways to handle unused input pins - set them as active low outputs and drive low. Does this increase sleep current? No, and I quote (my measurements):

// Here are my measurement results, which prove the pullup/pull-down resistor is connected to the pin regardless
// of the input setting. nRF52832, 32MHz crystal, no 32kHz crystal, no Reset pin, SoftDevice loaded but not
// enabled, no peripherals enabled, idle. Power CR2032 coin cell, no ground other than PPK-2, no J-Link.
//
// This first table is default port settings after a reset, no changes:
//
// PPK-2  Meter  Conditions
// ====== ====== ==========
// 1.66uA 2.971V with errata workarounds, no i/o
// 1.51uA 2.985V   no errata workarounds, no i/o
//
// This Next table is port settings made after a reset, all 32 port pins identical, nothing connected to any of
// the 32 port pins, no errata applied:
//
// PPK-2  Meter   Direction    Input            Pullup         Drive Level      Sense Level    Output
// ====== ======  ==========   ==============   ============   ==============   ============== ===========
//
// 1.49uA 2.989V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLNONE | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven Low
// 1.49uA 2.999V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLDOWN | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven Low
// 6.47mA 2.894V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLUP   | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven Low
// 6.47mA 2.889V (PIN_OUTPUT | PIN_CONNECT    | PIN_PULLUP   | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven Low
//
// 1.51uA 2.959V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLNONE | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven High
// 6.42mA 2.877V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLDOWN | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven High
// 1.53uA 2.938V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLUP   | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven High
//
//
// This shows setting a port pin into active low output driven low is as good as leaving a pin floating
// when unused, with the added benefit that there is no possibility of port feedthrough if a floating pin
// drifts through the threshold.