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

[bjorn-spockeli]

As Turbo J says:

Turbo J said:

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

 Infact the bootloader can also be configured to check a certain GPIO pin on startup and stay in DFU mode if this pin is low. See dfu_enter_check() in dfu_bootloader.c, which is called in nrf_bootloader_init().

static bool dfu_enter_check(void)
{
    if (!app_is_valid(crc_on_valid_app_required()))
    {
        NRF_LOG_DEBUG("DFU mode because app is not valid.");
        return true;
    }

    if (NRF_BL_DFU_ENTER_METHOD_BUTTON &&
       (nrf_gpio_pin_read(NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN) == 0))
    {
        NRF_LOG_DEBUG("DFU mode requested via button.");
        return true;
    }

    if (NRF_BL_DFU_ENTER_METHOD_PINRESET &&
       (NRF_POWER->RESETREAS & POWER_RESETREAS_RESETPIN_Msk))
    {
        NRF_LOG_DEBUG("DFU mode requested via pin-reset.");
        return true;
    }

    if (NRF_BL_DFU_ENTER_METHOD_GPREGRET &&
       (nrf_power_gpregret_get() & BOOTLOADER_DFU_START))
    {
        NRF_LOG_DEBUG("DFU mode requested via GPREGRET.");
        return true;
    }

    if (NRF_BL_DFU_ENTER_METHOD_BUTTONLESS &&
       (s_dfu_settings.enter_buttonless_dfu == 1))
    {
        NRF_LOG_DEBUG("DFU mode requested via bootloader settings.");
        return true;
    }

    return false;
}

Best regards

Bjørn 

[Mike Melbot]

Sweet!, I guess I'll go this way and use the reset button as a GPIO instead.
Thanks!