Start of application takes ages after DFU process is complete

RE: Start of application takes ages after DFU process is complete

ste2108 — Tue, 23 Apr 2024 11:34:52 GMT

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

RE: Start of application takes ages after DFU process is complete

Vidar Berg — Tue, 23 Apr 2024 11:33:12 GMT

Hi Stefano,

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

Regards,

Vidar

RE: Start of application takes ages after DFU process is complete

ste2108 — Mon, 22 Apr 2024 12:33:20 GMT

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

RE: Start of application takes ages after DFU process is complete

Vidar Berg — Mon, 22 Apr 2024 09:25:13 GMT

Maybe after app_active() returns with NRF_SUCCESS here:

RE: Start of application takes ages after DFU process is complete

ste2108 — Mon, 22 Apr 2024 08:07:38 GMT

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

RE: Start of application takes ages after DFU process is complete

Vidar Berg — Fri, 19 Apr 2024 05:43:02 GMT

That can happen to the best of us 🙂 Yes, the bootloader is reset after the on_dfu_complete() callback has been invoked, and the image is copied from bank 1 to bank 0 on the subsequent startup.

Regards,

Vidar

RE: Start of application takes ages after DFU process is complete

ste2108 — Thu, 18 Apr 2024 15:17:08 GMT

Right, I mixed bits with bytes as for the word :) the numbers are getting close to what I see experimentally then. I will perform the test you suggest and let you know, but can you please confirm that the callback on_dfu_complete in nrf_dfu_req_handler.c is called before the new image is moved from bank 1 to bank 0? Cause otherwise there is smtg wrong in the way I do things.

Thanks.

Regards,

Stefano

RE: Start of application takes ages after DFU process is complete

Vidar Berg — Thu, 18 Apr 2024 15:06:35 GMT

Dear Stefano,

No problem. Regarding the calculation, there are 1024 words in a page, so I think it should be 85+(0,041*(4096/4)) = 127 ms. We also need to account for the time it takes to update the progress in the BL settings page.

nrf_bootloader_fw_activation.c->app_activate()->image_copy

You can try increasing the NRF_BL_FW_COPY_PROGRESS_STORE_STEP value in sdk_config.h to see if that helps. This controls how frequent the settings page will be updated during the activation process.

Regards,

Vidar

RE: Start of application takes ages after DFU process is complete

ste2108 — Thu, 18 Apr 2024 14:44:07 GMT

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

RE: Start of application takes ages after DFU process is complete

Vidar Berg — Thu, 18 Apr 2024 14:16:42 GMT

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