Compilation Error when Configuring NRF21540 on NRF5340

[kpi_xie]

I've been using ICMSG's IPC to exchange HCI messages between the netcore and appcore, and using SPI to exchange HCI information between the host and appcore. This setup enables HCI message transfer between the netcore and the host, and it works properly.

However, when I configure the NRF21540 FEM in the netcore, I get an error indicating that mpsl_work_q is undefined in hci_driver.c. I traced the code and found that mpsl_work_q is defined in mpsl_init.c, and it requires CONFIG_MPSL_FEM_ONLY=n. But when CONFIG_FEM=y is set, it automatically selects MPSL_FEM_ONLY.

So it seems like there's a conflict between my HCI and FEM configurations. How can I configure it to ensure both FEM and HCI are enabled at the same time?

[Hieu]

Hi kpi_xie,

What application are you having on the netcore? A regular BLE controller, or something custom of your own?

What version of the SDK are you using?

Hieu

[kpi_xie]

my sdk is ncs 2.6.1

The netcore has a simple program whose function is to send messages from the BLE rx_queue to the appcore via ICMSG IPC, and forward the messages received through IPC to the Bluetooth module via bt_send. The program is based on the hci_spi implementation but replaces SPI with IPC.

Below are the configuration items related to FEM and HCI in my prj.conf.

CONFIG_BT=y

CONFIG_BT_HCI_RAW=y

CONFIG_BT_MAX_CONN=8

CONFIG_BT_TINYCRYPT_ECC=n

CONFIG_BT_HCI_RAW_RESERVE=1

CONFIG_FEM=y

CONFIG_FEM_AL_LIB=y

CONFIG_MPSL_FEM=y

CONFIG_SPI=y

CONFIG_SPI_NRFX=y

CONFIG_NRFX_SPIM0=y

# CONFIG_MPSL_FEM_ONLY=y

CONFIG_MPSL_FEM_NRF21540_GPIO=y

# CONFIG_MPSL_FEM_NRF21540_GPIO_SPI=y

CONFIG_MPSL_FEM_NRF21540_RUNTIME_PA_GAIN_CONTROL=y

CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTA=7

CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTB=7

CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB=7

CONFIG_MPSL_FEM_NRF21540_RX_GAIN_DB=13

The configuration related to FEM in the DTS overlay file of netcore.

&spi0 {

    status = "okay";

    cs-gpios = <&gpio0 11 GPIO_ACTIVE_LOW>;

    pinctrl-0 = <&spi0_default>;

    pinctrl-1 = <&spi0_sleep>;

    pinctrl-names = "default", "sleep";

    nrf_radio_fem_spi: nrf21540_fem_spi@0 {

        compatible = "nordic,nrf21540-fem-spi";

        reg = <0>;

        spi-max-frequency = <8000000>;

        status = "okay";

    };

};

&radio{

    /delete-property/ ieee802154-supported;

    fem = <&nrf_radio_fem>;

};

/ {

     nrf_radio_fem: nrf21540_fem {

        compatible = "nordic,nrf21540-fem";

        tx-en-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;

        rx-en-gpios = <&gpio0 5 GPIO_ACTIVE_HIGH>;

        pdn-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;

        ant-sel-gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>;

        mode-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;

        spi-if = <&nrf_radio_fem_spi>;

        supply-voltage-mv = <3000>;

        status = "okay";

    };

}

[Hieu]

We are diverging to a different topic now, while on DevZone we would like to keep each case focused on one topic. This is a quick answer, but for further follow-up, please have a new case.

These configs likely have some issue

CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTA=13
CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTB=7
CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB=13
CONFIG_MPSL_FEM_NRF21540_RX_GAIN_DB=13

Think of POUTA and POUTB as quick preset gain level that can be switched to using the GPIO interface. The nRF21540 by default has 10dB and 20dB gain for those output. It has one-time programmable (OTP) registers to override that level.

The CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTA and POUTB config is to tell the system what the hardware nRF21540 has been configured to. Unless you have configured those OTP registers, don't set them

CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB is meant to be use when using the GPIO interface without the MODE pin. Refer here.
I don't remember clearly if it works in your context. If RSSI doesn't change at all, then it probably isn't.

Another thing is that this only sets the gain. However, MPSL controls both the output gain and the nRF5340's TX Power. It could be that MPSL is still targeting 0dBm total TX Power, thus it could be lowering the nRF5340's TX Power, resulting in a lower total result. Because of the wrong POUTA config, it is likely doing the math wrong.

You should use CONFIG_BT_CTLR_TX_PWR_ANTENNA instead. MPSL will use its own algorithm to finely change nRF5340 TX Power and the nRF21540 gain (over SPI) to get as close to the configured value as possible, taking into account also influences from temperature and voltage.

Hope that helps. For further issues with this topic, please open a new case.

[kpi_xie]

Hi Hieu 

Thank you for your support. My FEM seems to be working now. For the time being, we are only using the mode controlled by GPIO; the GPIO+SPI mode is not needed for now.

Thanks.

[Hieu]

Hi kip_xie,

Good to know it is working. From the compiled Kconfig you sent earlier, I see CONFIG_MPSL_FEM_NRF21540_GPIO_SPI is enabled, and that would indicate MPSL is controlling the FEM with GPIO and SPI though. Shouldn't be any issue, as long as you have the physical connection setup properly.

[kpi_xie]

Our circuit schematic has assigned pins for SPI, but we don't actually use it. Additionally, I have tested the GPIO+SPI control mode, which didn't seem to work. Later, I switched to using GPIO only, which works fine.

Now, the configuration items in .config are as follows:

#

# Multiprotocol service layer (MPSL)

#

# CONFIG_MPSL_FEM_ONLY is not set

CONFIG_MPSL_FEM_ANY_SUPPORT=y

CONFIG_MPSL_FEM_NRF21540_GPIO_SUPPORT=y

CONFIG_MPSL_FEM_NCS_SUPPORTED_FEM_USED=y

CONFIG_MPSL_FEM_API_AVAILABLE=y

CONFIG_MPSL_FEM=y

CONFIG_MPSL_FEM_NRF21540_GPIO=y

CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB=20

CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTA=10

CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTB=20

CONFIG_MPSL_FEM_NRF21540_RX_GAIN_DB=20

CONFIG_MPSL_FEM_NRF21540_RUNTIME_PA_GAIN_CONTROL=y

# CONFIG_MPSL_FEM_POWER_MODEL is not set

CONFIG_MPSL_FEM_DEVICE_CONFIG_254=y

[Hieu]

How did you test GPIO + SPI? 

The control of the FEM is done automatically by MPSL. Perhaps that's why you can have some success when using the GPIO interface, but not when SPI is involved because the entire SPI peripheral is controlled by MPSL.

The idea is that MPSL will take care of everything, and you don't have to worry about controlling the FEM directly. You just send requests to MPSL/BLE controller for what TX Power you want to achieve.

But I see that I am now the one pulling this case off track. If your findings do not match with my guesses, please open a different case if you want to resolve it.