Device Firmware Update (DFU) distributor in nRF54L15

Question

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:

I have prepared a firmware built directly from the sample and a firmware with only the version updated.
I flashed the first one to DKs.
I used the nRF Mesh App to provision and register the App Key.
I used the nRF Device Manager App to upload the new firmware to one of DKs.

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

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

Maria Gilje · Accepted Answer

a.da said: What triggers the distributor to start its own update? Doesn't it start its own update even after all targets have finished updating? 
 You can find relevant documentation on self-update here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/bluetooth/mesh/dfu/distributor/README.html#self-update 
 a.da said: The 'progress' remains at 50(%?), is this expected? 
 Yes, the output is formated accordic to the Mesh spec where transfer progress is calculated in 2% steps. 
 a.da said: Therefore, I want to know the minimum configuration for this sample. 
 Since the sample is not supported by default, we don't have a minimum configuration at hand. You can use the Memory footprint optimization guidelines to find Kconfig values which can be used for optimization. The Bluetooth Mesh section has a decently long list of possibilities. 
 Best regards, 
 Maria

Device Firmware Update (DFU) distributor in nRF54L15

Top Replies