NRF FEM module debug methods.

Hi, I have a FEM module connected with spi0 on an nrf5340 running Zigbee. without the FEM module, the range of the device is around 10 meters (specific environment, not free space), but with the FEM module its like 2 meters which is odd. I want a way to verify the FEM module operation on the CPUNET core without scoping the spi line ( because I dont have physical access).

Here is my current configuration: (code blocks don't work for some reason, IDK why)

on my CPUNET dts I have:

<>

&spi0 {
status = "okay";
pinctrl-0 = <&spi3_default>;
pinctrl-1 = <&spi3_sleep>;
pinctrl-names = "default", "sleep";
cs-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;

nrf_radio_fem_spi: nrf21540_fem_spi@0 {
compatible = "nordic,nrf21540-fem-spi";
status = "okay";
reg = <0>;
spi-max-frequency = <8000000>;
};
};

&radio {
fem=<&nrf_radio_fem>;
};

</>

and

<>

chosen {
zephyr,bt-hci-rpmsg-ipc = &ipc0;
nordic,802154-spinel-ipc = &ipc0;
zephyr,ieee802154 = &ieee802154;
};
nrf_radio_fem: nrf_spi_fem_radio {
compatible = "nordic,nrf21540-fem";
tx-en-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>;
rx-en-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
pdn-gpios = <&gpio0 29 GPIO_ACTIVE_HIGH>;
ant-sel-gpios = <&gpio0 31 GPIO_ACTIVE_HIGH>;
supply-voltage-mv = <3000>;
spi-if = <&nrf_radio_fem_spi>;
};

</>

the SPI pinctrl for CPUNET is:

<>

&pinctrl {
spi3_default: spi3_default { //Radio
group1 {
psels = <NRF_PSEL(SPIM_SCK, 0, 24)>,
<NRF_PSEL(SPIM_MISO, 1, 7)>,
<NRF_PSEL(SPIM_MOSI, 1, 9)>;
};
};
spi3_sleep: spi3_sleep {
group1 {
psels = <NRF_PSEL(SPIM_SCK, 0, 24)>,
<NRF_PSEL(SPIM_MISO, 1, 7)>,
<NRF_PSEL(SPIM_MOSI, 1, 9)>;
low-power-enable;
};
};

};

</>

and the configuration for CPUNET is:

<>

CONFIG_MPSL=y
# CONFIG_MPSL_FEM_ONLY=y
CONFIG_MPSL_FEM=y
CONFIG_MPSL_FEM_NRF21540_GPIO_SPI=y
CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB=20
CONFIG_MPSL_FEM_LOG_LEVEL_DBG=y
CONFIG_PINCTRL=y

</>

For the CPUAPP it has the gpio fwd:

<>

chosen {
zephyr,bt-hci-rpmsg-ipc = &ipc0;
nordic,802154-spinel-ipc = &ipc0;
zephyr,ieee802154 = &ieee802154;
};
gpio_fwd: nrf-gpio-forwarder {
compatible = "nordic,nrf-gpio-forwarder";
status = "okay";
nrf21540-gpio-if {
gpios = <&gpio0 30 0>,
<&gpio1 11 0>,
<&gpio0 29 0>,
<&gpio1 12 0>,
<&gpio0 31 0>;
};
nrf21540-spi-if {
gpios = <&gpio0 24 0>,
<&gpio1 7 0>,
<&gpio1 9 0>,
<&gpio1 8 0>;
};
};

</>

If there is an issue with my configuration please notify me, because I see nothing wrong.

I enabled logging on the CPUNET core and I see logs but I can't see any logs related to the FEM module.

I just got the nrf21540 dk and I will do some tests now, I need your help regarding the verification.

Parents
  • Hello,

    Since the control pins are not accessible for scoping, I suggest that you first debug the application to confirm that the control pins are assigned to the netcore by the pin forwarder. You can use the Peripherals view  to check if the MCUSEL field in PIN_CNF[x] is set to 'NetworkMCU'.

    You can repeat the same when debugging the netcore to verify the pin configurations (if outputs are configured as outputs, etc).

    I was not able to spot any errors in your configuration. But for troubleshooting, it you want to try with the GPIO only mode by enabling MPSL_FEM_NRF21540_GPIO instead of MPSL_FEM_NRF21540_GPIO_SPI.

    Best regards,

    Vidar

Reply
  • Hello,

    Since the control pins are not accessible for scoping, I suggest that you first debug the application to confirm that the control pins are assigned to the netcore by the pin forwarder. You can use the Peripherals view  to check if the MCUSEL field in PIN_CNF[x] is set to 'NetworkMCU'.

    You can repeat the same when debugging the netcore to verify the pin configurations (if outputs are configured as outputs, etc).

    I was not able to spot any errors in your configuration. But for troubleshooting, it you want to try with the GPIO only mode by enabling MPSL_FEM_NRF21540_GPIO instead of MPSL_FEM_NRF21540_GPIO_SPI.

    Best regards,

    Vidar

Children
  • Hi,

    Sorry for taking too much time to reply, It takes so many steps to change things remotely.

    Thank you for your input, I tried the GPIO mode alone, and the results are demonstrably better but first, for what reasons could make SPI mode not working? second, It would be nice to have more range because in GPIO mode, the range is not so good either. I tried those nRF24L01, those devices I can put behind 2 barriers and get decent reception, but for the 21540, I can't get good reception behind 1.

    I checked the PIN_CNF for the pins in the dts, and they are assigned to the NETMCU (both spi pins and regular control pins).

    Since this is an issue that is really causing system disruption and I can't get any work done because of it, I am open to alternative solutions, the current tech does not need to be the one running, it's just what I have.

    Is it possible to put an nrf24l01 next to my nrf5340 zigbee app and get that working without writing much code?

    I want to get this over with before it's too late.

  • Hi,

    I discussed this case with a colleague who has more experience with the Zigbee stack. The issue may be that the output power is configured to 0 dBm by default. This means that if the FEM gain is 20 dB, the output from the nRF5 RADIO will be -20 dBm to achieve the desired TX power on the antenna. I suspect the SPI control, for some reason, causes the gain to be set lower than with the simple GPIO control.

    In your parent application, please try to add the following code snippet after zigbee_enable():

    	nrf_802154_tx_power_set(20);
    
    	int8_t tx_power = nrf_802154_tx_power_get();
    	LOG_INF("TX power at antenna: %d", tx_power);

    And add this include:

    #include "nrf_802154.h"

    It may also be worth testing if you get better range with the nRF21540 DK if your project can be built for this board without too much effort.

    The nrf24l01 part is not recommended for new designs. The RADIO does not support 15.4 either. 

Related