Firmware update without DFU

[Jithin A]

Hi, I am new to the Nordic environment. So far I have done all the integration by going through your examples code which is very good.

Now, one thing I have no knowledge about is updating the firmware image(non-secure + TF-M) without using DFU.

I do not want FW update over DFU for some personal reasons.

Please guide me to any reference or documentation for how to build a bootloader and configure the application image to run with the bootloader and do OTA update.

I do not know from where to start for implementing the OTA update.

Thank you in advance.

My setup:

NRF SDK: v2.2.0

Board: nRF5340-DK

[Marte Myrvold]

Hi,

Can you clarify what you mean by not wanting to do fw update over DFU? DFU is device firmware update, so if you want to update your device, then this will be DFU, Do you mean that you do not want to update the device over serial (e.g. UART), but only over the air?

Best regards,

Marte

[Jithin A]

The reason I do not want to do DFU is we are using our own crypto algorithms to transfer any data over BLE.

Let me explain what I need to do actually

I get the FW image over BLE which later it is decrypted and is stored in the desired partition.

Now on the next boot, I need the bootloader to check if there is any new image downloaded and boot the new image if so.

[Jithin A]

Any update on the above.

[Jithin A]

Hello, just to let you know that I need to implement this onto my project with high priority.

Please let me know if I am missing anything to explain my need.

Please help me with the integration ASAP.

[Marte Myrvold]

Hi,

Thank you for clarifying. As long as you have MCUboot enabled and save the image in the correct area in flash and with the correct metadata (header + trailer), then the transport method is irrelevant. To enable MCUboot you must set the following configuration in prj.conf:

CONFIG_BOOTLOADER_MCUBOOT=y

The metadata can contain information about booting information, image hash, etc. You can find more about this, both header and trailer, in MCUboot Bootloader Design. There you will also find information about image slots, swapping, and more.

As for area in flash, when you enable MCUboot with the configuration above, the partition manager will automatically configure partitions. You can see the partitions after you have built the application by running the following command:

west build -t partition_manager_report

If you are using VS Code with our extension you can also see it by selecting the Memory report action, and going to Partitions in the generated report. As an example, adding MCUboot support to the Blinky sample, the partitions will look lilke this:

  flash_primary (0x100000 - 1024kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x7a000 - 488kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x79e00 - 487kB)-+
| 0xc200: app (0x79e00 - 487kB)                   |
+-------------------------------------------------+
| 0x86000: mcuboot_secondary (0x7a000 - 488kB)    |
+-------------------------------------------------+

  sram_primary (0x40000 - 256kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

As you can see, here the primary MCUboot image slot starts at 0xc000, and the secondary image slot at 0x86000.

Best regards,

Marte