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

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

Nguyen Hoan Hoang — Tue, 20 May 2014 20:07:01 GMT

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.

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

Mike Robbins — Tue, 20 May 2014 18:07:59 GMT

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.

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

Nguyen Hoan Hoang — Tue, 20 May 2014 08:28:19 GMT

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.

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

Mike Robbins — Mon, 19 May 2014 20:39:40 GMT

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!

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

Chris — Mon, 19 May 2014 09:15:21 GMT

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