Migrating from CC1101


Welcome to the CC1101 migration guide. This guide is written for users that use CC1101 today and want to migrate over to CC13x2. This guide consists of 4 main parts:

  • “How do I get a link between CC1101 and CC13x2?”
  • “Where are my registers?”: A short introduction to software on CC13x2
  • “How do I make CC13x2 do anything”: Drivers and software
  • “I use feature <> on CC1101, how do I do it on CC13x2?”

This document refers to the following material:

“Where are my registers?”

CC1101 is a transceiver meaning that to make an application CC1101 has to be used together with an MCU. This MCU communicates with CC1101 over an SPI interface and hardware registers on CC1101 has to be written or strobe commands have to be sent to make the radio do anything.

CC13x2 is a wireless MCU. This mean that CC13x2 is a powerful MCU with a selection of peripheral modules where one of these is the RF core. CC13x2 still has registers but most of them are hidden from users. One of the reasons for this is that the meaning of a register on CC13x2 changes dependent on which firmware that is running. Instead the communication with the different modules on CC13x2 is done via APIs and overrides. All the available modules on CC13x2 have a driver. The APIs for the drivers are described in the documentation.

In addition all drivers are documented in the header files. The header files also contain examples of usage. The driver header files are found in TI Driver Source Files. Some drivers also have examples included in the SDK.

An override is a register write. Most of the overrides are provided by TI and should not be changed. These are typically registers setting up one or more internal modules and are the result of a lot of testing. The registers users can change freely are typically documented here. Required overrides are given by SmartRF Studio.

“How Do I Make CC13x2 Do Anything?”: Drivers and Software

To control CC1101 you can use anything from a simple 8 bits MCU to a multi core Arm processor, all depending on the complexity of your application. CC13x2 is a wireless MCU with more than one core hence programming CC13x2 is different from using a simple 8 bit controller. CC13x2 has a number of internal voltage and clock domains. To use (as an example) the RF core the clocks used by the RF core have to be turned on and the voltage domain the RF core is powered from has to be turned on. When the RF core is not in use the clocks and the voltage domain should be turned off to save power. The power on and off needs to be done in a given sequence to ensure that everything is in the correct state.

To simplify the use of CC13x2 drivers are available. The driver sets up the clock and power domains and offer an API. The driver documentation can be found here:

The drivers are written in c and it is therefore possible to walk through the code to get a better understanding of what a given driver does if this is wanted and/ or required. In addition, this document describes the power driver requirements: Power Management Software Development Reference.

Both the TI-RTOS and the NoRTOS solution go to the IDLE state whenever possible. In IDLE state the Power_idleFunc() is called which takes the chip to the lowest power state possible.

For a comprehensive TI-RTOS course, see the TI RTOS Workshop Series.

The NoRTOS solution is documented here: NoRTOS Driver Porting Layer.

EasyLink is a simple abstraction on top of the CC13x2 drivers which can be used as a starting point for simple RF protocols. Examples are available in the SDK.

For CC13x2 a Software Development Kit (SDK) is provided.

The Customer Configuration (CCFG)

CC13x2 has a part of flash called Customer Configuration (CCFG). The CCFG parameters are set at compile time in the ccfg.c file in the SDK. The ccfg.c file contains settings for (not a complete list):

  • CCFG_FORCE_VDDR_HH: Sets it 12.5 dBm or 14 dBm is maximum output power.
  • SET_CCFG_MODE_CONF_DCDC_ACTIVE: Sets if the DCDC should be used in active or not.
  • SET_CCFG_MODE_CONF_SCLK_LF_OPTION: Sets the source for the low frequency clock.
  • SET_CCFG_MODE_CONF_XOSC_CAP_MOD: Sets if the internal crystal load capacitor array should be used. The default is that the internal array is in use.
  • SET_CCFG_EXT_LF_CLK_DIO: The DIO used if using an external clock source for the LF
  • SET_CCFG_BL_CONFIG_BL<>: Settings for the boot loader.

“I Use Feature <> on CC1101, How Do I Do it on CC13x2?”

This part of the migration guide aims to describe how CC1101 features map to the CC13x2. The numbering of the sections follows the CC1101 datasheet. If you wonder how to implement a given thing on CC13x2, find which section in the CC1101 datasheet this is covered and look up the section number in the guide.

