Device Firmware Update (DFU) distributor in nRF54L15

Hello.

I tested the DFU distributor sample using two nRF54L15DKs.
I have three questions.

1. Apply is not completing.
The firmware transfer seems to have completed, but Apply did not.
The steps are as follows:

  1. I have prepared a firmware built directly from the sample and a firmware with only the version updated.
  2. I flashed the first one to DKs.
  3. I used the nRF Mesh App to provision and register the App Key.
  4. I used the nRF Device Manager App to upload the new firmware to one of DKs.
  5. I sent a Shell command using J-Link RTT Viewer.
      < mesh models dfu slot add 426536 59000200000000000000 0200000000000000288206013e9ffbc50200
      < mesh models dfd receivers-add 0x000C,0
      < mesh models dfd start 0 0
  6. The transfer seems to have completed, but the log "'Distribution phase changed to Completed'" did not appear.
    The Distributor still seems to be processing the DFU.
    00> rtt:~$ [01:09:56.480,851] <dbg> bt_mesh_dfu_cli: handle_status: 2 phase: 0, cur state: 4
    00> rtt:~$ [01:09:56.480,860] <dbg> bt_mesh_dfu_cli: handle_status: Response received with Idle phase
    00> rtt:~$ [01:09:56.480,867] <dbg> bt_mesh_blob_cli: blob_cli_broadcast_rsp: 0x000c, pending: 1
    00> rtt:~$ [01:09:56.480,882] <dbg> bt_mesh_blob_cli: broadcast_complete: continuing
    00> rtt:~$ [01:09:56.480,893] <dbg> bt_mesh_dfu_cli: dfu_applied: 
    00> rtt:~$ [01:09:56.480,902] <dbg> bt_mesh_dfu_cli: confirm: 
    00> rtt:~$ [01:09:56.480,910] <dbg> bt_mesh_blob_cli: blob_cli_broadcast: 1 targets
    00> rtt:~$ [01:09:56.632,043] <dbg> bt_mesh_dfu_cli: handle_info_status: Image list from 0x000c from index 0
    00> rtt:~$ [01:09:56.632,070] <dbg> brtt:~$ [01:10:22.431,384] <wrn> bt_l2cap: Ignoring data for unknown channel ID 0x003a
    00> rtt:~$ rtt:~$ 
      < mesh models dfd receivers-get 0 8
    00> mesh models dfd receivers-get 0 8
    00> {
    00>   "target_cnt": 1,
    00>   "targets": {
    00>     "0": { "blob_addr": 12, "phase": 8, "status": 0, "blob_status": 0, "progress": 50, "img_idx": 0 }
    00>   }
    00> }

    However, the Target automatically rebooted, and the Firmware was updated.
    00> rtt:~$ [01:09:41.695,868] <dbg> bt_mesh_blob_srv: handle_block_start: 104: (105/105)
    00>   size: 552
    00>   chunk size: 113
    00>   chunk count: 5
    00> rtt:~$ [01:09:41.695,885] <dbg> bt_mesh_blob_srv: block_status_rsp: Status: 0, missing: 5/5
    00> rtt:~$ [01:09:42.370,914] <dbg> bt_mesh_blob_srv: handle_chunk: 1/5 (113 bytes)
    00> rtt:~$ rtt:~$ [01:09:43.018,789] <dbg> bt_mesh_blob_srv: handle_chunk: 2/5 (113 bytes)
    00> rtt:~$ [01:09:43.591,810] <dbg> bt_mesh_blob_srv: handle_chunk: 3/5 (113 bytes)
    00> rtt:~$ rtt:~$ [01:09:44.202,913] <dbg> bt_mesh_blob_srv: handle_chunk: 4/5 (113 bytes)
    00> rtt:~$ rtt:~$ [
    00> rtt:~$ *** Booting Mesh DFU Distributor v3.0.0-ea2277162fb6 ***
    00> rtt:~$ *** Using nRF Connect SDK v3.0.0-3bfc46578e42 ***
    00> rtt:~$ *** Using Zephyr OS v4.0.99-3e0ce7636fa6 ***
    00> rtt:~$ Initializing...
    00> rtt:~$ Current image version: 2.0.0+0
    00> rtt:~$ [01:09:50.621,187] <inf> fs_zms: 2 Sectors of 4096 bytes
    00> rtt:~$ [01:09:50.621,196] <inf> fs_zms: alloc wra: 0, 9b0
    00> rtt:~$ [01:09:50.621,203] <inf> fs_zms: data wra: 0, 3f0
    00> rtt:~$ [01:09:50.621,721] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision: 
    00>                                             c7 53 7d bc 06 12 f7 c0  b3 3a 3e 28 8e 56 1e d7 |.S}..... .:>(.V..
    00>                                             a0 be 95 b0                                      |....             
    00> rtt:~$ [01:09:50.622,794] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
    00> [01:09:55.113,786] <dbg> bt_mesh_dfu_srv: handle_apply: 
    00> rtt:~$ [01:09:55.113,799] <wrn> bt_mesh_dfu_srv: Apply: Invalid phase 0
    00> rtt:~$ [01:09:55.183,951] <dbg> bt_mesh_dfu_srv: handle_info_get: from 0 (limit: 255)

What kind of situation is this?
Full Log:

250502_distributor.log

250502_targetlog.log

2. The transfer takes time.
It took about one hour to send 426536 bytes.
There are no obstructions between the DKs, and they are adjacent.
Is this the expected specification?

3. Minimum configuration
The build failed for nrf54l15dk/nrf54l15/cpuapp/ns.
The RAM region is overflowing.
What is the minimum configuration to guarantee the DFU Distributor?

c:/ncs/toolchains/0b393f9e1b/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr\zephyr_pre0.elf section 'noinit' will not fit in region`RAM'
c:/ncs/toolchains/0b393f9e1b/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: region `RAM' overflowed by 6322 bytes

Thanks for reading.

a.da

  • Hello, a.da

    Our Mesh and DFU experts are out of office today, so we need some time to address all of your points. I'll address point 2 and 3 now and one of our Mesh/DFU experts can take a look at this next week.

    2. The transfer takes time.
    It took about one hour to send 426536 bytes.
    There are no obstructions between the DKs, and they are adjacent.
    Is this the expected specification?

    Yes, this seems correct. DFU for Bluetooth Mesh is quite slow because of the low throughput. See i.e. this reply on an older case which addresses an application of a similar size to yours.

    3. Minimum configuration
    The build failed for nrf54l15dk/nrf54l15/cpuapp/ns.
    The RAM region is overflowing.
    What is the minimum configuration to guarantee the DFU Distributor?

    The DFU Distributor sample does not support the nrf54l15dk/nrf54l15/cpuapp/ns build target, but it does support the nrf54l15dk/nrf54l15/cpuapp build target. See the memory report in the build log for details on how much memory is left after building.

    Best regards,

    Maria

Related