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

Parents
  • 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
Reply
  • 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
Children
No Data
Related