4 Electrical Specifications

4.1 Current Consumption

The CC13x2 current consumption numbers are summarized in 5.4 and 6.7 in the CC13X2R1 Datasheet.

State CC1101 CC1310 CC1312
Tx (10 dBm) 30.0 mA 13.4 mA 14 mA
Rx 14.7 mA 5.5 mA 5.7 mA
Sleep 0.2 uA 0.185 uA 0.13 uA

4.2 Receive Section

The CC13x2 receive parameters are stated in 5.6 and 5.7 in the CC13X2R1 Datasheet.

4.3 RF Transmit Section

The CC13x2 transmit parameters are stated in 5.8 and 5.9 in the CC13X2R1 Datasheet.

4.4 Crystal Oscillator

CC13x2 has 2 crystal oscillators, 24 MHz and 32.768 kHz. The internal 32.768 kHz RC oscillator can be used instead of the 32.768 crystal. This is done in the ccfg.c file.

4.5 Low Power RC Oscillator

The CC13x2 32 kHz RC oscillator is covered in in the CC13X2R1 Datasheet.

4.6 Frequency Synthesizer Characteristics

The CC13x2 PLL parameters are covered in 5.10 in the CC13X2R1 Datasheet.

4.7 Analog Temperature Sensor

The CC13x2 has a build in temperature sensor and battery monitor. An API is provided, see AONBATMON.

Section 18 in the CC13x2 Technical Reference Manual describes how the module is implemented on CC13x2.

4.8 DC Characteristics

The CC13x2 DC characteristics are covered in 5.17 in the CC13X2R1 Datasheet.

4.9 Power-On Reset

CC13x2 has built in power supply supervision that ensures that the chip first starts when the supply voltage to the chip has a valid level. When the voltage drops below a given voltage the voltage supply supervision module take the chip down in a controlled reset to ensure that the chip does not enter an undefined state.

In the ccfg.c file it’s possible to set the reset level to 1.78 V (1.65 V if external regulator mode is used) or 2.0 V, see SET_CCFG_MODE_CONF_VDDS_BOD_LEVEL in The Customer Configuration (CCFG).

5 Pin Configuration

See section 4 in the CC13X2R1 Datasheet to find the CC13x2 pin configurations.


CC1310 comes in 3 different packet sizes (4x4, 5x5 and 7x7) where the main difference between the packet sizes is the number of available IOs.

6 Circuit Description

See the CC13X2R1 Datasheet and section 1 in the CC13x2 Technical Reference Manual.

7 Application Circuit

This section will not cover the CC13x2 application circuit but some of the differences between CC1101 and CC13x2. For CC13x2 application circuits see under Design files in Technical Documents.

7.1 Bias Resistor

CC13x2 doesn’t use an external bias resistor

7.2 Balun and RF Matching

Similar to CC1101, CC13x2 has differential RF pins, RF_P and RF_N. In addition the RXTX pin may be used. The LNA can be biased internally or externally. If the latter is the case the RXTX pin is used. In addition, the RF_P and RF_N pins are possible to use single ended. Possible use cases are two single ended paths on two different frequencies or one path for TX and one for RX. The latter could typically be the case when using a front-end module (FEM).

For 868 MHz, it is also possible to use an integrated passive component (IPC) instead of discrete components.

7.3 Crystal

CC13x2 has a build-in capacitor array used as load capacitors for the crystal. The built in is possible to adjust, see Crystal Tuning.

7.4 Reference Signal

CC13x2 can only be used with a crystal. TCXO or an external reference signal is not supported.

7.5 Additional Filtering

Not applicable for CC13x2. Please follow the reference design under Technical Documents.

7.6 Power Supply Decoupling

It is important that the power decoupling is done as in the reference design. In addition the network connected to the DCDC_SW pin should be done as close as possible to the reference design if the DCDC converter is used. Pay close attention to the grounding and to have a short as possible return path from the decoupling to the die paddle.

7.7 Antenna Considerations

Please take a look the CC-Antenna-DK2 and Antenna Measurements Summary for the latest recommended PCB antennas.

7.8 PCB Layout Recommendations

