Enter DFU mode battery-powered not working

[John1]

Hi,

I currently got the DFU mode working with my nrf52832 while it is being connected to the PC using the Particle Debugger.

I use the GPREGRET method and while connected to the PC the device enters the DFU mode as expected by executing this code after a button press:

uint32_t err_code;
err_code = sd_power_gpregret_clr(0, 0xffffffff);
APP_ERROR_CHECK(err_code);
err_code = sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
APP_ERROR_CHECK(err_code);
sd_nvic_SystemReset();

The problem now is, if I disconnect the 10-pin cable, the GPREGRET register is set as expected (I verified this by reading the register again before doing a system reset), but the device seems to not enter the bootloader/DFU mode but instead simply turns off.

Why does it make a difference when having the 10-pin cable connected and not having it connected in terms of being able to enter the DFU mode? Any suggestions?

Further information:
I use the Nordic SDK 17.0.2 and softdevice 7.2.0.

[Vidar Berg]

Hello,

I can't think of any obvious reasons for this. After the device is "turned off", could you try to attach the debugger again and read the CPU regs with nrfjprog --readregs to find out what state the chip is in?

Best regards,

Vidar

[John1]

Hello Vidar,

After installing nrfjprog I tried running your command with no success:

As written above I use the Particle Debugger (see here for an image of this debugger: https://github.com/particle-iot/debugger) to connect my board to the PC via USB. I currently use pyocd to flash the soft device and application, which works fine. I am not 100% sure, but I think pyocd flashes the .hex files using CMSIS-DAP currently. Is there something I have to change in order to be able to use nrfjprog? Or is there an alternative I can use to read the registers?

Best regards,
John

[Vidar Berg]

Hello John,

Sorry, I forgot that you were using another debugger. nrfjprog only works with J-link programmers. Is there compatible command line tool for this debugger you can use to read the CPU registers. Alternatively, do you have a setup for debugging with GDB, etc?

Best regards,

Vidar

[John1]

Hi Vidar,

Nevermind, thanks for your answer! I am not aware of any command line tool specific for that debugger.

Yes, I have GDB running by following and adapting the following tutorial: https://medium.com/makerdiary/debugging-nrf52-boards-with-visual-studio-code-c1482a759997

I assume now I have to use the command "info registers" to have a look at the registers, right? Which ones are of importance here?

[Vidar Berg]

Hi,

Great that you have GDB setup ready, that will make further debugging easier if it becomes necessary.

Yes, you can use "info registers" to read out the registers. The most interesting one now is probably the Program counter (PC). It will tell us where the CPU is executing code from. Based on its address range you can determine if it hangs somewhere in the application or in the bootloader.

Edit: try to configure gdb to connect to a «running target». Because if you connect and reset it might recover the device.

[John1]

Hi Vidar,

Thanks a lot for your help. Using this knowledge I found out that a pin was configured in the wrong way. A specific gpio pin should have been initialized as output pin and set to one, otherwise my device simply shut down. so I had to adapt my code to deal with that. My problem is solved now.

Best regards,
John

[Vidar Berg]

Ah, the devices was actually shutting down. My assumption was that the FW was entering a "bad state" and got stuck. Thank you for the update.

Best regards,

Vidar