This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU Bootloader's settings can become corrupt after a power-cycle

Hello,

My team and I are experiencing a problem with our custom DFU Bootloader, which is based on the Experimental Bootloader Secure Serial example (SDK 13), running in a custom NRF52832 board. Our main app uses a single bank, and we're also using the S132 v4 SoftDevice, our custom Bootloader and Bootloader settings.

We have a custom main application that writes to our custom Bootloader's settings, triggering the enter_buttonless_dfu flag and resetting the system into update mode. When no update is due, upon power-on our Bootloader starts the main application by checking the result of nrf_dfu_app_is_valid().

However, on certain power-cycle conditions the Bootloader's settings become corrupt and the Bootloader can no longer start the main application as it looses the indication that a valid application is present. It appears to occur mostly if pressing our on-board reset button that temporarily disables our power-supplies (the switch is not debounced).

We are wondering if this is a known problem with SDK 13 and if there is a solution to the problem.

As a workaround, we're currently using a delay on our Bootloader code, that delays the loading of the Bootloader's settings ( nrf_dfu_settings_init() ) for 1000ms after power-on. This seems to help resolve the issue, although we believe the system is still vulnerable to this issue.

Thank you for your attention to this matter, please let me know if we are required to provide more details regarding this issue, TC

  • Hi Tiago,

    Could you try to modify the bootloader to print out some log to check what cause the bootloader not to enter application ? My suspicion is that the application is modified (because of some flash operation? ) and the CRC is mismatched. If you can reproduce the issue, you can also simply run the bootloader in debug mode and step into the code where it check for application valid.

  • Hi Hung, thanks for your reply. The bootloader fails to enter the application because the bootloader settings are erased by calling nrf_dfu_settings_init() when the bootloader starts, causing nrf_dfu_app_is_valid() to return false. This only occurs if the bootloader is power-cycled multiple times in a row, otherwise works just fine and loads the main app as expected. I have checked the SDK function nrf_dfu_settings_init(), and it seems to only erase the settings whenever they are corrupt. I just don't understand why would they become corrupt when neither the bootloader or the main app are writing to the settings or any other flash region.

    The flow of our bootloader on boot is as follows:

    • calls nrf_dfu_settings_init() to load the bootloader's settings
    • calls nrf_dfu_continue() in the event there is a pending flash operation - can this cause problems even if there is no pending flash operation?
    • proceeds to load the main app if nrf_dfu_app_is_valid() returns true and if enter_buttonless_dfu is not set
  • I suspect the bootloader has been reset when it's performing a bootloader setting update, meaning it's trying to erase the old bootloader setting and write a new one. Before the new bootloader setting can be written it got reset and the next boot up the bootloader setting appears corrupted.

    Do you have the issue if you simply reset the bootloader without doing any DFU update ? From my understanding, the bootloader setting only get updated if there is a DFU update.

    Avoiding a system reset when doing DFU is pretty important. That's why most vendors require battery >50% or power supply plugged before doing DFU update.

    If needed, we can implement a flag telling if the bootloader setting update is in progress and can continue/retry that on the next booting if there is a reset occurs.

  • Hi Hung, your reasoning makes total sense. I would expect the settings to become corrupt if a power-loss occurs during an update. However, frequently, the settings were also lost when our bootloader was calculating a CRC of our firmware files stored in a SD Card, when we forced a reset.

    Finally, I believe we have sorted it out:

    • when we cut power to the board while the bootloader is calculating the CRC, we've noticed that the NRF52 continued to run after the SD Card stopped working (due to low voltage). This caused the read operation to fail, aborting the calculation and triggering a write to the settings (indicating that the image on the SD Card is not valid). After adding a delay before the write operation, we prevented the read errors which can be an indication of a sudden power loss, and the issue could not be reproduced again.

    Thanks again for all the assistance on this.

  • That bootloader setting update flag would be handy actually. Could this help prevent the settings from being reset if they become corrupt?

Related