Differences in BLE Controller Initialization logs between throughput sample and throughput with Single-Slot DFU Integration

Question

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: 
 throughput_original.zip 
 
 NCS330	hroughput_original	hroughput> west build -b nrf54h20dk/nrf54h20/cpuappthroughput_original	hroughput>west build -b nrf54h20dk/nrf54h20/cpuapp
NCS330	hroughput_original	hroughput> nrfutil device recover
NCS330	hroughput_original	hroughput> 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	hroughput_dfu_single_slot	hroughput>west build -p -b nrf54h20dk/nrf54h20/cpuapp -T ./sample.dfu.single_slot.fw_loader_update.fw_loader_entrance_boot_req.nrf54h20 
NCS330	hroughput_dfu_single_slot	hroughput>nrfutil device recover
NCS330	hroughput_dfu_single_slot	hroughput>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.

Hung Bui · Accepted Answer

Hi Lam, I think you pinpointed the cause. Fwloader ipc image should be in cpurad_slot1. The configured you had earlier made the app to use the BLE controller of the Fwloader instead of its own (slot 0). 
 I got some info from R&D, which related to another ticket but could be relevant to you: 
 
 The firmware loader mode (single slot) does not support multiple images (from the bootloader perspective). That's why if you enable it on nRF54H20, the "merged slot" approach is automatically enabled. 
 
 The partitioning of the BLE-enabled application should be fairly similar to what you can find in the Direct XIP (merged_slot suffix) configuration of the smp_svr sample as well as the A/B sample: 
 - slot0_partition: the merged app+radio application partition 
 - cpuapp_slot0_partition: the main application partition 
 - cpurad_slot0_partition: the main radio partition 
 - slot1_partition: the merged app+radio FW loader partition 
 - cpuapp_slot1_partition (also: fw_loader_partition): the FW loader application partition 
 - cpurad_slot1_partition: the FW loader radio partition (note: if the main application uses radio, the FW loader partition is no longer the "cpurad_slot0_partition" but "cpurad_slot1_partition". This is a consequence of a logic inside the soc.c that tries to find the proper radio slot for a given application image to boot. This change must be also applied inside the sysbuild/fw_loader_ipc_radio.overlay file so the code,partition is set to point the correct partititon). 
 
 When the radio is merged with the application, the application image might not be the last one in the merged partition. If so, please adjust the MCUBOOT_IMAGES_ROM_END_OFFSET_AUTO Kconfig value by replacing the "single_slot" image name with the appropriate radio image name.

Differences in BLE Controller Initialization logs between throughput sample and throughput with Single-Slot DFU Integration

Top Replies