Force MBR to jump to bootloader on GPIO input?

[Mike Melbot]

Hi Nordic,

We're developing a product based on the nRF52810 and got the following question:

We were wondering if we can recover a board in the worst-case scenario where a valid OTA is applied, but due to a bug not caught in QA, it somehow renders the device unusable.

Take the following case for example:  

A persistent setting is read from flash on startup, and on certain values of the setting the board will crash right after boot.

It got through QA because it only happens in the unlikely case that this particular value is written to the flash at some point, or as a result of power loss while writting to the flash. The next time it boots it will instantly crash without a chance to telling the MBR to go into DFU mode again.

We would love to implement a safety mechanism to escape this situation and unbrick affected devices, where the user can press the RESET button (we're using the RESET pin) and possibly by releasing it and pressing again in a short timeframe the board would go into bootloader mode again for the chance to install a fixed version of the firmware.

To be totally safe, this would be ideally done in the MBR as follows.

On the MBR entry point, the reason of reset is checked.

if it's a hard reset then

Reconfigure the RESET button as a regular GPIO and start a 500 ms timer

if the GPIO is set low and the high before the timer expires then

reconfigure the GPIO as RESET again and jump to the bootloader ignoring the DFU settings in flash

else

proceed to the user firmware

else 

proceed like normal (check if there is a DFU command pending, ....)

I'm aware that the MBR source code is proprietary and not intended to be updated or modified. So I'm asking for alternative ideas to implement such a security mechanism.

Probably it's easier to build that into the asm startup code of the app firmware to be run right before main() and never touch it in any subsequent firmware update once it's working. The potential bricking code would always be after main()...

Is there already some support for this in the SDK/hardware?, can you recommend a better way of achieving this?

Thanks in advance!
Mike

[Turbo J]

Mike Melbot said:

Reconfigure the RESET button as a regular GPIO and start a 500 ms timer

Not safely possible. UICR erase is a very dangerous operation, and would be the only way to reconfigure the pin.

Note that the normal boot process is MBR->bootloader->app, so your pin check can simply be done in the bootloader itself.

In many cases you also have a way to cut power (removing the power source in order to trigger POR), so you don't really need the reset pin function in the final design and could configure the GPIO as a "bootloader" button.