Would MPSL automatically set some gpio pins to be used to control CTX and RTX pins of the SKY66112-11 FEM for TX/RX operations?

[Omid]

Hello my friends,

we have a custom board which includes an nRF52832 being chained to SKY66112-11 FEM.

Investigating the radio.c file in the radio-test example, I realized that we can configure the FEM in the application code, for example:

int fem_tx_configure(uint32_t ramp_up_time)
{
	int32_t err;

	fem_activate_event.event.timer.counter_period.end = ramp_up_time;

	err = mpsl_fem_pa_configuration_set(&fem_activate_event, &fem_deactivate_evt);
	if (err) {
		printk("PA configuration set failed (err %d)\n", err);
		return -EFAULT;
	}

	return 0;
}

However, for the FEM to work correctly, we need to set/clear CTX or RTX pins of the FEM via the nRF chip's GPIO pins that are connected to the FEM.

I am wondering how this control signal is generated automatically as we do NRF_RADIO->TXENABLE=1U or NRF_RADIO->RXENABLE=1U.

I already checked the radio.c fem_configure API and all I could conclude was that, it basically configure a timer. For instance, mpsl_fem_pa_configuration_set() API for the TX events.

However,  there is not a clear path to follow to understand how a radio event like TXENABLE=1 would translate into a GPIO pin high on a pin that can be connected to the FEM's CTX pin. Or how this timer configuration relates to the FEM control through the GPIO pins.

I am using MPSL for my proprietary communication protocol.

Does MPSL automatically set/clear some GPIO pins for every TX/RX radio events? If not, then how one can configure the FEM to be functional when using MPSL?
Is there any PPI channel that automatically sets some GPIO pins high and low for every TX/RX radio events? 
Is there a way to configure the MPSL to automatically send the control signal to FEM through specific GPIO pins and with appropriate timing?

[Kenneth]

Hello,

There is not automatic handling simply because you are using the radio no. I suggest that you look at the ESB source code on how it is configuring MPSL when enabling the radio, and for instance to transmit and receive data.

\v2.6.0\nrf\subsys\esb\esb.c
\v2.6.0\nrf\subsys\esb\esb_dppi.c

Kenneth

[Omid]

Hi Kenneth, it seems like I was not able to get my point accross. I am not asking for the ways I can use MPSL and radio (I already know how to do that). The entire question is about a front end module (FEM) being chained to the nRF chip and how that thing is actually controlled by the nRF chip during radio operation. I know for the fact that MPSL has FEM support, please see: [MPSL FEM]

[Kenneth]

1. This is configured in the devicetree, for instance for the nRF21540 it's found here:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/build/dts/api/bindings/net/wireless/nordic%2Cnrf21540-fem.html#properties 

tx-en-gpios	phandle-array	GPIO of the SOC controlling TX_EN pin of the nRF21540
rx-en-gpios	phandle-array	GPIO of the SOC controlling RX_EN pin of the nRF21540

2. The pins can only be controlled by MPSL (;MPSL will connect the provided events to control the pins through PPI->GPIOTE peripheral).

Kenneth

[Omid]

Thanks Keneth for the information.
I am using a device tree configuration as below for the FEM SKYWORKS (See nRF reference): 

	nrf_radio_fem: fem {
		compatible = "skyworks,sky66112-11", "generic-fem-two-ctrl-pins";
		ctx-gpios = <&gpio0 P_a GPIO_ACTIVE_HIGH>;
		crx-gpios = <&gpio0 P_b GPIO_ACTIVE_HIGH>;
		ant-sel-gpios = <&gpio0 P_c GPIO_ACTIVE_HIGH>;
		csd-gpios = <&gpio0 P_d GPIO_ACTIVE_HIGH>;
        cps-gpios = <&gpio0 P_e GPIO_ACTIVE_HIGH>;
        chl-gpios = <&gpio0 P_f GPIO_ACTIVE_HIGH>;
	};

where P_a, P_b, ... P_f are the FEM control pins.

I tried almost every thing, and the gpio pins assigned for the ctx-pin (P_a) never changes before, during, and/or after the TX operations. It is always a constant low.

