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

[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.