• 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.

  • 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.

  • 0 in reply to user108796

    Hi Alberto, 

    Yes you can put the device in DFU with these call. However, you are making the assumption that the application can run normally and can trigger the reset after 5 seconds without central connection. But if there is a case that the application crashed before that (if it couldn't boot, or when booting it assert for some reason) then it's not possible to switch to DFU mode. 

    In addition, what if the central couldn't reconnect within 5 seconds for some reason (use turn off the app , or Bluetooth signal was not strong enough) then the device will enter DFU. 

    If you choose to do 5 seconds staying DFU mode when booting, then it would not be dependent on the new application as it's the bootloader handing this first phase of booting. 

  • 0 in reply to Hung Bui

    Hi again.

    I tried answering earlier but for some reason the "reply" button seems to appear and disappear at will.

    In the case that the application would crash, if a watchdog timer is in place, it should take the device into DFU mode, isn't it? Then, that case would be covered.

    In the second case, if the user turned off the app or something similar after an OTA update, then it would go into DFU indeed. But the timeout would happen in 2 minutes and the app would be started so I don't think it would be a big problem.

    The problem I see with staying in DFU mode when booting for 5 seconds is that it is not testing whether the application itself can connect to the central device. What I am worried about is that the new app would not be able to connect to the central device for some misconfiguration of BLE parameters or wrongly called methods. In that case, the device would not be able to be sent into DFU mode because it can not connect and the application itself is not crashing.

  • 0 in reply to user108796

    Hi again, 

    Yes, the watchdog can bring the device to the bootloader. But the bootloader may just start the application again and you will end up in a infinite loop. If there isn't a "5 seconds advertising" at bootloader booting, it would not be possible to connect and do DFU update. Usually the fall back is to have a button pressed and hold when booting to retain in DFU mode but I guess it's not an option for you. In your case you can think of checking the reset reason, if it's watchdog reset then you can start DFU. 

    alberto. said:
    The problem I see with staying in DFU mode when booting for 5 seconds is that it is not testing whether the application itself can connect to the central device. What I am worried about is that the new app would not be able to connect to the central device for some misconfiguration of BLE parameters or wrongly called methods. In that case, the device would not be able to be sent into DFU mode because it can not connect and the application itself is not crashing.

    I see what you meant here, but 5 seconds could be too short to me. I would suggest to try 30seconds to give good user experience. But I guess you would know your application better than me :) 

  • 0 in reply to Hung Bui

    Hi Hung,

    Thanks a lot for all your answers.

    Isn't it so that after the watchdog reset, the DFU mode will be active for 2 minutes (set at #define NRF_BL_DFU_INACTIVITY_TIMEOUT_MS 120000). So there should be a 2 minute window for DFU advertising that the user can connect to the DFU target, no? I believe that has been what I have experienced during testing. After those 2 minutes, the application will start again if it is valid.

    Yes, I agree there should be enough time in DFU mode before starting the app again Slight smile I'm guessing the reason why I have seen those 2 minutes before the timeout was because I called ble_dfu_buttonless_bootloader_start_finalize(); before NVIC_SystemReset();. I assume that it would be possible to do the same from the watchdog reset.

Related
Terms of service