• State Not Answered
  • Replies 35 replies
  • Subscribers 72 subscribers
  • Views 1698 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 333052
Options

How to add Skyworks fem to nrf5340 audio

LandyWang

Hello,

I am using nrf5340 audio sample with the custom board. The nRF Connect SDK version I used is v2.7.0.

I referred to this post and tried to add skyworks fem to my nrf5340 audio application.

The following is the part I modified:

nrf5340_audio_dk_nrf5340_cpunet.overlay

/ {
    nrf_radio_fem: pa_lna {
        compatible = "skyworks,sky66112-11", "generic-fem-two-ctrl-pins";
        ctx-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
        ctx-settle-time-us = < 23 >;
        crx-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
        crx-settle-time-us = < 5 >;
        cps-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
        tx-gain-db = < 13 >;
        rx-gain-db = < 14 >;
    };
};
&radio {
	fem = <&nrf_radio_fem>;
};

nrf5340_audio_dk_nrf5340_cpuapp.overlay

/ {
    nrf_radio_fem: pa_lna {
        compatible = "skyworks,sky66112-11", "generic-fem-two-ctrl-pins";
        ctx-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
        ctx-settle-time-us = < 23 >;
        crx-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
        crx-settle-time-us = < 5 >;
        cps-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
        tx-gain-db = < 13 >;
        rx-gain-db = < 14 >;
    };
};

prj.conf

CONFIG_MPSL=y
CONFIG_MPSL_FEM_ONLY=y
CONFIG_MPSL_FEM_SIMPLE_GPIO=y

But it doesn't seem to work.

Is there any way to add skyworks fem to nrf5340 audio application?

Parents
  • 0

    Hello again, and once again sorry about the wait. Please contact your local RSM if the help you are getting here isn't prompt enough. And let me know if you need his contact info.

    LandyWang said:

    But I don’t quite understand with the step 4 of the document. Does it mean creating a child image/hci_ipc.overlay file to the nrf5340 audio application? But in NCS v2.7.0, the child image has been replaced by sys build. What should I do to apply the devicetree node to the network core?

    Hmm yeah that part is a bit confusing, though it is explaining how one would do it with the legacy/non-sysbuild way. In the old system you would just add a dts overlay file to a childimage folder, like you mentioned. You can build it without sysbuild if you prefer, using "--no-sysbuild" or the 'No sysbuild' checkbox when making a build configuration in VSC:

     

    In order to build it with sysbuild, you essentially do the same thing but call the folder sysbuild. 

    LandyWang said:

    I tried adding hci_ipc.overlay in sysbuild/ipc_radio, but it seems that fem has no effect.

    Could you make sure that the hci_ipc.overlay have any effect there, by for instance adding some jibberish to the overlay and check if it still builds.

    I think you should either place a file called nrf5340dk_nrf5340_cpunet.overlay in sysbuild/hci_ipc/, or in child_image/hci_ipc/, but there are different ways of doing this in sysbuild and it is a bit confusing to me too.

    Regards,

    Elfving

  • 0 in reply to Elfving

    Thank you for your reply.

    I tried adding jibberish to the overlay and check if it still builds to ensure that the hci_ipc.overlay have effect.

    Whether hci_ipc.overlay is placed in sysbuild/hci_ipc/ or child_image/hci_ipc/, it seems to have no effect. The same goes for changing the file name to nrf5340dk_nrf5340_cpunet.overlay.

    Selecting the 'No sysbuild' checkbox when making a build configuration in VSC has the same result.

    It looks like I can't apply the devicetree node to the network core.

  • 0 in reply to LandyWang

    Hi,

    There are two issues to reading from that registers, and none of them are related to TF-M. While it seems so from the error message related to the SPU, this is just because the SPU is in general responsible for blocking any disallowed access.

    Issue 1: The ticket you got the command for is to read TXPOWER from the nRF52840. The nRF5340 has TXPOWER in another register. Specifically RADIO (0x41008000) -> TXPOWER (0x50C) = 0x4100850C

    Issue 2: In the nRF5340, the TXPOWER register lives in the network core and not in the application core. nrfjprog tries to read from the application core by default. If we use "nrfjprog --help", we can see:

    Try this instead:

    nrfjprog --memrd 0x4100850C --coprocessor CP_NETWORK

  • 0 in reply to Sigurd Hellesvik

    Thank you for your assistance. It works.

    Now I can use this method to check if the TX power has improved.

    I will test the above method of enabling Skyworks FEM and will post the results of the test later. If TX power doesn't improve, I will continue to ask for help in this ticket.

  • 0 in reply to Sigurd Hellesvik

    After I set CONFIG_BT_CTLR_TX_PWR_ANTENNA to 16, the TX power read by nrfjprog changed from 0xF0 to 0x0.

    After actual testing, the connection distance has also been lengthened. But the distance is still not as long as what I tested on v2.2.0.

    I found during testing that removing the settings in the overlay, which is where the specified part is added, does not affect the TX power read by nrfjprog.

    Does this mean I still not enable skyworks front-end on nrf5340 audio?

    How can I enable skyworks fem on nrf5340 audio in v2.7.0?

  • 0 in reply to LandyWang

    Hi,

    Using a skyworks FEM for this should still be possible.

    So if I understand you correctly, you can confirm that the FEM is increasing the antenna power, but you've tried this earlier in NCS 2.2, and you got an even better result there. Was this previous result with the same nRF, hw, antenna power config, and value set in the tx power register?

  • 0 in reply to Elfving

    Yes, I use the same nRF, hw, antenna power config, and confirmed that the value set in the tx power register is also 0dbm in NCS 2.2.0.

    I got better results in NCS 2.2.0.

Reply Children
Related
Terms of service