DFU flash transport

RE: DFU flash transport

Aurele — Thu, 24 Nov 2022 12:57:21 GMT

Hello

I'm also interested in the same feature as you. Lecram69 did you succeed an implementation of it ? I'm currently using sdk17 with a nRF52840 and a Quectel LTEM modem. On my side, the update will be done from the app : that is to say, I will retrieve the .bin + .dat file from a FTP server and store them in the nRF internal flash.
Then, I guess i need to indicate to the bootloader how to apply the new firmware (copy + erasing the old one), is there any documentation on how to proceed ?

Thank you in advance,

Best regards,

RE: DFU flash transport

Lecram69 — Tue, 04 Oct 2022 11:00:51 GMT

Im using SDK17.1.0

Will try out background DFU. Thx! Still a better solution than creating new transport layer

RE: DFU flash transport

Jørgen Holmefjord — Fri, 30 Sep 2022 13:46:29 GMT

Which SDK version are you using?

Background DFU was originally implemented for the IoT SDK, but the IoT libraries have been removed in the latest nRF5 SDK v17.x.0 releases. This have also been used by other protocols like Thread, Zigbee, and Bluetooth Mesh.

The bootloader part of Background DFU might still be present in nRF5 SDK v17.1.0, by setting NRF_BL_DFU_ALLOW_UPDATE_FROM_APP, but there is no examples showing how to receive the updates in the application, and how to trigger the activation.

RE: DFU flash transport

Lecram69 — Fri, 30 Sep 2022 13:33:30 GMT

The image will be written via Fstorage in 100 Byte chunks in a memory section defined in the linker script (in application): Trigger extern DFU mode, Bootloader should detect the image and update. After this the image should be deleted.

Didnt read anything about Background DFU? Do you have docu for this?

RE: DFU flash transport

Jørgen Holmefjord — Fri, 30 Sep 2022 13:21:33 GMT

Hi,

Can you elaborate a bit on how the image is stored in flash, and how the "uploading" happens? Do you mean that a separate application firmware is stored in the flash of the device at all times?

We have multiple protocols using Background DFU, where the image is received over a transport protocol in application (i.e. not running in the bootloader when receiving the image).

If you can store the image in the same format, it should be quite simple to modify the bootloader to only enable the new image when this is desired.

Using the Serial UART transport layer will likely be easier and not require modifications to the bootloader.

Best regards,
Jørgen