Nordic not reflashable suddenly

[dareis08]

Nordic,

We've been using the nRF52832 for many years now.  We have a custom board that uses SWCLK and SWDIO to flash our NRF52.  We're getting set for production and I am working on our automated manufacturing rig.  We have a python script that flashes a nordic with a soft device, bootloader, and then application.  Some of the GPIO go to LEDs, so I can see what state the chip is in after programming.  It had been working great then I started getting this problem where the LEDs didn't show up in the right state.  I'd go to reflash the device, and then the SWD won't connect, and I could not erase the chip.  I can hit our reset button, tied to the RESET pin on the IC, and nothing happens.  Normally this button does a hard reset, where the LED goes away and (I believe) the chip loses power.  Upon release of the reset, the board should initialize into the bootloader and the LED blinks red marking as such.  But for these 'bricked' boards, the LED stays on throughout the reset button press.   These two things: not able to reset the chip, and not being able to reflash the chip, these are quite alarming.

One piece of good news is the current drawn seems to be about 1 mA like when the Nordic is in low power state.  

I've spent most all day going through devzone forums trying things, hoping to recover or at least explain my freeze-up.  

When I go back into J Flash Lite, I can no longer ERASE the chip.  Now it says

Connecting to J-Link...
Connecting to target...
ERROR: Could not connect to target.
Done.

Fine, I can try from the command utility.  I use the jlink.exe tool, and go through the regular steps to connect and then try to erase.  This also doesn't work:

J-Link>connect
Device "NRF52832_XXAA" selected.

Connecting to target via JTAG
InitTarget() start
InitTarget() end
TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
InitTarget() start
InitTarget() end
TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
InitTarget() start
InitTarget() end
TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
InitTarget() start
InitTarget() end
TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
Cannot connect to target.

Ok, now I try to use the nrfjprog tool.  For reference I look up the version as 

nrfjprog version: 10.15.1 external
JLinkARM.dll version: 7.58b

Then I do all kinds of commands to try and talk to my board.  Here are some

>nrfjprog --recover --log
ERROR: [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
ERROR: [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
ERROR: [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
ERROR: [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
ERROR: [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
ERROR: [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
ERROR: [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
ERROR: [ nRFXX] - Device does not have an ARM debug port.
ERROR: [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".
ERROR: nrfjprog could not identify the target device. This may be due to an
ERROR: invalid family argument, a problem with your device, or nrfjprog may
ERROR: not yet support your device.
ERROR: Please check the family argument passed, or upgrade nrfjprog to a more
ERROR: recent version.

>nrfjprog -e
ERROR: nrfjprog could not identify the target device. This may be due to an
ERROR: invalid family argument, a problem with your device, or nrfjprog may
ERROR: not yet support your device.
ERROR: Please check the family argument passed, or upgrade nrfjprog to a more
ERROR: recent version.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

>nrfjprog -d --family nrf52 --log
ERROR: Unable to connect to a debugger.
ERROR: [ nRF52] - Debug probe is not connected to an NRF52 series device.
ERROR: The --family option given with the command (or the default from
ERROR: nrfjprog.ini) does not match the device connected.

I know the segger and cables and everything are correct, I HAD been able to program this and other boards.  But during development of the python script, I've 'bricked' 5 of my boards.  I only have 2 left.  So I need to get to the bottom of this.

I don't understand how something could ever make the SWCLK SWDIO not able to erase the chip.  What am I missing, please help.

environment:  windows 10

[hmolesworth]

LED on during reset pin low implies no internal VCC available even if voltage is on the VCC pin so instead internal VCC is coming from the LED pin through the schottky protection diode to internal VCC and thus illuminating the LED; if the chip were in reset the LED port pin would not be driven low at all and would not be lit. This implies the internal LDO (or DCDC if that is hat you are using) may be bust. Try enabling the internal DCDC at powerup  then remove the 3 volts on the reset pin and see if the it still dies.

Otherwise we are quite sure there isn't a simple code bug? Check by while(1); at power up, no other code run at all; no offense intended.

Edit: Just to clarify (couldn't edit my last post, still issues with this forum in editing) the thesis is that the Reset pin has become the new source of VCC for the nRF52, nothing to do with reset functionality. Any other i/o pin might also supply VCC if it were directly connected to 3 volts, then maybe the reset pin (now not connected to 3 volts) would work also as expected. Worth a try .. if this the case the current into the Reset or other io pin will be (say) 4 or 5mA since it is supplying the entire internal VCC. How could this have happened? Well ..

[hmolesworth]

Just to clarify (couldn't edit my last post, still issues with this forum in editing) the thesis is that the Reset pin has become the new source of VCC for the nRF52, nothing to do with reset functionality. Any other i/o pin might also supply VCC if it were directly connected to 3 volts, then maybe the reset pin (now not connected to 3 volts) would work as expected. Worth a try ..

[dareis08]

hmolesworth,

Bingo.  Somehow the external LDO was blown.  Supplying external 3V to the IC seem to restore functionality.  I don't know how we blew the LDO supply.  More exploration and details to follow.  

I haven't yet accomplished the internal DCDC config yet.  TBD.

THANKS for your help. 

Darren 

[dareis08]

I've tested 4 of the 'bricked' boards and it seems that the LDO [ADP165ACPZN-R7] supplying the NRF VDD is blown on each.  This is very peculiar because its never happened on our last production run, with the same circuit.   The NRF is only ever supposed to pull 180mA, and the LDO should handle that.  So I'm puzzled.  The NRF is the only IC on this power rail.  Any idea how I could blow the LDO? 

But the good news is the chip internal isn't the problem.   

hmolesworth, I'd like to upvote your answer but the forum is not letting me. But, kudos to you for your help on this issue.  Thanks!

[hmolesworth]

You're welcome - and thanks for the thanks, sometimes lack of response is off-putting :-)

That LDO is pretty bullet-proof except against high spike voltages on the Vin, maybe inductive kick-back? What is the input voltage range? I've used external regulators before on the nRF52 but found lowest overall power consumption is by using the internal DC-DC converter which automatically drops back to the internal LDO skip mode (pseudo-DC-DC). If the external supply is high (over 3.5 volts) then there is  no alternative to the external regulator, other than switching to an nRF52840 or similar. The port pins use VCC (say 3.3V) but the MCU core uses 1.3 volts, so LDO is inefficient. 3.3V supplying 1.3V core at 5mA uses 3.3V @ 5mA, but DC-DC uses only (1.3/3.3)x5mA - huge savings

    // The internal 1.3V DC/DC regulator used as an alternative to the internal LDO regulator to reduce power consumption
    NRF_POWER->DCDCEN = 1;