# GPIOs are not reset after DFU

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

edit retag close delete

Sort by » oldest newest most voted

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

more

[hide preview]

## Recent blog posts

• ### Nordic Developer Zone celebrates its 4th year of helping developers succeed - Celebrate with us and win a Nordic Thingy: 52’

Posted 2017-06-23 10:12:53 by John Leonard
• ### nRF52 Development with CLion

Posted 2017-06-22 09:50:54 by dansheme
• ### Simple GPIO driver example

Posted 2017-06-22 13:38:36 by Hans Elfberg
• ### What mom didn't tell you about ble_app_att_mtu_throughput on the nRF52840 evaluation board

Posted 2017-06-16 16:12:15 by George
• ### Introducing Nordic’s new software licensing schemes

Posted 2017-06-15 11:21:39 by Reidar Martin Svendsen

## Recent questions

• ### NRF51822 to NRF51822 Over the air update (DFU)

Posted 2017-06-25 16:25:45 by wogisha
• ### Advertising with device_name Vs whitelisting

Posted 2017-06-25 14:39:12 by raju

Posted 2017-06-25 11:14:42 by Eric
• ### NRF24L01+ Minimum order quantity

Posted 2017-06-25 10:14:55 by tabrown
• ### Can I use MDBT40 with ATMEGA328 ?

Posted 2017-06-25 09:59:42 by sai