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

[Allan-led]

Hi Vidar,

Thanks for your insights. I was wondering if you could elaborate on how to shrink the app size? In the link you gave above, you talked about creating a sysbuild/mcuboot directory with a prj.conf file. You provided the conf file as well and I have included that in the directory.

However, it seems like creating a new build with this new prj.conf file included doesn't seem to shrink my project size. 

Currently, I'm testing for the changes in partitions.yml with the given CLI sample from the SDK. I was wondering why does such a minimal project like CLI take up SO MUCH space, such that it is not possible for DFU? Below is the partitions.yml for the CLI sample, this should be reproducible on your guys' end as well. I am using the 54l15dk

app:
  address: 0x0
  end_address: 0x17b000
  region: flash_primary
  size: 0x17b000
bootconf:
  address: 0xffd080
  end_address: 0xffd084
  region: bootconf
  size: 0x4
otp:
  address: 0xffd500
  end_address: 0xffd9fc
  region: otp
  size: 0x4fc
settings_storage:
  address: 0x17b000
  end_address: 0x17d000
  placement:
    after:
    - app
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000

Best regards,

Allan

[Vidar Berg]

Hi Allan,

Please look at the build output to see the actual size of your application. This is not the same as the size you have allocated the app partition.  For comparison this is what I get when I build the same sample from SDK v3.0.2 with SB_CONFIG_BOOTLOADER_MCUBOOT=y

Build output

Generated partitions.yml

EMPTY_0:
  address: 0xd800
  end_address: 0xe000
  placement:
    after:
    - mcuboot
  region: flash_primary
  size: 0x800
EMPTY_1:
  address: 0x174000
  end_address: 0x175000
  placement:
    after:
    - mcuboot_secondary
  region: flash_primary
  size: 0x1000
app:
  address: 0xe800
  end_address: 0xc1000
  region: flash_primary
  size: 0xb2800
bootconf:
  address: 0xffd080
  end_address: 0xffd084
  region: bootconf
  size: 0x4
mcuboot:
  address: 0x0
  end_address: 0xd800
  placement:
    align:
      end: 0x1000
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xd800
mcuboot_pad:
  address: 0xe000
  end_address: 0xe800
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x800
mcuboot_primary:
  address: 0xe000
  end_address: 0xc1000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0xb3000
  span: *id001
mcuboot_primary_app:
  address: 0xe800
  end_address: 0xc1000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xb2800
  span: *id002
mcuboot_secondary:
  address: 0xc1000
  end_address: 0x174000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0xb3000
otp:
  address: 0xffd500
  end_address: 0xffd9fc
  region: otp
  size: 0x4fc
settings_storage:
  address: 0x175000
  end_address: 0x17d000
  placement:
    after:
    - app
    align:
      start: 0x1000
    before:
    - end
  region: flash_primary
  size: 0x8000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000

Best regards,

Vidar

[Allan-led]

Thanks Vidar,

I was not setting the SB_CONFIG_BOOTLOADER_MCUBOOT correctly. After setting it, the size was approximately halved. Do you have any recommendations for how to get started with DFU?

Best regards,

Allan

[Marte Myrvold]

Hi Allan,

Vidar is out of office, so this ticket has been assigned to me.

The best place to learn about DFU in the nRF Connect SDK is Lesson 9 – Bootloaders and DFU/FOTA in our nRF Connect SDK Intermediate course on DevAcademy.

Best regards,
Marte