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]

I think the ESB files I point to show what you want to know, because the ESB source code show how to use the radio along with MPSL to use the FEM. The MPSL don't expose directly the pins that control the fem, instead you configure MPSL with the events that it should use in turn to control the TX/RX pins, then MPSL will ensure the RX/TX pins to the FEM toggle as expected based on the events provided. 

Looking at the implemention of ESB I can find that both mpsl_fem_pa_configuration_set() and mpsl_fem_lna_configuration_set() is never enabled at the same time. The ESB don't call TXENABLE or RXENABLE when it want to start the radio, instead it will setup ppi channels from the EGU to the start radio task and a start timer task. When ESB want to transmit or receive it will instead trigger an EGU event by calling radio_start(), see implementation here:

static void radio_start(void)
{
	/* Event generator unit is used to start radio and protocol timer if needed. */
	nrf_egu_task_trigger(ESB_EGU, ESB_EGU_TASK);
}

So the radio will startup (this takes for instance 150us if it's BLE or 130us if its proprietary) before radio is actively transmitting or receiving, the MPSL will use the timer compare event to set the RX/TX pin after for instance TX_RAMP_UP_TIME_US (129us).

So you are right, ESB is using for instance a timer compare event to time when the RX/TX pins are set.

Hope it helps,
Kenneth

[Omid]

Hi Keneth, thanks for further clarification, however, I still have a few more questions in mind:

1. what GPIO pins exactly are used by MPSL? Where can I find the GPIO pin assignment?

2. I realized if I use my proprietary application which uses MPSL and HAL for wireless communication, when I try to write on pin 26, it never does that and that pin is constantly zero regardless of the hardcoded gpio pin set. I am wondering why this is happening.

[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