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

[lammobile]

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\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.

[Hung Bui]

Hi Lam, 
Thanks for the  instruction. I have reproduced what you observed here. 
I'm checking with the team to get more insight. 

My understanding is that when you enable fw_loader with BLE on nRF54H it will add a controller to the radio core (in addition to the main application's BLE controller). And the way the radio core booting may be slightly changed (for example log configuration) and you may see different log. 

Do you see any change in the BLE behavior when testing with throughput sample or other BLE sample ? 

[lammobile]

Hi Hung,

Good news: The issue is resolved. I updated the partition labels as follows:

• Changed cpurad_slot0_ipc_radio_partition --> cpurad_slot0_partition (under slot0_partition: 256KB for ipc_radio to interface with the app).

• Changed cpurad_slot0_partition --> cpurad_slot1_partition (under slot1_partition to configure ipc_radio for fw_loader).

Is there a defined naming convention or policy for these partition labels?

[Hung Bui]

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.

[lammobile]

Hi Hung,

Thank you for the information. That makes sense. Thanks a lot.