BT hci_spi on nrf54L15 - multiple registrations of same IRQ when using CONFIG_BT_LL_SW_SPLIT

Hi,

We are on NCS v2.9.1

We have an existing project on based on the nrf52832, which we use as a hci_spi controller. There, CONFIG_BT_LL_SW_SPLIT is set.
We are now porting that to the nrf54L15 for use on future projects.

When building, we get the following error message:

gen_isr_tables.py: error: multiple registrations at table_index 227 for irq 227 (0xe3)
Existing handler 0x5653d, new handler 0x5fa19
Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?

The Bluetooth LLL registers an interrupt with the GRTC, and the nrfx_grtc_timer does as well:

zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll.c:241

- zephyr/drivers/timer/nrf_grtc_timer.c:472

Switching to SOFTDEVICE instead of BT_LL_SW_SPLIT, the issue goes away, and the application seems to function ok. But since I have now replaced half of the Bluetooth stack, I need to do a lot of verification to make sure everything is still fine. The only additional warning generated by our build is this:

warning: BT_CTLR_RX_BUFFERS (defined at subsys/bluetooth/controller/Kconfig:225) was assigned the
value '9' but got the value ''. Check these unsatisfied dependencies: BT_LL_SW_SPLIT (=n). See
docs.zephyrproject.org/.../kconfig.html and/or look up
BT_CTLR_RX_BUFFERS in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.

But I assume I just have to find an appropriate config for the softdevice, if there is any.

-------------------------------------

I have managed to recreate the exact same issue using the hci_spi sample in zephyr, for easier debugging. The sample is under zephyr/samples/bluetooth/hci_spi.
I have added a nrf54l15dk_nrf54l15_cpuapp_ns.overlay and configurations for both using LL_SW_SPLIT or SOFTDEVICE. Please see the attached zip files:

7838.hci_spi_softdevice.zip                             0005.hci_spi_ll_sw_split.zip

build with west build -b nrf54l15dk/nrf54l15/cpuapp/ns

The same IRQ error is generated in the ll_sw_split configuration. The build succeeds in the softdevice configuration.

The only difference between them is this:

LL_SW_SPLIT overlay:

LL_SW_SPLIT prj.conf:

SOFTDEVICE overlay:

SOFTDEVICE prj.conf:

------------------------------------------------------

I tried using CONFIG_SHARED_INTERRUPTS=y. This makes the LL_SW configuration buildable, but it behaves very weirdly at run-time:
1. It is way harder to establish a connection.
2. When it is established, it drops almost immediately with the following warning printed:

[00:01:34.744,537] <inf> ble_conn: Connected. Peer address: D8:F8:83:0F:6D:DC (public)
[00:01:34.745,025] <inf> ble_ctrl: BLE connected
[00:01:34.988,616] <wrn> bt_conn: conn 0x200101b0 failed to establish. RF noise?
[00:01:34.988,952] <inf> ble_conn: Disconnected. Peer address: D8:F8:83:0F:6D:DC (public) (reason 3e)

I also do not see any way to configure the LLL and GRTC_TIMER drivers to use different interrupts of the GRTC (the nrf54l15 datasheet says there are 4 GRTC interrupts)

------------------------------------------------------

So, our questions:

1. is the only working solution to use the softdevice?
2. Can we configure LLL or GRTC_TIMER to use different interrupts?
3. Is this a known issue? Can we expect it to be fixed in the next NCS release?
4. Did we miss anything else? Is there some other way to make this work?

Note:
I am not quite sure why the original nrf52832 code uses 
CONFIG_BT_LL_SW_SPLIT, but we would like to keep the same configuration, since we have tuned a lot of the BT configs, and are unsure how sofdevice will handle them.

Thank you and best regards,
Tjaž Vračko

  • Hi Tjaz,

    I am not quite sure why the original nrf52832 code uses CONFIG_BT_LL_SW_SPLIT, but we would like to keep the same configuration, since we have tuned a lot of the BT configs, and are unsure how sofdevice will handle them.

    Understood. You do have more control when everything is open source. One thing to note is that SDC is what we recommend for production, and it might be that not all zephyr controller revisions have BLE QDIDs - I would have to check.

    Was the project with '32 on 2.9.1, or have you migrated NCS versions as well?

    Regards,

    Elfving

Related