The layout considerations for CC1101 are also valid for CC13x2. See the CC13X2R1 Datasheet, the reference designs and your manufacturer on solder paste coverage. See the CC13x2 reference designs for the number of vias under the chip.

8 Configuration Overview

CC1101 is a transceiver where the transitions between the different states are controlled by a hardware module.

CC13x2 is a wireless module where the radio is one of the peripherals. The states on CC1101 can therefore not be compared directly. 6.7 in the CC13X2R1 Datasheet describe the main power modes.

The RF driver controls which state the RF core is in.

9 Configuration Software

It’s highly recommended to use the code export feature in SmartRF Studio to get the recommended settings.

For details, press help in SmartRF Studio and scroll down to “Command Code Export” in the contents pan.

10 4-wire Serial Configuration and Data Interface

CC1101 is programmed and controlled over a SPI interface. This section of the CC1101 datasheet covers how to use the SPI interface. The CC13x2 is a wireless MCU and therefore is not directly controlled over an interface. Programming the CC13x2 is done over the JTAG interface using XDS100V3, XDS110 or XDS200. The CC1352R1 Launchpad has a built-in XDS110 that can be used to program the CC13x2 on the Launchpad or on a custom board using either Flash Programmer 2 or Uniflash.

11 General Control and Status Pins

The pins described in this section of the CC1101 datasheet are related to the SPI interface controlling CC1101. Since CC13x2 is controlled differently than CC1101, CC13x2 doesn’t have the pin control described in this section of the CC1101 datasheet.

12 Data Rate Programming

On CC1101 the wanted data rate is set by writing to the MDMCFG3.DRATE_M and MDMCFG4.DRATE_E registers. On CC13x2 the data rate is set via the CMD_PROP_RADIO_DIV_SETUP command. See 23-139 in CC13x2 Technical Reference Manual for details. It is recommended to use SmartRF Studio to calculate the required values and export the code. SmartRF Studio also contains a set of characterized settings for data rates used in CC1101 systems. See also settings for different PHYs.

13 Receiver Channel Filter Bandwidth

Receiver bandwidth is set via the CMD_PROP_RADIO_DIV_SETUP command.


On CC1310 the RX BW can’t be set independently of the data rate, please see CC13xx Data rate vs RxBw for more details.

14 Demodulator, Symbol Synchronizer and Data Decision

14.1 Frequency Offset Compensation

When using (G)FSK and data rates under 500 kbps the frequency offset estimate is available as DEMMAFC0[7:0] / 64 * f_dev; f_dev is the programmed deviation and has unit Hz.

DEMMAFC0[7:0] is on address 0x4004 5154 and should be read after a packet is received. The result is a signed value.:

 //frequency_dev is the deviation given in Hz.
 static int16_t offset  = 0;

 rfc_CMD_READ_RFREG_t RF_cmdReadRfregFreqOffset =
    .commandNo  = 0x0601,
    .address = 0x5154,
    .value = 0,

RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdReadRfregFreqOffset);

offset = (RF_cmdReadRfregFreqOffset.value) * frequency_dev/ 64;

14.2 Bit Synchronization

From a user standpoint this is done in the same way on CC1101 and CC13x2.

14.3 Byte Synchronization

From a user standpoint this is done in the same way on CC1101 and CC13x2.

15 Packet Handling Hardware Support

15.1 Data Whitening

CC13x2 can be set up to use the same whitening as CC1101 by setting CMD_PROP_RADIO_DIV_SETUP.whitenMode = 0x1.

15.2 Packet Format

The CC13x2 standard packet format shown in figure 23-9 in CC13x2 Technical Reference Manual is the same packet format as used on CC1101, but the packet format on CC13x2 is made more flexible.

  • The length of the preamble is possible to set in CMD_PROP_RADIO_DIV_SETUP.nPreamBytes with the possibility to set the length of the preamble to most values between 1 and 32 byte in addition to 1 and 4 bit. See table 23-139 for details. On CC13x2 it’s possible to use other preambles than 0xAA or 0x55.

    The preamble can be set using Overrides:

    //Preamble: 0x33
    (uint32_t) 0x33330043
    //Preamble: 0xCC
    (uint32_t) 0xCCCC0043
  • The length of the sync word is possible to set in CMD_PROP_RADIO_DIV_SETUP.nSwBits with the possibility to set number of bits from 8 to 32.

