nRF51822 requiring re-flash (exposed SWDIO/SWDCLK pins?)

[Mike Robbins]

I am experiencing an unusual and hard-to-reproduce issue with some custom PCBs containing a nRF51822-QFAA, S110 v5.2.1, with 10K external pulldown on SWDCLK, and a 10-pin SWD header. Some of my test units have no physical enclosure, and my test users are occasionally returning the boards in a state where they fail to start the program despite repeated power-cycling. However, on connecting a the programmer, the program still appears to be there (haven't tried to verify contents, but nRFgo Studio shows two code regions). When simply re-flashed and power cycled, the boards successfully come back to life!

This happens even though my program code contains no instructions that erase or write to flash. It also is only happening with my test units that have no enclosure. I haven't yet been able to create a procedure to repeatably enter this state.

1. Is there a possibility that some incidental shorting (or even drops of water!) between some combination of SWDIO, SWDCLK, GND, VCC on the SWD header is causing the Debug Interface Mode to begin, and that this is causing the MCU to enter a state that is not recoverable by power cycling alone?

2. Is some unintended write or erase of the flash memory the only possibility, or are their other non-volatile registers I should attempt to examine?

3. Is there more protection I can provide, electronically or in software, to avoid this issue in production?

I appreciate any leads toward investigating or reproducing this very strange phenomenon! Thanks,

Mike

[Chris]

Dodgy reset lines or similar.. have you been through each of your pins and compared to the standard reference schematics...?

What are they powered by?

[Mike Robbins]

Hi Chris, thanks for the reply. Yes, I also suspect "dodgy reset lines", since nRESET is shared with SWDIO (and is exposed on this header). I could see why this might cause random resets, but I can't see why it should cause damage in a non-volatile way that isn't repaired simply by power cycling. Yes, the board is based on the reference schematics. Powered by 2xAAA batteries directly. Thanks!

[Nguyen Hoan Hoang]

You said it is running on regular AAA battery. Does the unit expose to small shock. Try to fasten the battery securely so it could not move what so ever and retest to see if the problem occurs again. We had this similar problem with a different processor. It was the problem with the battery disconnecting on a small shake or shock causing the Flash to be erased partially. Took us weeks to figure out what was the problem. We thought it was software issue until we found the problem occurred every time we gave a little tap on the table or put it on the table a little hard. Our code didn't do any writing to Flash either. During development phase we use battery hardness (springs) that were made in America. We began to experiencing the problem only with units that came back from production in China. 100% have that issues. Comparing, we found that the springs were a lot weaker than the one made in America despite the fact that they have the spring samples in hand. They were never able to produce it.

[Mike Robbins]

Hi Nguyen, thanks for the reply! Wow -- that is a very strange finding, and yes, our system might be exposed to small mechanical shock (occasionally picked up and returned to a hard surface).

Were you ever able to diagnose the mechanism of how that affected the flash memory? Were there other workarounds to protect the flash from erase, other than the stiffer springs? I feel like this would be a bad microcontroller design that allows a brown-out condition to permanently erase flash.

[Nguyen Hoan Hoang]

What I discovered was that shock cause displacement of the battery which momentarily power off and on the device. The action of on/off rapidly may have cause a current spike. This may be the cause of Flash being erased. It happens only when the device is running. What exactly is the cause, I have no idea. I added a bigger capacitor like 22uF helped to prevent power loss for a short period, enough to solve the problem for small shock. For bigger shock, we added a rubber sponge on the battery door that helps to hold batteries in place. With those 2 solutions seems to solved the problem. We didn't get Flash erase report since. Of course you can use a more sophisticated power regulator circuitry but would add up costs. Our device was low cost consumer electronics, every cents we save counts.