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

`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.

  • It has done nothing, it just tried to open dlls to be able to communicate with segger chip, then it tried to detect the power of the nrf chip and it sensed there is no power. So it bails out. I am not sure if the segger chips gets power from P20, why are you not using normal debug port P18 if you have the DK?

  • It seems to have done something, because the Rigado bootloader isn't there any more. It can also detect the chip's serial number over SWD (0x2BA01477) and fails if I remove my device's battery so the chip must have power on it. To be honest I can find very little documentation on what I should be using and how to connect it. I'm using P20 because it can be connected with 0.1" leads and it actually had some documentation that showed SWDIO and SWCLK which is what I knew I needed. So how should I be connecting a target device to it?

  • I don't remember the memory protection bit being set on my BMD-300s, but they were engineering samples, perhaps it changed for the production release. I have to solder some up this week, will find out.

    So you have SWDCLK, SWDIO, 3.3V and GND connected, check them again just to be sure? How about going straight to JLink(Exe), get the latest segger JLink tools to make sure they're new enough, get connected

    JLinkExe -if swd -device nrf52 
    

    See if you can at least get connected and have the JLink tell you what voltage it reads and whether it gets enough from the DAP to identify the chip. I wonder if the debug protection is enabled (didn't think RIgado did that), in which case you'd need to get into the second debug port and reset the entire chip, which is what I assume 'recover' does.

    I just noticed that your log file says NRF51822, I think you need to tell it you're an nRF52.

  • 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.

  • 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