Note that the CC1101 sync search is purely bit based (the bits in the received data stream are compared one by one with the programmed sync word). CC13x2 on the other hand uses a combination of correlator based sync search and a bit based search (strict sync search). A correlator based sync search compares patterns and does not limit sensitivity. This difference in how the CC1101 and CC13x2 search for sync means that it’s not possible to accept 1 bit error per 16 bits on CC13x2 as on CC1101 (MDMCFG2.SYNCMODE). Since the sync search on CC13x2 doesn’t limit sensitivity there is no need for a 15/16 or 30/32 sync mode setting on CC13x2.

Note that by using CMD_PROP_RX_ADV it is possible to search for two different sync words at the same time.

  • CMD_PROP_RX supports up to 255 bytes payload, CMD_PROP_RX_ADV supports unlimited length (CMD_PROP_RX_ADV.maxPktLen = 0).
  • Fixed or variable packet length is set in CMD_PROP_TX.bVarLen. When using variable packet length mode on CC1101, the length byte must be written to the TX FIFO. On the CC13x2, the length byte is not part of the packet but is set through the API (CMD_PROP_TX.pktLen).

15.3 Packet Filtering in Receive Mode

Address filtering can be enabled by setting CMD_PROP_RX.bChkAddress. The received address is compared against CMD_PROP_RX.address0 and CMD_PROP_RX.address1. CRC filtering can be enabled by setting CMD_PROP_RX.bUseCrc.

16 Modulation Formats

As of today CC13x2 supports 2-(G)FSK and OOK. Contact TI if you need a different format.

17.1 Sync Word Qualifier

The sync word is selectable to have a length from 8 bits to 32 bits. This is set in CMD_PROP_RADIO_DIV_SETUP.nSwBits. The sync word threshold could be set with the following override:


where YY and ZZ is the threshold for the two correlators. For simplicity the two thresholds can be set equal. Higher value is stricter. The default sync threshold is given by:

Sync Threshold = (30*nSwBits)/32 + 9

If the received sync word has to be bit by bit equal to the programmed sync word, the word search is qualified as a strict sync word search.

17.2 Preamble Quality Threshold (PQT)

The CMD_PROP_CS command can be used to monitor the RF activity in a channel and return busy if a preamble is present.

If PQT gating of sync search is wanted CMD_PROP_RX_SNIFF has to be chained (Conditional execution and chaining) with CMD_PROP_RX.

17.3 RSSI

If in Rx, the function RF_getRssi() returns the RSSI value. After receiving a packet the radio will no longer be in RX mode unless bRepeatOk = 1. The RSSI of a received packet can be read from the rfc_propRxOutput_t structure.

In the code, add:

static rfc_propRxOutput_t rxStatistics;
int8_t RSSIout;

// Under Modify CMD_PROP_RX command for application needs
RF_cmdPropRx.pOutput = (uint8_t*)&rxStatistics;

// Where you want to read out the RSSI in the code
RSSIout = rxStatistics.lastRssi;

17.4 Carrier Sense (CS)

The CMD_PROP_CS command can be used to monitor the RF activity in a channel and return busy if the RSSI is above a given threshold.

17.5 Clear Channel Assessment (CCA)

The rfListenBeforeTalk example in the SimpleLink CC13x2 SDK shows how listen before talk (LBT) or CCA can be implemented.

18.1 Forward Error Correction (FEC)

To enable the CC1101 compatible FEC:

  1. Export GEN-FSK settings from SmartRF Studio.

  2. In the smartrf_settings.c file, add the rf_patch_mce_genfsk_fec_cc1101 MCE patch to RF_prop:

    #include <ti/devices/DEVICE/rf_patches/rf_patch_mce_genfsk_fec_cc1101.h>
    RF_Mode RF_prop =
        .rfMode = RF_MODE_PROPRIETARY_SUB_1,
        .cpePatchFxn = &rf_patch_cpe_genfsk,
        .mcePatchFxn = &rf_patch_mce_genfsk_fec_cc1101,
        .rfePatchFxn = &rf_patch_rfe_genfsk,
  3. In the override list set the MCE to run from RAM:

  4. In the override list, add the following line to set stricter sync word threshold. The FEC patch does not do bit-wise sync word check.:


