• State Verified Answer
  • Locked Locked
  • Replies 13 replies
  • Subscribers 25 subscribers
  • Views 489 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288842
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Customize bootloader to rollback OTA DFU

user108796

Hi,

I've been requested a feature regarding buttonless OTA DFU that I'm not sure if it's feasible or advisable to implement.

The feature is that once the OTA is successful and the new application has been successfully flashed, we should check if the app can connect to the client application. If it can not secure a connection due to a bug in the new app, it should rollback the app to the previous app. Since it can not connect to the client, it should store the old app in a "Bank 2" before flashing the new app from Bank 1 into Bank 0. This assumes that there is enough flash memory to store 3 copies of the app. Does this procedure make sense? Is it feasible to implement with the secure bootloader?

How could this be handled in a different way? I think a timer to check if connection is possible (similar to a watchdog timer) and if not send device to bootloader mode for OTA DFU could be an easier approach to implement.

Thanks in advance.

Parents
  • +1

    Hi Alberto, 

    I think its feasible and there are multiple alternatives to achieve what you want. Here is the list I can think of: 

    1. Do what you are planning, divide the flash into 3 banks and before you swap the application with the new image you copy the original application to "bank 2".

    2. In stead of using 3 bank you can use 2 banks and copy the original image back to bank 1. You can use one swap page to temporarily store the page you want to copy from bank 0 to bank 1 when overwriting the page on bank 0. 

    3. Third option, is to simply use the phone to revert the image back to the original one via DFU update. This requires you to have a way to enter DFU mode even if the application failed. A physical button would works. You can hold the button when reset to enter DFU mode. Or you can configure a period of time (5 second for example) when you boot up to stay in DFU mode and wait for the phone to connect. 

    Doing option 1 or 2 would require you to significantly change how the swap process works on the bootloader. But I don't see any reason that it would work. Option 1 will limit the size of the application as you would need to divide the flash into 3 parts. 

Reply
  • +1

    Hi Alberto, 

    I think its feasible and there are multiple alternatives to achieve what you want. Here is the list I can think of: 

    1. Do what you are planning, divide the flash into 3 banks and before you swap the application with the new image you copy the original application to "bank 2".

    2. In stead of using 3 bank you can use 2 banks and copy the original image back to bank 1. You can use one swap page to temporarily store the page you want to copy from bank 0 to bank 1 when overwriting the page on bank 0. 

    3. Third option, is to simply use the phone to revert the image back to the original one via DFU update. This requires you to have a way to enter DFU mode even if the application failed. A physical button would works. You can hold the button when reset to enter DFU mode. Or you can configure a period of time (5 second for example) when you boot up to stay in DFU mode and wait for the phone to connect. 

    Doing option 1 or 2 would require you to significantly change how the swap process works on the bootloader. But I don't see any reason that it would work. Option 1 will limit the size of the application as you would need to divide the flash into 3 parts. 

Children
  • 0 in reply to Hung Bui

    Hi Hung,

    Thank you for your answer.

    Since my board has no buttons available, option 3 would require to enter the DFU mode from the application. My idea would be that if the new application can not secure a connection in (for example) 5 seconds after flashing, it should go into DFU mode and the old application should be uploaded over BLE. Is that the same procedure you are describing?

    I understand that option 3 would the easier to implement that 1 or 2. Do you see any added benefits of options 1 or 2 over option 3?

  • 0 in reply to user108796

    Hi again,

    My idea was that if you dont have a button, you can configure the bootloader so that when you power up the device it will stay in the bootloader mode for 5 seconds, advertising and wait for a connection from the phone. If the phone connect before 5 seconds elapse it will start to do DFU update (so that you can revert to previous application image). If there is no connection the bootloader will continue to start the application. 

    The main draw back of this approach is that you have longer booting up time, an addition of 5 seconds. And it wouldn't work if your device is a battery powered device and never supposed to be reset in its lifetime. 

  • 0 in reply to Hung Bui

    Hi,

    The device is battery powered so this approach could not quite work exactly like that.

    However, I think that if when the new app is initialized after OTA DFU and the connection can not be successful with the central device, sending the device into DFU mode would work as a way to fix for this issue, no?

  • 0 in reply to user108796

    Hi Alberto, 
    The device is battery powered but does it has a power button on it ? So that you can turn off and on the device ? 

    If the connection can not be successful with the central device with the new firmware, how would you put the device to DFU mode ? It's the main challenge here. 

  • 0 in reply to Hung Bui

    Hi,

    The device does not have a button for power on/off. It will be turned off during charging. Based on this discussion, I have tested that I can send the device to DFU mode by calling ble_dfu_buttonless_bootloader_start_finalize();NVIC_SystemReset();.

    If when initializing the device after an OTA DFU update, the application can not connect to the central device in 5 seconds, I would call these 2 methods and the device goes into DFU mode.

    I have checked that the device goes into DFU when calling those 2 commands.

Related
Terms of service