nRF52 Delete bonds while in Bootloader

I'm working on a custom board that uses an nRF52832 module. It has a single button that is used to power the device On/Off and a  >= 5sec  long press from Off to force enter the bootloader (my fail-case backup). The bootloader can also be entered by the buttonless DFU.

I would like to delete bond data when entering the bootloader by the long-press since I cannot provide a separate button for it. I also don't want to use BLE command to do it in case of app failure.

I added a bootloader entry case for the long press in static bool dfu_enter_check(void)  in  nrf_bootloader.c  and I would like to delete bonds here, shown below:

static bool dfu_enter_check(void)
{
    // If power button is held for >= 5 seconds, then enter DFU
    uint32_t timeout_ticks = nrf_bootloader_dfu_timer_counter_get() + NRF_BOOTLOADER_MS_TO_TICKS(5000);
    while (0 == nrf_gpio_pin_read(PIN_PB_OUT))
    {
      if(nrf_bootloader_dfu_timer_counter_get() >= timeout_ticks)
      {
        NRF_LOG_DEBUG("DFU mode requested via timed button press.");
        
        delete_bonds(); // <-- This
        
        return true;
      }
    }
    
    ...
    
    return false;
}

My question is, is there a quick and dirty way to do this in the bootloader without having to pull in the entire peer manager?

  • I suppose one way I could do this is setting a delete-bonds-flag in GPREGRET2. Then if the app is valid it would read the flag, delete bonds, and reset GPREGRET2.  ..I'll try this first but I'm open to more suggestions.

    EDIT: So I got it working but I had to change the bootloader behavior when the power button is pressed as follows:

    button pressed < 5sec run bootloader normally

    button pressed >= 5sec set the delete-bonds flag in GPREGRET2 and let the bootloader run normally when released, ie if valid app then it will jump to it.

    button pressed >= 10sec then stay in the bootloader (delete-bonds flag still set)

  • Hi Andrew, 

    It's possible to erase bond information in the bootloader without pulling the entire peer maanger but it will be more like wipeout the whole flash storage and when the application run again it will need to re-initialize the flash database. This could be an issue if you have other data to be preserved. 

    So what you are doing with the GPREGRET2 and do the bond erasing in the application could be a better solution. One thing to take into account is that when you update a new app it should be able to use the same flash configuration (or prepare a way to re-initialize the flash if it can't re-use the original flash configuration from previous version).

  • When you refer to flash configuration, are you talking about the linker flash/ram size and location configurations?

Related