`Could not power-up debug power domain.` with nrfjproj on nRF52

Hi,

I'm trying to use the nRF52832DK to flash a Rigado BMD-300 module (nRF52) - I've connected SWDIO, SWCLK, GND and voltage sense to P20.

It seems that because the protection bit comes set, you have to use --recover, and I did that but I get the following:

./nrfjprog --recover
Recovering device. This operation might take 30s.
ERROR: Cannot connect to any nRF device. Please make sure a device is
ERROR: connected to the debugger and supplied.

When enabling logging, it shows:

--------------------------------------------------------------------------------
./nrfjprog --recover --log
nrfjprog verion 8.4.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 "NRF51822_XXAA" selected.
FUNCTION: recover.
FUNCTION: recover.
Found SWD-DP with ID 0x2BA01477
Could not power-up debug power domain.
Communication timed out: Requested 20 bytes, received 0 bytes !
Could not read hardware status!
FUNCTION: close_dll.
FUNCTION: close_dll.

It's done something, because the Rigado bootloader no longer shows in BLE, but it seems to have basically bricked the module now. I can't write any new firmware to it (either via nrfjprog or mass storage) - whatever I do I get the same Could not power-up debug power domain. message.

I've tried powering from a battery and the devkit's own power supply. Neither seems to make any difference.

Any ideas what could be wrong? This is causing serious problems - I've got prototypes here waiting to be programmed.

Parents
  • Fixed this. There's a very helpful description of pins here: devzone.nordicsemi.com/.../

    Basically P20 is for debugging shields. It seems like it should work, but for some reason it didn't in my case

    P20 is not a 0.1" version of 0.05" - the SWDIOs and SWCLKs are totally different

    So you might need to use P19 (the 0.05" version).

    Update: It is possible that P20 would work. I had managed to accidentally connect the NRST pin to a chip that was pulling it low - which I believe caused the connection errors. By default the bootloader has flags set to ignore NRST, but when you do --recover it removes those flags, NRST is used, and then the chip becomes basically unusable until NRST is left to go high.

Reply
  • Fixed this. There's a very helpful description of pins here: devzone.nordicsemi.com/.../

    Basically P20 is for debugging shields. It seems like it should work, but for some reason it didn't in my case

    P20 is not a 0.1" version of 0.05" - the SWDIOs and SWCLKs are totally different

    So you might need to use P19 (the 0.05" version).

    Update: It is possible that P20 would work. I had managed to accidentally connect the NRST pin to a chip that was pulling it low - which I believe caused the connection errors. By default the bootloader has flags set to ignore NRST, but when you do --recover it removes those flags, NRST is used, and then the chip becomes basically unusable until NRST is left to go high.

Children
  • If you read the schematic for the PCA10040 .. you end up none the wiser. At some point SWDIO and SWDCLK from the nrf52 must go to the ATSAM chip, however according to the names of the connections, they don't. SWDCLK and SWDIO only go to the debug in connector, everything else is either EXT SWDIO or SH SWDIO etc and so I actually don't know how the nrf's SWDCLK and SWDIO are connected to the segger chip in the usual course of things.

    you should still use

    --family NRF52 
    

    on your commands however. It definitely sets the segger up differently and if it thinks it's talking to an nRF51, it's not always going to work.

Related