NRF52 locked, can't recover

[brett_anderson]

I have custom hardware that is working fine. No issues. I can program, erase, debug with no issues. I have been working on making some changes in the bootloader, and I've run into some issues with two chips completely locking up and I can't recover them.

Seems to occur after exiting debug in Keil, specifically debugging the bootloader.

The chip locks up, and I can not recover using nRFgo Studio or nrfjprog.

nrfjprog --recover --log
nrfjprog verion 9.6.0
--------------------------------------------------------------------------------
FUNCTION: open_dll.
FUNCTION: open_dll.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_without_snr.
FUNCTION: enum_emu_snr.
Device "NRF52832_XXAA" selected.
FUNCTION: read_connected_emu_snr.
FUNCTION: read_connected_emu_snr.
FUNCTION: read_device_family.
FUNCTION: read_device_family.
Not supported by current CPU + target interface combination.
JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -2.
JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -102.
FUNCTION: close_dll.
FUNCTION: close_dll.

The two boards in question are now sitting in a state where they are dumping power and warming up. I can't stop them, as they are sealed units with internal batteries. I have no idea what state the chip is in, because I can no longer connect to it.

Any thoughts on what I might have done, or how I could recover them? (Other than a power cycle, which would require I break them open).

[AmbystomaLabs]

In one of the nRFgo Studio docs, I remember it mentioning something about the processor ignoring the SWD commands under certain circumstances. I think it said the solution is to make sure reset is connected.

I searched around for ARM related SWD problems and found similar problems/solutions. According to the entries the SWD can be ignored due to faulty firmware. The solution was always assert reset so that the erase command can be issue via SWD.

Though, the warming up part of your processor problem sounds odd. Could just be really screwed up firmware and something is going wrong on the main clock. A reset assert should still fix it.

[brett_anderson]

I can't. The hardware designer did not include a reset line in the design. I did find out that if I let the batteries die, I am now able to reprogram them. I'm taking that as circumstantial evidence that you are correct.