This document describes the known exceptions to functional specifications (advisories) to the CC2652RSimpleLink™ device.
SimpleLink™ and Texas Instruments™ are trademarks of Texas Instruments.
Arm® and Cortex® are registered trademarks of Arm Limited (or its subsidiaries).
All trademarks are the property of their respective owners.
Table 1-1 lists all advisories, modules affected, and the applicable silicon revisions.
MODULE | DESCRIPTION | SILICON REVISIONS AFFECTED | |||
---|---|---|---|---|---|
E/F | |||||
Radio | Advisory Radio_03 — LE 2M PHY Sensitivity vs Selectivity | Yes | |||
Power | Advisory Power_03 — Increased voltage ripple at low supply voltages when DC/DC converter is enabled | Yes | |||
PKA | Advisory PKA_01 — Public key accelerator (PKA) interrupt line is always high when module is enabled and PKA is idle | Yes | |||
PKA | Advisory PKA_02 — Public key accelerator (PKA) RAM is not byte accessible | Yes | |||
I2C | Advisory I2C_01 — I2C module master status bit is set late | Yes | |||
I2S | Advisory I2S_01 — I2S bus faults are not reported | Yes | |||
CPU | Advisory CPU_01 — Arm® Errata #838869: Store immediate overlapping exception return operation might vector to incorrect interrupt | Yes | |||
CPU | Advisory CPU_02 — Arm® Errata #752770: Interrupted loads to SP can cause erroneous behavior | Yes | |||
CPU | Advisory CPU_03 — Arm® Errata #776924 VDIV or VSQRT instructions might not complete correctly when very short ISRs are used | Yes | |||
CPU, System | Advisory CPU_Sys_01 — The SysTick calibration value (register field CPU_SCS.STCR.TENMS) used to set up 10-ms periodic ticks is incorrect when the system CPU is running off divided down 48-MHz clock | Yes | |||
System | Advisory Sys_01 — Device might boot into ROM serial bootloader when waking up from shutdown | Yes | |||
System | Advisory Sys_05 — Elevated power-on-reset (POR) threshold voltage at low operating temperatures. | Yes | |||
System Controller | Advisory SYSCTRL_01 — Resets occurring in a specific 2-MHz period during initial power up are incorrectly reported | Yes | |||
SRAM | Advisory SRAM_01 — Reserved addresses within SRAM_MMR region alias into SRAM array | Yes | |||
General-Purpose Timer | Advisory GPTM_01 — An incorrect value might be written to the general-purpose (GP) timers MMRs (memory mapped registers) when simultaneously accessing the PKA (public key accelerator) engine and/or the AES (advanced encryption standard) engine from a different master | Yes | |||
ADC | Advisory ADC_01 — Periodic ADC trigger at 200 kHz rate can be ignored when XOSC_HF is turned on or off | Yes | |||
ADC | Advisory ADC_02 — ADC samples can be delayed by 2 or 14 clock cycles (24 MHz) when XOSC_HF is turned on or off, resulting in sample jitter | Yes | |||
ADC | Advisory ADC_03 — Software can hang when reading the ADC FIFO if a single manual ADC trigger is generated immediately after the ADC is enabled | Yes | |||
ADC | Advisory ADC_04 — Misbehaving ADC FIFO status flags in the AUX_ANAIF:ADCFIFOSTAT register (OVERFLOW, FULL, ALMOST_FULL, and EMPTY) | Yes | |||
ADC | Advisory ADC_05 — Writing any value to AUX_ANAIF:ADCTRIG.START will create an ADC trigger | Yes |
To designate the stages in the product development cycle, Texas Instruments™ assigns prefixes to the part numbers of all devices and support tools. Each device has one of three prefixes: X, P, or null (for example, XCC2652R). Texas Instruments recommends two of three possible prefix designators for its support tools: TMDX and TMDS. These prefixes represent evolutionary stages of product development from engineering prototypes (X/TMDX) through fully qualified production devices/tools (null/TMDS).
Device development evolutionary flow:
Support tool development evolutionary flow:
X and P devices and TMDX development-support tools are shipped against the following disclaimer:
"Developmental product is intended for internal evaluation purposes."
Production devices and TMDS development-support tools have been characterized fully, and the quality and reliability of the device have been demonstrated fully. TI's standard warranty applies.
Predictions show that prototype devices (X or P) have a greater failure rate than the standard production devices. Texas Instruments recommends that these devices not be used in any production system because their expected end-use failure rate still is undefined. Only qualified production devices are to be used.
This document supports the following device:
Figure 2-1 and Table 2-1 describe package symbolization and the device revision code.
DEVICE REVISION CODE | SILICON REVISION |
---|---|
E | PG2.1 (see following NOTE) |
F | PG3.0 (see following NOTE) |
LE 2M PHY Sensitivity vs Selectivity
Revision: F and earlier
Some devices operating using the Bluetooth Low Energy 2 Mbps (LE 2M) data rate may experience increased Packet Error Rate (PER) for receiver RSSI input levels centered around -70 dBm with a narrow window of +/- 5dB.
Updated radio settings are provided starting with the SimpleLink CC13xx_26xx SDK v5.40.00 and are applied by default. These settings improve sensitivity while resulting in up to 4 dB degradation in selectivity.
To minimize potential PER impact, it is recommended to leverage the updated radio settings made default in the SimpleLink CC13xx_26xx SDK v5.40.00 and later SDKs. If the LE 2M PHY is not used, it is not required to use these settings and SDK migration is not required. For applications configured to use the LE 2M PHY, migration to the latest SDK to leverage these settings is recommended.
Increased voltage ripple at low supply voltages when DC/DC converter is enabled
Revision F and earlier
At supply voltages <2.0V, a hardware control module disables the DC/DC converter to maximize system efficiency. This module does not have enough hysteresis, causing approx 10 mV of ripple on the VDDR regulated power supply. Based on internal testing of the device, it is not anticipated that this erratum affects RF performance. However, these test results cannot ensure that a customer’s application or end equipment will not be affected.
Use the TI-provided Power driver (PowerCC26X2.c) which automatically disables the DC/DC converter when supply voltage is <2.2V.
The workaround is available in all SDK versions.
Public key accelerator (PKA) interrupt line is always high when module is enabled and PKA is idle
Revision F and earlier
When the PKA module is enabled and idle, the interrupt line is always high and the interrupt can thus not be used as is.
The workaround is to disable the PKA interrupt in the interrupt service routine while the PKA module is idle and re-enable the interrupt right after starting an operation.
The workaround is implemented in the TI-provided cryptography drivers (ECDHCC26X2.c, ECDSACC26X2.c, ECJPAKECC26X2.c_list.c) in the following SimpleLink software development kit (SDK) versions:
Public key accelerator (PKA) RAM is not byte accessible
Revision F and earlier
When accessing the PKA RAM, the RAM is not byte accessible. If a single byte is accessed (read or written), 4 bytes will be accessed instead.
The workaround is to use word access (4 bytes) when accessing the PKA RAM.
The workaround is implemented in the TI-provided cryptography drivers (ECDHCC26X2.c, ECDSACC26X2.c, ECJPAKECC26X2.c_list.c) in the following SimpleLink software development kit (SDK) versions:
I2C module master status bit is set late
Revision F and earlier
The I2C.MSTAT[0] bit is not set immediately after writing to the I2C.MCTRL register. This can lead an I2C master to believe it is no longer busy and continuing to write data.
Add four NOPs between writing to the MCTRL register and polling the MSTAT register.
The workaround is implemented in the TI-provided I2C Master driver (I2CCC26XX.c) and in the I2C driver Library APIs (driverlib/i2c.c).
The workaround is available in all Software Development Kit (SDK) versions.
I2S bus faults are not reported
Revision F and earlier
The I2S module will not set the bus error interrupt flag (I2S0.IRQFLAGS.BUS_ERR) if an I2S read or write causes a system bus fault that results from access to illegal addresses (usage error).
Software must ensure that memory area used by the I2S DMA is accessible, meaning that the memory is powered on and the system bus is connected..
As an example; The TI-provided SPI driver SPICC26X2DMA.c will ensure that the flash memory is kept accessible also in Idle power mode if the transmit buffer address starts with 0x0 to ensure no bus faults occur. A similar approach needs to be taken if writing a peripheral driver utilizing I2S.
Arm® Errata #838869: Store immediate overlapping exception return operation might vector to incorrect interrupt
Revision F and earlier
Configurations Affected:
This erratum only affects systems where writeable memory locations can exhibit more than one wait state (system SRAM does not have wait states).
The Arm®Cortex®-M4 processor includes a write buffer that permits execution to continue while a store is waiting on the bus. Under specific timing conditions, during an exception return while this buffer is still in use by a store instruction, a late change in selection of the next interrupt to be taken might result in a mismatch between the interrupt acknowledged by the interrupt controller and the vector fetched by the processor.
Conditions:
STR/STRH/STRB <Rt>, [<Rn>,#imm]
STR/STRH/STRB <Rt>, [<Rn>,#imm]!
STR/STRH/STRB <Rt>, [<Rn>,#imm]
Implications:
The processor should execute interrupt handler C, and on completion of handler C the processor should execute the handler for B. If the previously listed conditions are met, then this erratum results in the processor erroneously clearing the pending state of interrupt C, and then twice executing the handler for B. The first time the handler for B is executed it will be at the priority level for interrupt C. If interrupt C is pended by a level-based interrupt that is cleared by C's handler then interrupt C will be pended again after the handler for B has completed and the handler for C will be executed. If interrupt C is level based, then this interrupt will eventually become re-pending and subsequently be handled. If interrupt C is a single pulse interrupt, there is a possibility that this interrupt will be lost.
This bug is triggered in a rare condition. In cases where STORE experiences more than 2 wait cycles, workarounds must be used by the software developer.
Software not using the Memory Protection Unit (MPU):
For software not using the Memory Protection Unit (MPU), the workaround can be to disable CPU write buffering (register CPU_SCS.ACTLR.DISDEFWBUF) at the cost of significantly reduced execution speed.
All other cases (recommended workaround):
Ensure a DSB instruction occurs between the store and the BX instruction. For exception handlers written in C, this can be achieved by inserting the appropriate set of intrinsics or inline assembly just before the end of the interrupt function, for example:
ARMCC:
...
__schedule_barrier(); __asm{DSB}; __schedule_barrier(); }
GCC:
...
__asm volatile (“dsb 0xf” ::: “memory”); }
The workaround for this bug will not be added automatically by the compiler.
Arm® Errata #752770: Interrupted loads to SP can cause erroneous behavior
Revision F and earlier
An interrupt occurring during the data-phase of a single word load to the stack-pointer (SP/R13) can cause an erroneous behavior of the device. In all cases, returning from the interrupt will result in the load instruction being executed an additional time. For all instructions performing an update to the base register, the base register will be erroneously updated on each execution, resulting in the stack-pointer being loaded from an incorrect memory location.
The affected instructions that can result in the load transaction being repeated are:
The affected instructions that can result in the stack-pointer being loaded from an incorrect memory address are:
Conditions:
Implications:
Unless the load is being performed to device memory or strongly-ordered memory, there should be no implications from the repetition of the load.
Most compilers ensure this bug is not triggered by not emitting the affected instruction sequence and not using the instructions in the compiler runtime libraries. This includes:
A workaround for both issues can be implemented by replacing the direct load to the stack-pointer, with an intermediate load to a general-purpose register followed by a move to the stack-pointer.
If repeated reads are acceptable, then the base register update issue may be worked around by performing the stack-pointer load without the base increment followed by a subsequent ADD or SUB instruction to perform the appropriate update to the base register.
Arm® Errata #776924: VDIV or VSQRT instructions might not complete correctly when very short ISRs are used
Revision F and earlier
On the Arm® Cortex®-M4F processor, the VDIV and VSQRT instructions take 14 cycles to execute. When an interrupt is taken a VDIV or VSQRT instruction is not terminated, and completes its execution while the interrupt stacking occurs. If lazy context save of floating point state is enabled then the automatic stacking of the floating point context does not occur until a floating point instruction is executed inside the interrupt service routine.
Lazy context save is enabled by default. When it is enabled, the minimum time for the first instruction in the interrupt service routine to start executing is 12 cycles. In certain timing conditions, and if there is only one or two instructions inside the interrupt service routine, then the VDIV or VSQRT instruction might not write its result to the register bank or to the FPSCR.
Conditions::
A minimum of 12 of these 14 cycles are utilized for the context state stacking, which leaves 2 cycles for instructions inside the interrupt service routine, or 2 wait states applied to the entire stacking sequence (which means that it is not a constant wait state for every access).
In general this means that if the memory system inserts wait states for stack transactions then this erratum cannot be observed.
Implications:
The VDIV or VQSRT instruction does not complete correctly and the register bank and FPSCR are not updated, meaning that these registers hold incorrect, out of date, data.
For hand-written assembly code inside interrupt routines, this erratum should be considered.
A workaround is only required if the floating point unit is present and enabled. A workaround is not required if the memory system inserts one or more wait states to every stack transaction.
When using TI-RTOS interrupts, all interrupt service routines will contain more than the 2 instructions and no workaround is required.
In all other cases, one of the following two workarounds must be implemented:
Workaround 1: Disable lazy context save of floating point state by clearing LSPEN to 0 (bit 30 of the FPCCR at address 0xE000EF34).
Workaround 2: Ensure that every interrupt service routine contains more than 2 instructions in addition to the exception return instruction.
The SysTick calibration value (register field CPU_SCS.STCR.TENMS) used to set up 10-ms periodic ticks is incorrect when the system CPU is running off divided down 48-MHz clock
Revision F and earlier
When using the Arm® Cortex® SysTick timer, the TENMS register field (CPU_SCS.STCR.TENMS) will always shows the value corresponding to a 48-MHz CPU clock, regardless of the CPU division factor.
One of the following two workarounds must be implemented:
Workaround 1: Do not use a divided down system CPU clock. In general, power savings are maximized by completing a task at full clock speed and then stopping the system CPU entirely after the task is complete.
Workaround 2: Read the system CPU division factor from the PRCM.CPUCLKDIV.RATIO register and compensate the TENMS field in software based on this value.
TI-provided drivers do not offer any functionality to divide the system CPU clock.
Device might boot into ROM serial bootloader when waking up from shutdown
Revision F and earlier
For the conditions given below, the device will boot into and execute the ROM serial bootloader when waking up from Shutdown power mode. Intended behavior is to execute the application image. The prerequisites for this erratum to happen are:
With the above prerequisites, the bootloader will be entered in the following cases:
Please refer to the ICEMelter chapter in the CC13x2, CC26x2 SimpleLink™ Wireless MCU Technical Reference Manual for details on how noise entering the JTAG TCK pin can wake up the device
One of the following workarounds must be implemented:
Elevated power-on-reset (POR) threshold voltage at low operating temperatures.
Revision F and earlier
When powering up the device from 0 V at below 0 °C, the POR circuit might not release reset before VDDS has reached 2.3 V instead of 1.8 V. After POR has released the reset, an affected device can continue to operate at voltages down to 1.8 V.
Workaround 1: Power-up the device at VDDS > 2.3V when operating at temperatures below 0°C.
or
Workaround 2: Power-up the device at VDDS < 2.3V AND trigger the Reset pin from a host MCU or external circuitry once VDDS reaches 1.8V.
In addition, when operating the device in external regulator mode, workaround 2 must be implemented. Please note that VDDS must not exceed 1.95V in external regulator mode. This is applicable only to devices that have external regulator mode support.
Resets occurring in a specific 2-MHz period during initial power up are incorrectly reported
Revision F and earlier
If a reset occurs in a specific 2-MHz period during initial power-up (boot), the reset source in AON_PMCTL.RESETCTL.RESET_SRC is reported as PWR_ON regardless of the reset source. This means that there is a window of 0.5 μs during boot where a reset can be incorrectly reported.
None
Reserved addresses within SRAM_MMR region alias into SRAM array
Revision F and earlier
Accessing addresses within SRAM_MMR and greater than SRAM_MMR.MEM_CTL (0x40035010 - 0x4003FFFC) will alias into the SRAM array (0x20000010 - 0x20000FFFC) for both reading and writing.
Avoid accessing reserved addresses within SRAM_MMR.
Note that if using the Memory Protection Unit (MPU) to protect accesses to the SRAM array, also consider protecting the reserved SRAM_MMR addresses.
An Incorrect Value Might Be Written to the General-Purpose (GP) Timers MMRs (Memory Mapped Registers) When Simultaneously Accessing the PKA (Public Key Accelerator) Engine and/or the AES (Advanced Encryption Standard) Engine from a Different Master
Revision F and earlier
When writing data to the GP Timer MMRs from one master while simultaneously accessing the PKA/AES modules from another master (read/write), an incorrect value might be captured in the GP Timer MMRs. In some cases, the incorrect value is replaced by the correct one after two clock cycles, but not always. No issue is seen when accessing the modules from the same master.
Avoid accesses to PKA/AES by other masters while writing to the GP Timer MMRs. This can be accomplished by acquiring the relevant semaphores (depending on drivers/stacks) before writing to the GP Timer.
Note that the BLE stack executes crypto operations from ISR context. Other software must release the semaphores from a higher-priority ISR to avoid deadlocks.
Verify the value written to the GP Timer MMR by reading it back in software. Correct the value if necessary.
Periodic ADC trigger at 200 kHz rate can be ignored when XOSC_HF is turned on or off
Revision F and earlier
There is no dedicated clock source selection for the ADC clock. The clock is derived from either XOSC_HF or RCOSC_HF, but defaults to XOSC_HF-derived clock whenever this is turned on.
When the ADC clock source is switched from RCOSC_HF to XOSC_HF-derived clock, the clock will stop for 2 cycles (24 MHz).
When the ADC clock source is switched from XOSC_HF-derived clock to RCOSC_HF-derived clock, the clock will stop for additionally 12 clock cycles, as the RCOSC_HF-derived clock is not ready when switch is done.
The fact that the clock is stopped, together with the difference in frequency between XOSC_HF and RCOSC_HF, may cause the ADC sampling and conversion to finish too late to catch the next trigger.
Use asynchronous sampling.
The sampling period after the issue occurs can be reduced by up to 20% (12 + 1 clock cycles at 24 MHz)
To use the ADC in asynchronous mode from the Sensor Controller:
Call adcEnableAsync()
to enable the ADC, instead of adcEnableSync()
Example:
adcEnableAsync(ADC_REF_FIXED, ADC_TRIGGER_AUX_TIMER0);
To use the ADC in asynchronous mode from the System CPU, by using the ADCBuf driver:
ADCBuf_Params params;
ADCBufCC26X2_ParamsExtension paramsExtension;
ADCBuf_Params_init(¶ms);
ADCBufCC26X2_ParamsExtension_init(¶msExtension);
paramsExtension.samplingMode = ADCBufCC26X2_SAMPING_MODE_ASYNCHRONOUS;
params.custom = ¶msExtension;
To use the ADC in asynchronous mode from the System CPU, by using DriverLib API:
Call AUXADCEnableAsync()
to enable the ADC, instead of AUXADCEnableSync()
Example:
AUXADCEnableAsync(AUXADC_REF_FIXED, AUXADC_TRIGGER_GPT0A);
Please note the difference between the asynchronous and synchronous ADC modes:
Ensure that XOSC_HF is not turned on or off while the ADC is used.
Increase the sampling period by (12+1)/24 µs or more.
ADC samples can be delayed by 2 or 14 clock cycles (24 MHz) when XOSC_HF is turned on or off, resulting in sample jitter
Revision F and earlier
There is no dedicated clock source selection for the ADC clock. The clock is derived from either XOSC_HF or RCOSC_HF, but defaults to XOSC_HF-derived clock whenever this is turned on.
When the ADC clock source is switched from RCOSC_HF to XOSC_HF-derived clock, the clock will stop for 2 cycles (24 MHz).
When the ADC clock source is switched from XOSC_HF-derived clock to RCOSC_HF-derived clock, the clock will stop for additionally 12 clock cycles, as the RCOSC_HF-derived clock is not ready when switch is done.
SCLK_HF switches from RCOSC_HF to XOSC_HF at different times compared to ADC clock. This leads to sample jitter.
Use asynchronous sampling
To use the ADC in asynchronous mode from the Sensor Controller:
Call adcEnableAsync()
to enable the ADC, instead of adcEnableSync()
Example:
adcEnableAsync(ADC_REF_FIXED, ADC_TRIGGER_AUX_TIMER0);
To use the ADC in asynchronous mode from the System CPU, by using the ADCBuf driver:
ADCBuf_Params params;
ADCBufCC26X2_ParamsExtension paramsExtension;
ADCBuf_Params_init(¶ms);
ADCBufCC26X2_ParamsExtension_init(¶msExtension);
paramsExtension.samplingMode = ADCBufCC26X2_SAMPING_MODE_ASYNCHRONOUS;
params.custom = ¶msExtension;
To use the ADC in asynchronous mode from the System CPU, by using DriverLib API:
Call AUXADCEnableAsync()
to enable the ADC, instead of AUXADCEnableSync()
Example:
AUXADCEnableAsync(AUXADC_REF_FIXED, AUXADC_TRIGGER_GPT0A);
Please note the difference between the asynchronous and synchronous ADC modes:
Ensure that XOSC_HF is not turned on or off while the ADC is used.
Software can hang when reading the ADC FIFO if a single manual ADC trigger is generated immediately after the ADC is enabled
Revision F and earlier
There is no dedicated clock source selection for the ADC clock. The clock is derived from either XOSC_HF or RCOSC_HF, but defaults to XOSC_HF-derived clock whenever this is turned on.
When the ADC clock source is switched from RCOSC_HF to XOSC_HF-derived clock, the clock will stop for 2 cycles (24 MHz).
When the ADC clock source is switched from XOSC_HF-derived clock to RCOSC_HF-derived clock, the clock will stop for additionally 12 clock cycles, as the RCOSC_HF-derived clock is not ready when switch is done.
The additional 12 clock cycles introduces a race between trigger-event and ADC trigger-detector to get out of reset.
Updated TI software adds a short delay at the end of the function that enables the ADC.
Ensure that XOSC_HF is not turned on or off while the ADC is used.