Hi Nordic teams,
I am working on integrating single-slot DFU for the nRF54H20 based on the throughput example. However, I noticed a difference in how the Bluetooth controller is initialized, as detailed below:
Environment:
- Board: nRF54H20 DK 0.9.2
- NCS version: v3.3.0
- Samples: `samples/bluetooth/throughput` (original) vs. custom integration with `samples/dfu/single_slot`
When running the original bluetooth/throughput sample, the following log is observed at startup:
NCS330\throughput_original\throughput> west build -b nrf54h20dk/nrf54h20/cpuappthroughput_original\throughput>west build -b nrf54h20dk/nrf54h20/cpuapp NCS330\throughput_original\throughput> nrfutil device recover NCS330\throughput_original\throughput> west flash
Booting nRF Connect SDK v3.3.0-ba167d9f3db4 *** *** Using Zephyr OS v4.3.99-fd9204a02d52 *** Starting Bluetooth Throughput sample W: Num of Controller's ACL packets != ACL bt_conn_tx contexts (3 != 10) I: HW Platform: Nordic Semiconductor (0x0002) I: HW Variant: nRF54Hx (0x0004) I: Firmware: Standard Bluetooth controller (0x00) Version 39.32003 Build 4270654547 I: HCI transport: IPC I: Identity: CA:12:CA:03:D3:7E (random) I: HCI: version 6.2 (0x10) revision 0x40a3, manufacturer 0x0059 I: LMP: version 6.2 (0x10) subver 0x40a3 Bluetooth initialized Press button 0 or type "central" on the central board. Press button 1 or type "peripheral" on the peripheral board.
When the same throughput sample is integrated with the Single-Slot DFU mechanism, the following log is observed instead:
throughput_dfu_single_slot.zip
NCS330\throughput_dfu_single_slot\throughput>west build -p -b nrf54h20dk/nrf54h20/cpuapp -T ./sample.dfu.single_slot.fw_loader_update.fw_loader_entrance_boot_req.nrf54h20 NCS330\throughput_dfu_single_slot\throughput>nrfutil device recover NCS330\throughput_dfu_single_slot\throughput>west flash
Booting My Application v3.3.0-12d10162f8e0 *** *** Using nRF Connect SDK v3.3.0-ba167d9f3db4 *** *** Using Zephyr OS v4.3.99-fd9204a02d52 *** Starting Bluetooth Throughput sample W: Controller to host flow control not supported W: Num of Controller's ACL packets != ACL bt_conn_tx contexts (3 != 10) W: opcode 0xfc01 status 0x01 W: Vendor HCI extensions not available W: Read Static Addresses command not available I: HCI transport: IPC I: Identity: E1:6C:FC:F5:BE:52 (random) I: HCI: version 6.2 (0x10) revision 0x40a3, manufacturer 0x0059 I: LMP: version 6.2 (0x10) subver 0x40a3 Bluetooth initialized V2.0.3 build time: May 26 2026 09:41:40 Press button 0 or type "central" on the central board. Press button 1 or type "peripheral" on the peripheral board.
Observed Differences:
1. W: Controller to host flow control not supported
- This warning does not appear in the original sample. It suggests the BLE controller version or configuration used in the DFU-integrated build does not support controller-to-host flow control.
2. W: opcode 0xfc01 status 0x01 / W: Vendor HCI extensions not available
- These warnings indicate that vendor-specific HCI commands are not being acknowledged by the controller in the DFU-integrated build.
3. W: Read Static Addresses command not available
- This suggests the controller in the DFU-integrated build does not support this HCI command.
4. Missing hardware/firmware info lines
- The `I: HW Platform`, `I: HW Variant`, and `I: Firmware` lines are absent in the DFU-integrated build log, which may indicate the controller is not fully initialized or is a different version/configuration.
Question:
What causes these differences between the two builds? Is it related to the IPC radio firmware version, the MCUboot/TF-M configuration, or a mismatch in the BLE controller configuration when Single-Slot DFU is integrated?
Thanks.
