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

Device reboots into DFU Mode after App Update

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

  • Hmm, it should only enter that section if if the bootloader button is pressed, i.e. pin 16 is low, or if enter_buttonless_dfu flag in the bootloader setttings is set. Looking at the hexdump, I can see that the enter_buttonless_dfu flag is not set so it has to be the GPIO pin. Do you have pin 16 of the nRF52 tied to anything?

  • Pin16 is checked in the default implementation of nrf_dfu_enter_check() of nrf_dfu.c. If implementing buttonless DFU, this function should be overridden or modified to avoid conflicts with the use of this pin.

    We had been using pin16 for a SPI bus, and as a result, it was tricking the bootloader into launching DFU.

    I modified the code in nrf_dfu_enter_check() to remove the logic that checked the state of that pin. This should not be a problem for us since we are using a buttonless implementation.

    After removing the check for the state of pin16, the application launched successfully.

    Thanks for your help Bjørn!

    I feel like the DFU should only check the value of this button for the example code, and that it should not be part of the SDK default function.

  • Happy to help Kyle. I think it should be a part of the bootloader example, but I think that we should make users of the SDK that this pin is used to enter bootloader mode and the pin number should be modified or the check removed.

Related