19.1 Power-On Start-Up Sequence

The CC13x2 has a build in POR/ brown out detector (BOD) that ensures that the chip does not boot up before VDDS is above the set minimum voltage (see 4.9 Power-On Reset). The chip also has an external reset pin. Follow the reference design for an external circuit that ensures a pin reset at power-up.

19.2 Crystal Control

The 24 MHz XOSC is controlled by the drivers. A user doesn’t need to write code that directly controls the 24 MHz XOSC.

19.3 Voltage Regulator Control

The voltage regulators are controlled by the chip.

19.4 Active Modes (RX and TX)

The RF core has two active states, RX and TX.

  • The CMD_PROP_TX and CMD_PROP_TX_ADV commands set the radio in TX sending a packet(s) placed in the packet (or TX) queue the command points to.
  • The CMD_TX_TEST sets the radio in TX and a carrier wave (CW) or a 16 bit Tx word is sent continuously until the endTrigger or an abort command is issued.
  • The CMD_PROP_RX and CMD_PROP_RX_ADV commands set the the radio in Rx to receive a packet. The command exits Rx when the endTrigger is reached or a packet is received (optional).
  • The CMD_PROP_CS command sets the radio in RX to check if the RSSI is above a threshold or if a preamble is detected (Preamble Quality Threshold, PQT).
  • The CMD_PROP_RX_SNIFF and CMD_PROP_RX_ADV_SNIFF set the radio in Rx and combines the CMD_PROP_CS with normal packet reception.
  • The CMD_RX_TEST sets the radio in RX for test purposes.

The CMD_PROP_RADIO_SETUP and CMD_FS commands have to be issued before sending one of the commands above to start and calibrate the voltage controlled oscillator (VCO)/ phase locked loop (PLL), turn on the needed clocks, do patching and to configure the radio.

The radio commands are described in section 23 in the CC13x2 Technical Reference Manual. Some information can also be found in the description of the RF Core .

19.5 Wake On Radio (WOR)

Wake On Radio is shown in the example rfWakeOnRadioRx. This example uses the CMD_PROP_RX_SNIFF command.

19.6 Timing

The MCU timing is given in 5.19.2 in the CC13X2R1 Datasheet. The time to turn on the radio code and go either to RX or TX or TX <-> RX is not fixed. Part of the time is related to software and therefore the time will be dependent on how many and which patches are used. To get an accurate number the timing should be measured with the software intended to run on the device. The signal routing intended to control an external LNA or PA could be used to measure the timing (see Routing RF core signals to physical pins).

19.7 RX Termination Timer

The CMD_PROP_RX and CMD_PROP_RX_ADV have endTime as a parameter. Start and End Triggers gives an overview over the possible triggers.

20 Data FIFO

Data queues are used for transferring packets from the RF core to the main CPU and vice versa. For documentation, see:

21 Frequency Programming

The RF frequency needs to be given as input to two commands:


  • centerFreq: Center frequency of the band.

CMD_FS: Sets up the frequency synthesizer, described in in CC13x2 Technical Reference Manual.

The frequency is given in two parts:
  • frequency: Given in MHz
  • fractFreq: Fractional part of the frequency

If the frequency given in the CMD_FS command is different from the frequency given in the CMD_PROP_RADIO_DIV_SETUP command some parameters parameters will have been calculated with a relative error of up to: (freq - centerFreq)/ centerFreq. Deviation is one of the parameters that will be scaled with this factor. If this error is acceptable it is possible to do frequency hopping in the 863 MHz - 870 MHz band by setting the center frequency in the middle of the band, 867 MHz, using CMD_PROP_RADIO_DIV_SETUP once and the CMD_FS to set the frequencies when hopping.

SmartRF Studio can be used to calculate the frequency word.

22 Voltage-Controlled Oscillator (VCO)

The CMD_FS command starts and calibrate the VCO. On CC13x2 a CMD_FS has to be run for every frequency. It is not possible to pre-calibrate each channel.

23 Voltage Regulators

As with the CC1101, the CC13x2 contains internal regulators that are invisible for customers.

