Start of application takes ages after DFU process is complete

Hello,

in my application (SDK 16.0.0, nRF52840) I perform a DFU and successfully update the application firmware. However I have noticed that from the moment when the DFU is complete (i.e. the moment when the on_dfu_complete callback, defined in nrf_dfu_req_handler.c, is executed) to the moment when my application is active there is a huge time gap, about 15 seconds. Do you have any idea about the cause of this gap and how to reduce it? My guess is that there is either a coherence check on the new application before it is started, or a specific parameter that causes the delay in the sdk_config.h, which I am not aware of. My application occupies little less than half the available flash on the 52840.

Thank you.

Kind regards,

Stefano

Parents
  • Hello Stefano, 

    The activation delay is caused by the bootloader having to copy the FW image from bank 1 into bank 0. As can be seen from the Flash programming section of the PS, erasing one flash page takes ~85 ms, and the time to write one word is 41 us.

    If it is important to reduce this delay, you could consider configuring the bootloader so that it only perfom single bank updates (Dual-bank and single-bank updates) of the application, which means the application will be updated in-place.

    Kind regards,

    Vidar

  • Dear Vidar,

    Thank you for your quick answer. This can partially explain the large delay I observe. My application is exactly 409600, i.e. 100 pages, wide (the image we send is created in such a way to be always that size, and exactly half the available flash for dual update. I have verified in flash that after an update bank 1 starts immediately after the end of bank 0). So the time to erase and copy one page would be 85+(0,041*(4096/32)) ms=90 ms, and 9 seconds for 100 pages. Does any other potential source of delay to the start of application come to your mind?

    In addition to that, does this mean that when the on_dfu_complete is called the firmware has been copied into bank 1 but no validity check on it has been performed yet? What happens if there is a power cut during this validity check?

    Regards,

    Stefano

  • Dear Vidar,

    Thank you for your answer. I need the bootloader to signal a successful firmware update to the application, and I am presently doing it by setting a bit of the gpregret register in the  on_dfu_complete callback. The problem is that, in case an hard reset (e.g. shutdown) happens during the period when the firmware is moved from bank 1 to bank 0, the gpregret bit will be reset (whereas the shift from bank 1 to bank 0 will be finalised anyway, once the device is repowered). A simple solution would be to move the setting of the gpregret bit to the end of the fw validation, after the 13 seconds discussed above. Could you please tell me which is the best point to do that?

    Thank you.

    Kind regards,

    Stefano

  • Maybe after app_active() returns with NRF_SUCCESS here: 

  • After looking at the function you suggested I thought it could be better to add the gpregret write operation after it is called in nrf_bootloader_init (nrf_bootloader.c). Do you see anything wrong with it? I tested it and it seems ok, which means that now even if I switch the board off during the bank1 validation and shift to bank0, the gpregret bit is eventually set and my application can use it once it has started. 

    Thanks.

    Regards,

    Stefano

  • Hi Stefano,

    It depends if you want your flag to also be set after a Softdevice or bootloader update.

    Regards,

    Vidar

  • no, just after a successful application update. Ok thanks, I'll close the ticket.

Reply Children
No Data
Related