Device reboots into DFU Mode after App Update

[Kyle Krueger]

Hello,

I am having an issue with the DFU in SDK V12. Using the secure_dfu package, and the buttonless dfu app as a template, I was able to get OTA DFU application updates working with the development kit. However, the same cannot be said about running the same application with custom hardware.

After running the DFU update on the Development Kit, everything runs as expected. The device resets, and launches the application; the DFU control point is visible to reset the device and boot back into DFU mode.

On the other hand, with our custom hardware. The device reports |DFU| Upload Completed in (#####) ms, but then after the reset boots right back into DFU mode.

After checking the hardware compatibility matrix, I know our chip is the same revision as the one on the pca10040 DK we were using for testing.

My suspicion is that the BANK_0 value for a valid app is not being set upon DFU completion, but I can't make any sense out of why that would fail to occur.

Has anyone else seen a failure to launch an app after DFU update with SDK12.0 and/or SDK12.1?

Here is the output from the flash after performing DFU: hex_dump.txt

[bjorn-spockeli]

Yes, if the if the LFCLK settings were wrong you would not be able to perform DFU. The bootloader would simply hang on ble_stack_init. As for the BANK_0 flag, you can check whether the valid app flag is set by reading the DFU settings page, i.e.

nrfjprog -f nrf52 --memrd 0x7f020

which should output

0x0007F020: 00000001                              |....|

if the valid app flag is set.

[Kyle Krueger]

Hi Bjørn,

The output from our custom board is reading out as 0x0007F020: 00000001 |....| after flashing the application package with DFU. So the BANK_0 flag is being set properly on update completion. However, the device is not starting the application, and is instead launching DFUTARG.

This is not the case with the development kit. On the PCA10040 the application launches successfully.

[bjorn-spockeli]

If you debug the bootloader after the DFU, does it reach nrf_bootloader_app_start in main()? If so, could you try to debug the application? It would be interesting to know if it enters the application and then resets. Lastly, could you read back the flash after DFU to a file and attach it to the question? You can read back the flash and store it to a file using the following command.

nrfjprog -f nrf52 --memrd 0x00000000 --n 524288 >> hex_dump.txt

[Kyle Krueger]

The hex_dump is now attached at the end of the question. Going to check if the software reaches nrf_bootloader_app_start next.

[Kyle Krueger]

While checking if the bootloader reaches nrf_bootloader_app_start, I noticed some warnings about RAM configuration.

    SDH:INFO:sd_ble_enable: RAM START at 0x20002c00
    SDH:WARNING:sd_ble_enable: app_ram_base should be adjusted to 0x20002798
    SDH:WARNING:ram size should be adjusted to 0xd868