This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • 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!

Reply
  • 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!

Children
No Data
Related