GPIOs are not reset after DFU

[Kyle Krueger]

Hi,

We had a power issue with our custom board related to DFU updates. After performing a DFU we were seeing 8mA idle current, and when we had programmed the firmware directly with the JLink Flasher, we were seeing ~500µA as expected.

This lead us to believe that some GPIOs were not being reconfigured to the default values after a successful update. To test this theory we added a loop to the beginning of our app that sets all gpios back the their defaults. The result was a success, we now see ~500µA after a DFU update.

for (int i = 0 ; i <= 31; i++)
    nrf_gpio_cfg_default(i);

However, I wanted to create a question as a bug report. We expected that this would have happened at the end of a DFU update, and is not something that the app should need to worry about. We are still using SDK12.0.0 as there were a number of other bug fixes we had added in to the SDK, and we have not yet had tried to merge with SDK12.0.1.

Is this a known problem, and has it been fixed in the latest versions of the SDK?

-- Kyle

[bjorn-spockeli]

Hi Kyle,

this is the expected behavior since the bootloader branches to the application, i.e. does not reset into the application.

The nRF52 will always will pass execution to the bootloader if it is present, which in turn will pass execution to the application, if it is valid. The bootloader will trigger one or several soft-resets during the DFU process, depending on the image type, but the final switch from bootloader to app is a branch operation.

This means that all configurations of peripherals if you've initialized in the bootloader, e.g. the GPIO peripheral, will persist through the branch operation. So the best practice is to have to un-initalize or reset the configuration to its default values the peripherals before the branch operation.

Best regards

Bjørn