nRF5340 using Skyworks FEM interface

[AKV]

Hi,

I need to integrate the Skyworks RFX2401 FEM module into my custom nRF5340 based project.

The following code snippet has been included in the custom_nRF5340_cpunet.dts file.

nrf_radio_fem: rfx_2401_fem {
		compatible = "skyworks,sky66112-11", "generic-fem-two-ctrl-pins";
		ctx-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
		crx-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
		tx-gain-db = < 22 >;
		rx-gain-db = < 11 >;
};


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

Added gpio_fwd in the custom_nRF5340_common.dts file

gpio_fwd: nrf-gpio-forwarder {
		compatible = "nordic,nrf-gpio-forwarder";
		status = "okay";

		fem { // don't forward CPS/CHL pins, it's manually done by the application
            gpios = <&gpio1 10 0>, // CTX / P1.10
            <&gpio1 13 0>; // CRX / P1.13
        };
	};

Enable the given below config macros in thein the hci_rpms\prj.conf

CONFIG_MPSL_FEM=y
CONFIG_MPSL_FEM_SIMPLE_GPIO=y

FEM functionality seems to be non-functional after the following modifications.

Even after activating the configuration macros (CONFIG_MPSL_FEM=y, CONFIG_MPSL_FEM_SIMPLE_GPIO=y), they still display as 'n'. They are not visible in both the build\zephyr.config and build\hci_rpmsg\zephyr.config files.

Is there a requirement to include additional macros or incorporate specific code sections to enable FEM?

[Karl Ylvisaker]

Hello,

I need to integrate the Skyworks RFX2401 FEM module into my custom nRF5340 based project.

Please see the Working With FEM documentation page for information on how to add a FEM to your project.

FEM functionality seems to be non-functional after the following modifications.

How do you measure this - are you scoping the FEM assigned pins, or are you checking the RSSI on a peer device?

Even after activating the configuration macros (CONFIG_MPSL_FEM=y, CONFIG_MPSL_FEM_SIMPLE_GPIO=y), they still display as 'n'. They are not visible in both the build\zephyr.config and build\hci_rpmsg\zephyr.config files.

Is there a requirement to include additional macros or incorporate specific code sections to enable FEM?

From this it sounds like the issue is a problem with the configuration somewhere.
Could you share the .conf file from your build/zephyr location, so that we may see all the configurations that are set (or not) in your project?

Best regards,
Karl

[AKV]

Hi,

Thanks for the response.

I have duplicated the DK board files and assigned new names for a custom board purpose. The objective is to establish a connection between the devices. Once the FEM is activated, the system can successfully scan through the NRF Connect app.

Karl Ylvisaker said:

How do you measure this - are you scoping the FEM assigned pins, or are you checking the RSSI on a peer device?

I am monitoring the RSSI through the nRF Connect App.

#CONFIG_MPSL_FEM=y
#CONFIG_MPSL_FEM_SIMPLE_GPIO=y
CONFIG_BT_CTLR_TX_PWR_ANTENNA=20

1 .After added the the CONFIG_BT_CTLR_TX_PWR_ANTENNA=20 macro, the RSSI now displays satisfactory values. Furthermore, modifying the power level within this specific macro leads to fluctuations in RSSI. There is no difference in the RSSI if removed the macros CONFIG_MPSL_FEM=y and CONFIG_MPSL_FEM_SIMPLE_GPIO=y.

 Is it correct to say that the FEM only operates when this macro (CONFIG_BT_CTLR_TX_PWR_ANTENNA) is in use?

2. I've noticed that following the connection, the device is disconnected due to reason 8 within a few seconds.

This disconnection problem specifically occurs on our custom board and does not happen with the nRF5340 DK.

Could there be any missing custom board configurations? I have shared the sniffer and .conf files for your review. Can you please examine them to see if any configurations are overlooked?

3. The custom board fails to reset automatically following flashing in VS Code. I find it necessary to manually choose the "reset board" option after programming. And the same code triggers an automatic reset when used with the DK. What could be causing this issue?

/cfs-file/__key/communityserver-discussions-components-files/4/8233_2E00_config

