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. 

[Karl Ylvisaker]

Hello,

Thank you for elaborating on your test setup and observations.

AKV said:

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.

That's interesting. Is the peripheral not reporting a disconnection at all?
Which version of the nRF Connect SDK are you using, and which LE Audio controller version are you using?
I recall an issue with older controller versions (from over a year ago) where sometimes a disconnection event could be missing in a particular configuration. Could you try the same test again with the newest controller and SDK version?

AKV said:

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.

At first it did sound like drift, but if the timing and offset is consistent across multiple tests it weakens that hypothesis.

AKV said:

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?

It could be the missing disconnection event issue mentioned earlier, and so it will be very interesting if you could run the same test with the newest SDK and controller version.

AKV said:

Despite continuous packet transmission post-connection, why does disconnection still occur?

I am not sure that I understand your question here correctly, could you elaborate? - in the sniffer trace you shared earlier the peripheral device stopped responding to the central at all, which lead to the timeout disconnection.

AKV said:

Why does our custom board, functioning as a slave, experience quicker disconnection compared to its performance as a master?

This is a very interesting find, especially coupled with the tests you made with a synthesized LFCLK. This leads me to suspect an issue with the controller.

AKV said:

Private Ticket - Schematic Review Kindly examine the schematic to identify and assess any potential hardware issues. 

Great! Our lead hardware engineer is out of office this week, but I expect we'll get an answer to this early next week.
Fortunately, in the meantime we can follow up on the controller testing.


Best regards,
Karl

[AKV]

Thank you for your reply.

We're using the most recent SDK version 2.5.0. The disconnection problem is isolated to the custom board, as the DK functions correctly with the same code and SDK version.

Even after upgrading to version 2.5.2, the problem still persists.

Furthermore, After implementing the Network Core Monitor, We noticed that the network core triggers a reset event (NCM_EVT_NET_CORE_RESET) shortly after establishing a connection. Following the net core reset, disconnection occurs.

Then we read the RESETREAS register (Address offset: 0x400), the value is 0x01 in the DK (Development Kit) but 0x08 in our custom board.

After flashing in VS Code, the Development Kit (DK) resets itself using the "Applying pin reset" command, as I previously indicated. However, the custom board requires manually selecting the "reset board" option after programming. Could this be a configuration issue?

I have shared the .conf files for your evaluation. Could you please review them to identify any overlooked configurations?

[Karl Ylvisaker]

Hello,

AKV said:

Thank you for your reply.

No problem at all, I am happy to help! :) 

AKV said:

We're using the most recent SDK version 2.5.0. The disconnection problem is isolated to the custom board, as the DK functions correctly with the same code and SDK version.

Thank you for clarifying.

AKV said:

Then we read the RESETREAS register (Address offset: 0x400), the value is 0x01 in the DK (Development Kit) but 0x08 in our custom board.

This is interesting - value 0x01 indicates a PINRESET, while 0x08 indicates SREQ which is a soft reset from the application.

AKV said:

After flashing in VS Code, the Development Kit (DK) resets itself using the "Applying pin reset" command, as I previously indicated. However, the custom board requires manually selecting the "reset board" option after programming. Could this be a configuration issue?

If I have understood your previous comments correctly you are running the same application on the two boards, by just having a different build configuration for each of them, is this correct?

AKV said:

Even after upgrading to version 2.5.2, the problem still persists.

For good measure, could you share with me the full application log output when this issue occurs?
It would be good to also get the log from the same application running as expected on the DK, as a reference.

Best regards,
Karl