Weird Issue observed with Nrf52832

[VishnuGS]

Hello,

We have a custom board with nrf52832. We have seen a problem during production. Our process is as follows (the below steps are ran in a script),

1. We recover the board

2. We flash a HQ test application FW for hardware quality check

3. We run the test

4. We erase the board

5. We flash application FW

6. Enforce read back protection

7. Ship the units.

We received reports that Hardware quality checks are failing for lot of devices.

So, we took few of our production devices and ran the tests with it. 

Procedure 1:

As our production units have Application Firmware(with read back protection) loaded onto them already, we perform the above mentioned steps, the success rate is below 80%

Procedure 2:

We take the units, recover them and kept aside for 15 minutes, then we perform the above mentioned steps. The success rate is 100%

I could not understand the difference in approach of,

1. Having erased board when it powers up helps to pass the test always

2. Having App FW on it when it powers up -> recover it ->perform the test ->fails.

I have tried the following steps to understand the problem ( Having APP FW preloaded when device powers up)

1. Recover -> Recover -> reset -> Test -> fails

2. Recover -> eraseall -> reset ->  test -> fails

3. Recover -> Recover -> eraseall -> reset -> reset -> test -> fails

4. Added delays between steps to see no improvement

5. Assumed Script might have issue, So performed the manual steps using command line tools and Putty for serial -> fails

Specifics:

1. Main APP FW uses SDK 14.2 and SD S132 V5.0

2. Test FW uses SDK 13.0 and SD S132 V4.0.3

3. Our Custom Board has big bulk capacitors on them, so I chose to discharge the board (wait for 15 minutes as mentioned in procedure 2)

Even after we recover the board is there any way that Main APP FW has impact on HQ Test FW?

Can you help me understand 

Recover -> wait for 15 minutes -> Recover -> Flash Test FW -> Reset -> Test Run -> SUCCESS

Recover->Flash Test FW -> Reset -> Test Run ->Fails (20% failure rate)

Thanks.

[Nguyen Hoan Hoang]

Recover from protection or set protection or any change for the reset pin or NFC pins requires a full reset, either by power cycle or hard reset

[hmolesworth]

To add to Nguyen's reply there are some power issues to consider. Once the power supply is removed or switched off the bulk capacitance you mention starts to discharge. Once that capacitor voltage falls below some magic figure the nRF52832 will no longer be executing code and all port pins are in reset condition and so do not dissipate power; this means current consumption is extremely low, just a few 10s of nA. Note the voltage on the bulk capacitance has not discharged completely yet, and the voltage is high enough to prevent the nRF52832 reset circuitry from properly operating, so it is possible to restore power, fiddle with recover tools but yet be unable to actually get a working product.

The Work-around

The 15-minute delay allows the bulk capacitance to discharge below the magical reset voltage minimum-level-to-work-at-all, so now fiddling with tools and reprogramming works fine. Note that the discharge to near zero of the bulk capacitor is likely not through the nRF52832 draining the capacitor, but by other circuit elements - including capacitor leakage - which are likely to have higher leakage than the nRF52832 itself at low voltages of less than 1 volt.

The Test

Turn off the power and immediately short all the bulk capacitors with a Gnd wire thus discharging them, Immediately switch back on and verify the recover-program procedure you are hoping for without using a 15-minute delay.

The Fix

Add a crowbar, either on-board or off-board. This is a means of short-circuiting the capacitor to discharge quickly. Some regulators have this built-in, but most don't and an external FET or other dummy load is required. It doesn't need to be a short-circuit, just a low enough resistance to discharge all capacitors in the required time. Some capacitors are before and some after regulators, so some circuit knowledge is required.

Stuff to Watch For

Any external device or circuit - say an FTDI serial link or a J-Link debugger tool - will add to the problem as they back-drive any parts of the circuit they are connected to making the problem worse and discharge slower, and can even prevent any reset and recover at all. If not already disconnecting the programmer when power-cycling then doing so may even be a simple fix.

Nordic engineers have to look after the reindeer and gifts this time of year, but when back they might have some voltage figures to quote; I don't think the data sheet can be relied on here as the figures we need are not really specified, but the required discharge voltage is pretty low maybe 400mV or less.

[VishnuGS]

Hello Nguyen Hoan Hoang,

Thanks for your reply.

Did you mean,

Option 1:

Recover(from preloaded APP FW) -> --pinreset -> Flash HQ Test FW -> --reset -->Test

or 

Option 2:

Recover(from preloaded APP FW) -> Flash HQ Test FW -> --pinreset --> Test

And you do you mean by,

Since I am not doing hard reset, Even though I recovered from Main App FW, Normal Operation can not be guaranteed with my HQ Test FW?

My Second procedure as mentioned in the ticket description where I try to power cycle the board helped to get it work?

Thanks again for your response. 

[VishnuGS]

Hello hmolesworth,

Thanks for your reply.

I will consult my HW engineers to see a quick way of discharging my bulk capacitors.

About, J-link circuitry disconnection, I have tried that.

In my Second procedure, while waiting for 15 minutes I disconnected my custom board with all other external circuitry.

Thanks. 

[Nguyen Hoan Hoang]

Option 1. A hard reset is required after recover.

option 2. will not work reliably