Keeping GPIO high state during OTA DFU

[robca]

I found a few old support tickets mentioning the same topic, but most referred to very old versions of the SDK.

We designed a nRF52840 board with an electronic switch controlled by a GPIO pin. When the device is shipped, the switch is off and the battery disconnected. When the user connects the charger for the first time, the nRF52840 is powered on and sets a GPIO pin high to enable the battery switch. In normal use, when not used the device "sleeps" using system off, woken up by an IMU. If needed, the device can be put in an off state via a control point (switch off), and can reboot only if connected again to the power supply.

Based on the reset behavior below, the DFU process seems to lose the GPIO state, and "kill" the device. The only way to make the OTA DFU work, is to do it while the device is powered by the charger (which is an acceptable workaround).

I was wondering, though, if there is a way to change how the OTA DFU reset works and "jump" from the DFU code into the main code with no reset. We are using the nRF5 SDK 17.1 and cannot use the new Zephyr-based one (we need ANT+ and it was not supported until recently: we don't have time to port all of our existing codebase to the new environment for this project)

Any idea if it's possible to keep a GPIO PIN high during the DFU process?

[JONATHAN LL]

to do it while the device is powered by the charger (which is an acceptable workaround).

Looks like you found your solution!



So the device will do a soft reset while the OTA DFU's, so the GPIO pin states will not be retained. The workaround you found is now the new fix.

Regards,
Jonathan

[robca]

Well, yes, that works but it's a poor workaround : users rarely read the documentation and even if the update code were to warn the user to do it while connected, they might still not do it and have a bad experience/call support.

In an old thread ( GPIO high during DFU ), someone suggested 

the gpio register is cleared on system reset, but you could try the approach we used in 
our legacy bootlaoder which was to branch to the reset handler of the bootloader instead 
of doing a system reset, see bootloader_util_reset() implementation in bootloader_util.c 
(included in SDK 11).

But the code in SDK 17.1 is radically different, so I'm not sure if that is still doable. Before starting to hack away at the DFU code, I was hoping for a bit more information.