OTA DFU for thread product

RE: OTA DFU for thread product

Vidar Berg — Wed, 11 Oct 2023 06:16:48 GMT

The bootloader will verify the version requirements and the integrity of the received FW (i.e., the .bin file). You can read more about this here: Validation

RE: OTA DFU for thread product

xingjida — Wed, 11 Oct 2023 03:17:52 GMT

Thanks. What does bootloader verify, before it copies the .bin file from bank 1 to bank 0?

RE: OTA DFU for thread product

Vidar Berg — Tue, 10 Oct 2023 10:16:21 GMT

Hi,

Thank you for the clarification. A potential solution could be to modify the bootloader so that it only copies the .bin file from bank 1. It might be sufficient to change the nrf_dfu_bank1_start_addr() implementation to return the address where the FW image begins, rather than the actual bank 1 address.

RE: OTA DFU for thread product

xingjida — Tue, 10 Oct 2023 08:40:24 GMT

Hi Vidar,

For our situation, any suggestions about how to implement? Thank.

RE: OTA DFU for thread product

xingjida — Tue, 10 Oct 2023 07:54:38 GMT

Thanks for the explanation. Currently the bin file only has header + .dat + .bin(firmware). In the future, another image for another MCU may be added to the file, but the image will send to the other MCU through UART for firmware update, so it will not really affect the OTA firmware update.

RE: OTA DFU for thread product

Vidar Berg — Tue, 10 Oct 2023 07:32:08 GMT

Hi,

1. The bootloader will always copy the image from the bank1 address which is found with the nrf_dfu_bank1_start_addr() function.

2. This is not something that is supported in our implementation, so it will require changes to the application/bootloader to make it work. What is supposed to happen with the other image that is not part of the new application?

RE: OTA DFU for thread product

xingjida — Tue, 10 Oct 2023 07:06:10 GMT

Hi Vidar,

Thank you for your reply.

1. How do bootloader decide where is the new firmware to copy to bank 0? Is it based on the information of image type such as "type: application" and "hw_version 0x00000034 (52)"?

2. Yes, I have header information about where the real firmware is in my combined image. I wonder whether there is a way that I can set the real starting address of the firmware to be updated in the applicating firmware.

3. Is there any example that I can refer to for our thread product development?

RE: OTA DFU for thread product

Vidar Berg — Mon, 09 Oct 2023 11:43:41 GMT

Hello,

Unfortunately, the destination to which the bootloader copies the FW image is determined solely by the image type specified in the init command. The init command does not contain address information for the bootloader to use.

Are you uploading multiple FW images to bank 1? If so, you might be able to parse the received image in your application to determine where the second image starts by searching for a known pattern, such as the vector table.

Best regards,

Vidar