Yesterday, I spend some time to analyze mpsl_fem_simple_gpios.c which seems to be the file responsible to configure and enable the FEM when we have CONFIG_MPSL_FEM_SIMPLE_GPIO in a project. 

I also tried to work with FEM on a BLE stack beacon example, and the ctx-pin works.

The thing that is confusing is why the GPIO pins do not function according to the TX/RX operations on my app which runs on MPSL and HAL.

Thanks.

[Kenneth]

Have you had a chance to (at least try) the ESB example, which should show how it enable and use MPSL to use the FEM? For anyone making their own radio implementation it should be the closest we have to an example of direct usage of the radio along with FEM through MPSL.

Kenneth

[Omid]

No I have not done that, but I could figure out that something affects the SOC's power (input to the FEM) when I add the fem in the device tree. I kind of feel like it might be related to the issues of ncs2.2 see: DRGN-18568 for ncs2.2 on here https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/releases_and_maturity/known_issues.html#softdevice-controller

[Kenneth]

I would expect that the output power from the nRF soc is reduced, since it will expect a FEM with a 10 - 20dB gain depending on configuration. Sounds to me the problem is that the expected events are not generated. Please check out how ESB use a timer to generate the events.

Kenneth

[Omid]

The problem with the SDK is that it lowers the SOCs power to an unpredictable level which I guess it is supposed to be equal to whatever is given to NRF_RADIO->TXPOWER.

The real issue arises when you want to have both the SOC and the FEM at their Max amplification. That can only happen if you set "tx-gain-db=<0>" at the device tree which does not make any sense from the high-level coding-style perspective. There are two issues: first, the gain simply means amplification not anything else, and when you set a gain to something, it should do amplification to the specified level. second: there are many FEM products that offer fixed gains, i.e., non adjustable gain, and requiring a gain of zero specification in the DT of the FEM for proper performance of the SOC does not make sense at all. (At least not to me!)

From your comment, it seems like an EGU is needed. So, any MPSL-based application which does not use EGU, won't trigger the GPIO pins for TX and RX enables, right? For example, my application which does not use any EGU and runs only on MPSL and HAL.

Having said that, with hard gpio_pin_set and totally removing the Device Tree configuration from our driver, I could get the +14 dBm output out of the FEM for my MPSL based application which is almost near the specification of the SKY FEM for VCC of 1.8 Volt considering 1.6dB cable loss. Also, for the BLE-stack the only way that FEM would amplify is to do: tx-gain-db=<x> where x is a small number, otherwise you will get a highly attenuated signal out of FEM which is due to SOC's lowered power.

I am looking forward to testing the SDK2.6 for this scenario.

[Kenneth]

Hello again,

I have read through your comments, and I do believe your understanding is correct. I would like to mention a bit why it is the way it is, please see:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/device_guides/working_with_fem.html 

You can find that we provide a power model for the nRF21540, which ensure that the set output power remain constant over the following conditions:

- Temperature
- FEM supply voltage
- Carrier frequency
- FEM input power

So doing it like you want it to be done is more intuitive correct, but that is in an ideal world. You are running into a risk that you may for instance exceed regulative requirements and/or you experience reduced performance if you don't have a power model such that we provide for the nRF21540. Hope that explains a bit why it is the way it is, and why this also impact other FEMs that may be used.

Kenneth

[Omid]

Thank Keneth,  I see your point.

just one more question, do you mean my conclusion on the necessity of the EGU in the MPSL application was also right?

[Kenneth]

Omid said:

just one more question, do you mean my conclusion on the necessity of the EGU in the MPSL application was also right?

Not necessarily, it should be possible to use a timer without EGU, where compare0 event trigger start task of radio, and compare1 event trigger the txen/rxen pin. Though, you might need to use MPSL_FEM_EVENT_TYPE_GENERIC instead of MPSL_FEM_EVENT_TYPE_TIMER in that case, since you will be controlling the timer in the application (not through MPSL).

Kenneth

[Omid]

I see, thanks, but what do you mean by using either of MPSL_FEM_EVENT_TYPE_GENERIC or MPSL_FEM_EVENT_TYPE_TIMER?

How one can use them?