OTA DFU on 54L15

[Allan-led]

Hi all,

we are wondering if there is a clean and reliable way to perform DFU on 54L15 via Thread? Our scenario: once the products get shipped to customers, the border router should be able to send some sort of message via Thread, which includes the necessary information for the new firmware. We have a server and we can "control" the border routers from our office if needed.

I have tested the sample MCU Update code in V3.0.1 of the SDK, but it uses Bluetooth and we are not sure about enabling Bluetooth features for the project.

I have also seen previous postings about this topic. There were some promising links about OTA DFU with Thread, but they might have been archived. 

Until this point, we have been letting the partitions.yml file generate without the explicit interference of a custom pm_static file. Our partitions.yml currently looks as follows with CONFIG_BOOTLOADER_MCUBOOT enabled:

app:
  address: 0x0
  end_address: 0x163000
  region: flash_primary
  size: 0x163000
bootconf:
  address: 0xffd080
  end_address: 0xffd084
  region: bootconf
  size: 0x4
otp:
  address: 0xffd500
  end_address: 0xffd9fc
  region: otp
  size: 0x4fc
settings_storage:
  address: 0x163000
  end_address: 0x165000
  placement:
    after:
    - app
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_primary:
  address: 0x20000000
  end_address: 0x2002f000
  region: sram_primary
  size: 0x2f000

Is our app too big for this purpose? In the sample code, the pm_static.yml file defines 2 sections for 2 versions of code. I don't think we will be able to fit our code twice on RAM. Please correct me if this is incorrect. 

Please let me know how feasible this is, and whether this has been attempted before. If possible, please let me know about what might the process look like. Thanks!

Best regards,

Allan 

[Vidar Berg]

Hi Allan,

The bootloader is enabled through Sysbuild  in SDK v2.7.0 and later. This means you need to enable SB_CONFIG_BOOTLOADER_MCUBOOT in sysbuild for the bootloader to become included in the build. After the bootloader is included you will see that MCUBoot starts at address 0x0 instead of the app in the generated partitions.yml file. 

Is our app too big for this purpose? In the sample code, the pm_static.yml file defines 2 sections for 2 versions of code. I don't think we will be able to fit our code twice on RAM. Please correct me if this is incorrect. 

I see tha 0x163000 bytes are allocated to the app region, which definitely is too big for DFU. But I don't know the actual size of the application. You may find this thread relevant Problem with flash overflow when adding BLE DFU on nRF52833  

Unfortunately, we do not have any samples that demonstrate how you can transfer FW updates directly with Thread as Sigurd points out here  DFU over thread(NCS v2.4.0)  . However, if you are able to manage the transfer, you can use the DFU target library to help store the update to the secondary slot so it later can be activated by the bootloader.

Best regards,

Vidar