Code Corrupted after full discharge of batteries, upon reboot. NRF51822 SDK 12.3

[Robin]

Hello Nordic Wizards,

We are in the final throws of a project preparing to go to market.  However we have identified a "strange" problem.

if the batteries driving the board power are allowed to fully discharge, once they start recharging, plugging/unplugging the board from a charger resets the board and may lock the code up in an unknown state.  If the board is reprogrammed, this condition stops, until the next time the battery/board is fully discharged.  Has anyone see these types of problems with this chip, and/or can you point me to a prospective solution.

Thank you kindly

Robin @ TL

[daviddedwin]

1. Please state the chip markings on the nRF51822
2. You should try this on an additional board if that is possible.
3. Read the flash on the chip after a failure to see if there is any difference before and after the condition occurs, the nrfjprog utility will help you read the chip flash.

[Robin]

Hello David,

I assume you are the assigned Nordic Engineer, No?  Anyway

The chips are marked "N51822/QFAAH3/1906EP.

The symptoms occur on all boards (10 each).

I will likely need some help using the nrfjprog utility.

One of our US field agents is suspicious of power circuit issues.  We are running the board/chip at 2.8V, with a precision 2.048V Ref applied to AIN0.   Can you please enumerate the settings I need to insure are correct for proper power management to occur?

Thank you kindly,

Robin @ TL

[Kenneth]

if the batteries driving the board power are allowed to fully discharge, once they start recharging, plugging/unplugging the board from a charger resets the board and may lock the code up in an unknown state.

A few things come to mind. Likely the internal power en reset does not trigger as expected. Do you have any measurement on the time to ramp up VDD during charging? There is a max 60ms rise time I believe allowed by spec. 

Are all GPIOs also low level while VDD is discharged? Just checking that the chip is not partially powered through a pin before VDD rise above minimum operating conditions again.

Does adding a 1Mohm resistor between nRESET and GND have any impact on the issue? 

Best regards,

Kenneth

[Robin]

Hello Kenneth,

No measure on VDD ramp up rate.  I would think (hope) there were a comparator that held off ops until well above the chip min op voltage.  Never seen a spec like that on a chip this sophisticated before.  But, the board should be up within a 200 uSec based on regulator and cap specs.

If batt/board are dead, can gpios be high?

Haven't tried nReset resistor as we are using the pin as SWDIO to program the chip, and is no such component on the reference design circuit we have from Nordic.

[Kenneth]

Please measure the VDD ramp up time when charging to confirm if rise time is within specification.

Regarding the suggestion to try with a 1Mohm resistor on nRESET, it would help if you can do this test, since it would help understand if missing power on reset is part of the problem or if it is something else.

Robin said:

If batt/board are dead, can gpios be high?

I don't know your design, I am asking if you have secondary power or sensors in your design that may feed a gpio with power even if VDD is discharged.

Also test suggestions by David.

[Robin]

Hello again Kenneth,

1.) Please let me know where I can find this VDD ramp up spec.

2.) If I am not using pin as nReset, why would this help?

3.) No secondary power in system.

4.) I am not sure how to implement flash content test around a battery discharge, as the system is unusable until reprogrammed.  Any guidance here is greatly appreciated.

5.) What software features must I check to be sure the chip powers down safely with battery discharge?

Thank you again,

Robin@ TL 

*** New Info:

1.) I have completed the VDD ramp test.  It is up to full voltatge within 300uS, as I suspected. 

2.) I also tested quick discharge of battery (~20mS).  Symptoms remain the same.  Once discharged, the code does not start when a charge source is initiated.  Removing the charge source and resetting board power allows the code to start, adding the charge source back freezes the code.  This continues until the chip is reprogrammed.

3.) After adding the pulldown to the nRESET pin, there is a change is symptoms.  The chip will not reboot and run even after a board power reset.  It only runs after a reprogram.

Stand by for flash content testing...

[Kenneth]

Here is a snippet from the spec:

Based on your current description I am not quite able to understand what may be causing your problems here, are you able to share schematic of the design? It is possible that the nRF51 is actually starting running code, but it stops during initialization due to code is waiting for something (e.g. external sensors), can you add a LED blink on the start of main() to check for this?

Can you share a plot of VDD when it starts to charge? I just want to check if there is something we are missing here. 

Robin said:

3.) After adding the pulldown to the nRESET pin, there is a change is symptoms.  The chip will not reboot and run even after a board power reset.  It only runs after a reprogram.

 And you can confirm it is a 1Mohm, and not for instance a 1kohm?

[Robin]

Hello again Kenneth,

I could send you a plot of VDD rise and fall, but I will for now ask that you believe me.  The rise is <300uS, the fall is > 100mS.  I will send you the schematic, and those plots when I get down to the system later today, but first I will need to change this case to private, if I can remember how.

The resistor is indeed very high value, but not exactly 1 Megohm. 

The symptom I mentioned, I have found to be somwwhat erratic, ie sometime appears and others not.  The only consistent symptom is that after a discharge, when plugging the board into a charger, the code freezes.  Sometimes it restarts when unplugged, other times it does not. 

Right now, what I am most concerned with, is whether or not I have the chip properly configured for Low Voltage mode at the voltages the board is designed to use, and whether I need to write any code to insure a safe power down.  Again, can you please enumerate the firmware requirements to do so?

Thanks ad nauseam,

Robin @ TL 

[Robin]

Hello again Kenneth,

I cannot insert these graphs of VDD Rise and Fall.  This page says they are unallowed.  How can I get them to you?

Robin @ TL