Enable FEM by GPIO to PDN pin

[Hiihtaja]

Hello !

Enable of it to RX or TX mode from PD can take ( 10 + 17us) some time. It mean I should set PD line to High beforehand.

But it have sense to keep FEM in Powerdown mode as long as possible due high power consumption.

Now I configure and wakeup FEM some time beforehand ( 200-300 us) due my radio internal states. And FEM works fine.

I have event from Timer for wake up RADIO ( it take 40-50 us). I just think if it possible to attach to this event 3 GPIO lines and start to wakeup FEM to RX or TX mode at the same time when radio starts to wakeup ?

Or may be I will set all other lines beforehand and attach to RADIO->TASK_STARTS only control to PDN line.

I think it should be examples somewhere how to  set PDN high when TASK_START is initiated. I mean without interrupts and exact sw.

By using PPI and GPIOTE.

But I can't see ant RADIO event WAKEUP START for be able to attach to it.

Or how to bind radio TASK STARTS and toggling GPIO line to high ?

Regards,

Eugene

[ovrebekk]

Hi Eugene

Which RF protocol are you using, and which SDK version are you using for code development? 

Many of our RF protocol stacks will control the FEM automatically, as long as you enable it in the project configuration. 

If you are doing something proprietary then you should look for whatever event is starting the radio in the first place. 
There is no event generated when the radio rampup starts, but the rampup only starts when something in the application triggers the TXEN or RXEN tasks in the radio. Possibly you can use a PPI channel to fork this event both to the radio and to the GPIOTE peripheral, in order to enable the PD pin whenever the radio goes into the rampup phase. 

Best regards
Torbjørn

[Hiihtaja]

Hi Torbjørn !

Looks like in my proprietary radio I can attach NPDN pin control to the same timer what initiate RADIO STARTRX/TX operations. Radio wakeup time is quite similar and when RADIO is READY, FEM is ready as well.

But due this anomaly :

/*

* This anomaly applies to IC Rev. Revision 2, build codes QDAA-G00.

* [13] System: Increased supply current in Power-down state with digital input pins at high level

* The supply current may increase up to 500 µA per pin set high.

* Pull the CSN, RX_EN, TX_EN, MODE, SCK, MOSI, and ANT_SEL pins low in Power-down state.

* Pull the CSN pin high together with the PDN pin when changing to Program state.

*/

I should set to high level more pins at the same time as PD, because they might need to be set to High level beforehand.

And extra power consumption kill whole idea of power optimization.

It cause multiple GPIOTE/PPI line reservations. Looks like each GPIO line need individual GPIOTE channel.

Is this so ?

Do you have plan to fix this anomaly at some IC revision ?

Regards,

Eugene

[ovrebekk]

Hi Eugene

Hiihtaja said:

Looks like each GPIO line need individual GPIOTE channel.

Is this so ?

That is correct, each GPIOTE channel can only control a single pin. 

In order to set both PDN and MODE low on an even you need to use two GPIOTE channels, and possibly an additional PPI channel to connect one event to both the GPIOTE tasks (unless you don't need the FORK channel for something else, in this case you can connect the same event to two tasks without using two PPI channels). 

Hiihtaja said:

Do you have plan to fix this anomaly at some IC revision ?

I can check with the team, but since an effective workaround exists I don't think fixing this errata is a big priority. Revising the hardware is a big undertaking, and we will typically only do this for issues where no good workaround exists. 

Best regards
Torbjørn

[ovrebekk]

Hi Eugene

The developers confirmed that there is no plan to fix the anomaly in this chip. 

The bug will still be registered internally, in order to avoid it in future products. 

Best regards
Torbjørn