CC1310 Rf external signalling mapping

Leonid A.

Hi,

in SWCU117F–February 2015–Revised June 2016 I found the following:

11.3.2.1 Control External LNA/PA (Range Extender) With I/Os
There are four logic RF-Core internal output signals called RF Core Data Out n, where n goes from 0 to 3.
These signals can be mapped to DIOs.

By default, RF Core Data Out 0 is set to go high when the LNA
must be enabled, and RF Core Data Out 1 is set high when the PA must be enabled.

Table 11-1
describes the signals. The signals can be mapped to any DIO by setting the relevant PORTID in the
designated IOCFGn register.

Table 11-1. RF Core Data Signals for PA and LNA

Port Name PORTID RF Core Signal Description
RFC_GPO0 0x2F RF Core Data Out 0 LNA enable
RFC_GPO1 0x30 RF Core Data Out 1 PA enable
RFC_GPO2 0x31 RF Core Data Out 2 TX start
RFC_GPO3 0x32 RF Core Data Out 3 Synth calibration running

23.3.2.8 External Signaling
The radio CPU controls the signals CPEGPO0 and CPEGPO1. For control of an external front end,
CPEGPO0 is high when the LNA must be enabled and low otherwise. CPEGPO1 is high when the PA
must be enabled and low otherwise. The radio CPU also controls the signal CPEGPO2 to go high when
synthesizer calibration starts, and low when the calibration is done. This control can be used for
debugging.
Two of the output signals from the radio timer have automatic configuration that may be used for
observation. The signal RATGPO0 goes high when transmission of a packet is initiated and low when
transmission is done. The RATGPO0 signal may be observed for accurate timing of packet transmission,
as the same signal is used internally. The signal is very similar to CPEGPO1, but it goes high some
microseconds earlier, and the timing is more accurate compared to the first transmitted symbol out of the
modem. However, CPEGPO1 is recommended for control of external PA to avoid turning it on too early.

By default, the radio CPU maps CPEGPO0 to the signal RFC_GPO0, CPEGPO1 to the signal
RFC_GPO1, CPEGPO2 to the signal RFC_GPO2, and RATGPO0 to the signal RFC_GPO3 at boot time.

But in Table 11-1.RFC_GPO3 was mapped to Synth calibration running signal.

Q: what is the default mapping of the RFC_GPO3 signal (RATGPO0 - Tx start or Synth calibration running (Table 11-1)?

Leonid

over 8 years ago

0 Richard W. over 8 years ago

TI__Genius 14860 points

Hi Leonid,

thank you for taking the time to report this one. Table 11-1 is wrong on these two signals while the information in section 23.3.2.8 is correct. This will be fixed in the next TRM revision.

RFC_GPO0	LNA enable
RFC_GPO1	PA enable
RFC_GPO2	Synth calibration running
RFC_GPO3	TX start

In order to route these signals to an IO pin, use the following line of code to set the IO multiplexer:

#include <ti/drivers/pin/PINCC26XX.h>

// Map RFC_GPO3 to IO 23
PINCC26XX_setMux(pinHandle, IOID_23, PINCC26XX_MUX_RFC_GPO3);

0 Leonid A. over 8 years ago in reply to Richard W.

Expert 1630 points

Hi Richard,

thanks for answer.

Is the following is right as well?

IOCPortConfigureSet(IOID_23, IOC_PORT_RFC_GPO3, IOC_STD_OUTPUT)

Leonid

0 Richard W. over 8 years ago in reply to Leonid A.

TI__Genius 14860 points

You can check that yourself by looking into TIRTOS_RTOS_DIR/products/tidrivers_XXX/packages/ti/drivers/pin/PINCC26XX.c. The implementation is:

PIN_Status PINCC26XX_setMux(PIN_Handle handle, PIN_Id pinId, int32_t nMux) {
    if (PIN_CHKEN && (pinId>=PIN_NumPins || PIN_HandleTable[pinId]!=handle)) {
        // Non-existing pin or pin is not allocated to this client
        return PIN_NO_ACCESS;
    }
    PINCC26XX_setIoCfgMux(pinId, nMux);
    return PIN_SUCCESS;
}

So yes, it's ok.

0 Leonid A. over 8 years ago in reply to Richard W.

Expert 1630 points

Here IOCPortConfigureSet() implementation from TIRTOS_RTOS_DIR6\products\cc26xxware_2_24_03_17272\driverlib:

void

IOCPortConfigureSet(uint32_t ui32IOId, uint32_t ui32PortId,

uint32_t ui32IOConfig)

{

uint32_t ui32Reg;

// Check the arguments.

ASSERT(ui32IOId <= IOID_31);

ASSERT(ui32PortId <= IOC_PORT_RFC_GPI1);

// Get the register address.

ui32Reg = IOC_BASE + ( ui32IOId << 2 );

// Configure the port.

HWREG(ui32Reg) = ui32IOConfig | ui32PortId;

}

and here

// Internal utility function for setting mux setting in IOCFG register for pin

static void PINCC26XX_setIoCfgMux(PIN_Id pinId, int32_t nMux) {

// Read in existing value in IOCFG register and update with supplied mux value

if (nMux<0) {

nMux = PINCC26XX_MUX_GPIO;

}

uint32_t dsCfg;

dsCfg = HWREG(IOC_BASE+IOC_O_IOCFG0+4*pinId);

dsCfg &= ~IOC_IOCFG0_PORT_ID_M;

dsCfg |= nMux & IOC_IOCFG0_PORT_ID_M;

HWREG(IOC_BASE+IOC_O_IOCFG0+4*pinId) = dsCfg;

}

0 Richard W. over 8 years ago in reply to Leonid A.

TI__Genius 14860 points

Sorry, my answer above was incomplete. I should have referred to PINCC26XX_setIoCfgMux().

In the DriverLib function, HWREG(ui32Reg) resolves to (IOC_BASE + ( ui32IOId << 2 )) which is equivalent to (IOC_BASE+IOC_O_IOCFG0+4*pinId) in PINCC26XX_setIoCfgMux(). The only difference is, that PINCC26XX_setIoCfgMux() leaves the existing IO port configuration (pull-up, etc) intact while IOCPortConfigureSet() overwrites it with a new configuration.

Sub-1 GHz

Sub-1 GHz forum

CC1310 Rf external signalling mapping