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, 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?

Reply Children
No Data
Related