/cfs-file/__key/communityserver-discussions-components-files/4/devicedisconnects.pcapng

[AKV]

Karl Ylvisaker 

I have revised the information using the most recent data available. Could you kindly provide your response?

[Karl Ylvisaker]

Hello again,

Thank you for your patience with this.

AKV said:

Thanks for the response.

No problem at all, we are happy to help! :)

AKV said:

After added the the CONFIG_BT_CTLR_TX_PWR_ANTENNA=20 macro, the RSSI now displays satisfactory values.

I am glad to read that you are now seeing the correct output power!
Just to make sure, you are in your measurements seeing a ~20 dBm gain when you switch on the FEM, compared to when you have not set the output power to 20?

AKV said:

 Is it correct to say that the FEM only operates when this macro (CONFIG_BT_CTLR_TX_PWR_ANTENNA) is in use?

No, that is not quite correct - the FEM is still activated so long as you do not unassign the pins, and so if you for instance were to set the output to +0 dBm the nRF53 would output -10 dBm, and the FEM would output +10 dBM (its lowest mode).
The nRF21540 does not have a bypass mode directly, but you could perhaps unassign its TXEN and RXEN pins to reduce power consumption, if that is what you are after.

AKV said:

2. I've noticed that following the connection, the device is disconnected due to reason 8 within a few seconds.

This disconnection problem specifically occurs on our custom board and does not happen with the nRF5340 DK.

Could there be any missing custom board configurations? I have shared the sniffer and .conf files for your review. Can you please examine them to see if any configurations are overlooked?

Hmm, this could indicate a radio hardware issue with your custom board - thank you for including the sniffer trace immediately, so that I may take a look.
Have you had us perform a schematic review on your nRF5340 related circuitry? If not, please do not hesitate to open a new private ticket with this request so that our hardware engineers can perform the review in parallel to our work in this ticket.
Please provide the schematic files and the gerber files for them to review.

Taking a look at the provided sniffer trace I notice that the peripheral stops replying to the central device at packet #2056, #2535, and #3583, and there seems to be nothing wrong with the link up until then. This could indicate a drift in the peripheral's LFCLK so that it does not wake up at the right time, causing it to fall out of synch with the central device.
What clock source are you using for your LFCLK?

AKV said:

3. The custom board fails to reset automatically following flashing in VS Code. I find it necessary to manually choose the "reset board" option after programming. And the same code triggers an automatic reset when used with the DK. What could be causing this issue?

Are you here referring to the disconnection issue?
If so, are you resetting your peripheral board during sniffer capture you performed?
Perhaps I am not understanding you correctly.

Best regards,
Karl

[AKV]

Thanks for the response.

Here are some observations:

We conducted experiments using one nRF5340 DK and our custom board, connecting them to each other and sending packets with a 20 ms delay immediately after establishing the connection.

Our findings indicate that when our device functions as the master to the DK, the connection remains stable for 10 to 20 minutes before experiencing disconnection. Conversely, when our device operates as the slave, it disconnects immediately after sending a few packets. Notably, upon disconnection, our device does not register a disconnection event, whereas the DK reports a disconnection event with reason 8.

We have experimented with both the synth and RC options (CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y and CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y with CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y), but in both scenarios, the behavior remains consistent.

We attempted to address this issue by setting CONFIG_SOC_HFXO_CAP_INTERNAL=y (Removed external cap from our custom board) and writing the value 0x103 to the register NRF_OSCILLATORS->XOSC32MCAPS, derived from calculations based on reading the register NRF_FICR->XOSC32MTRIM, yielding the value FFFFFDBE and we need to set 8 pF.

Addressing your specific queries:

1. What could be the reason for the disconnection event not being reported on our custom board? Is this possibly related to a netcore hang issue?
2. Despite continuous packet transmission post-connection, why does disconnection still occur?
3. Why does our custom board, functioning as a slave, experience quicker disconnection compared to its performance as a master?
4. I have shared the .conf files for your evaluation. Could you please review them to identify any overlooked configurations?
5. Private Ticket - Schematic Review Kindly examine the schematic to identify and assess any potential hardware issues.