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,

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