The battery voltage on CC13x2 is called VDDS (allowed level 1.8 V to 3.8 V). The output of the global low-dropout regulator (LDO)/ internal DCDC converter is called VDDR. When the DCDC is in use the VDDR net should not be connected to anything else than the external components shown in the reference designs. The Power Supply System is described in more detail in 1.3.13 in the CC13x2 Technical Reference Manual.

Note that on CC13x2 it is possible to run different DIO segments on different voltages; see 11.10.2 Digital Input/ Output Power Domains in the CC13x2 Technical Reference Manual.

24 Output Power Programming

The wanted output power is set in CMD_PROP_RADIO_DIV_SETUP.txPower. Max output power is dependent on the setting in The Customer Configuration (CCFG).

Most PAs have temperature dependent output power. On CC13x2 it is possible to compensate for the temperature dependency and get an output power that is close to independent of temperature. The txPower settings found in SmartRF Studio contain the temperature compensation. This compensation is only valid for boards that follow our reference design closely. If a custom board does not follow the reference design the output power will be different and the temperature compensation coefficients have to be calculated for the custom board. See in the CC13x2 Technical Reference Manual for equations.

For OOK the output power is set by Overrides.


The following is only valid gor CC13x0, not CC13x2.

Example: To set 13.0 dBm:

Override Output power @ 25 Degree C
0x6098,0x7200 14.0
0x6098,0x7100 13.4
0x6098,0x7000 13.0
0x6098,0x6F00 11.5
0x6098,0x6E00 9.5
0x6098,0x6D00 7.5
0x6098,0x6C00 5.2
0x6098,0x6B00 3.6
0x6098,0x6A00 1.4
0x6098,0x6900 -1.8
0x6098,0x6800 -7.2
0x6098,0x6700 -8.9
0x6098,0x6600 -10.8
0x6098,0x6500 -13.0
0x6098,0x6400 -15.7
0x6098,0x6300 -19.0
0x6098,0x6200 -22.8
0x6098,0x6100 -27.3

The numbers are an indication of which output power to expect when CCFG_FORCE_VDDR_HH=‘1’.

25 Shaping and PA Ramping

When using (G)FSK PA ramping is included in the examples.

26 General Purpose / Test Output Control Pins

  • Signal routing describes how to get some internal signal available on external pins.
  • Packet format contains some more information on how to use of the internal signals to debug packet formats.

27 Asynchronous and Synchronous Serial Operation

An asynchronous signal (MCE_GPO1) is available in RX, see Routing RF core signals to physical pins. This signal is the sign of the instantaneous frequency. This signal is used as input to further data processing and therefore measuring PER will give better sensitivity compared to looking at the asynchronous output.

It is only possible to get one signal from the RF core. It is therefore not possible to generate a clock at the same time as getting the data out.

For Tx it is not possible to apply an external bit stream to CC13x2 to be sent on the air. By using the TX buffer and the CMD_PROP_TX/ CMD_PROP_TX_ADV commands it is possible to generate the data wanted to send. It is not possible to turn off preamble (minimum 1 bit) and sync (minimum 8 bit). If the protocol is not using a sync word the sync word can be set equal to the first 8 bit of the payload.

28.2 Frequency Hopping and Multi-Channel Systems

The 15.4 Stack shows how frequency hopping can be implemented. On CC13x2 a CMD_FS has to be run for every frequency. It is not possible to pre-calibrate each channel.

28.3 Wide-band Modulation when not Using Spread Spectrum

An application note will be released to cover this.

28.4 Wireless MBUS

CC13x0 has full support for C, T and S mode. Download and documentation is available at Wireless M-Bus Protocol Software.

CC13x2 does not currently support WMBUS.

28.7 Battery Operated Systems

CC13x2 is designed to be used in battery operated system with very low standby current and low active current. The drivers ensure that the chip is in the state that gives lowest power consumption at any given time.

28.8 Increasing Range

For increased range (better sensitivity and higher output power), CC13x2 can be used together with CC1190 (CC1190 Datasheet). See Using CC1190 Front End With CC13xx Under EN300220 and Using CC1190 Front End With CC13xx Under FCC 15.247.

29 Configuration Registers

On CC1101 writing/ reading registers are required to operate the chip. On CC13x2 the control of the radio core is done by using drivers and APIs. Therefore no description is given of registers on CC13x2.