Release Notes
Table of Contents
Introduction
This is a GA release of the Core SDK 3.30.03.00 for the CC26xx and CC13xx devices.
Documentation
Open the documentation overview web page file in the SDK’s Doc folder for a full list of documentation.
For further information on the drivers included in this product, see the Drivers Release Notes
What’s New
- This release updates to the newest code gen tools. See the Validation Information section for details on what versions of each code gen tools was used to test this release.
- Improvements to SPI driver implementation.
- This release includes 2 changes that were not included in 3.30.00.13.
- TIDRIVERS-1178 – RF driver RAT/Power update needed by BLE stack (also on the list below)
- updated to driverlib_cc13xx_cc26xx_3_02_03_17972 (see driverlib release notes for more)
New Features
| ID | Summary |
|---|---|
| TIRTOS-1195 | Add a new board for CC1350 Launchpad in 433MHz band |
| TIDRIVERS-1155 | NVS sections in GCC linker files should only set alignment |
| TIDRIVERS-1110 | Provide an NVS driver for RAM (NVSRAM) |
| TIDRIVERS-1109 | RF_cancelCmd() and RF_flushCmd() shall return RF_StatCmdEnded after command has finished |
| TIDRIVERS-1075 | Make Power_idleFunc() the default idleCallback in NoRTOS module |
| TIDRIVERS-972 | For better Flash utilization in the ROM build flow with TI tools, use linker's ‘>>’ to place .text, .const,.sections. |
| TIDRIVERS-957 | Implement generic ECDH driver for CC26X2 |
| TIDRIVERS-954 | Implement generic AES_CCM driver for CC26X2 |
| TIDRIVERS-75 | Update CC26XX SPI driver to have a polling mechanism for small transfers |
Bugs Resolved
| ID | Summary |
|---|---|
| TIRTOS-1193 | No-RTOS Display_printf “%%” problem in SystemP_nortos.c |
| TIRTOS-1160 | NoRTOS SwiP_destruct() gets stuck if the SWI is never posted after construct |
| TIDRIVERS-1182 | Race condition in No-RTOS HwiP_dispatch for CC3220, CC13xx and CC26xx |
| TIDRIVERS-1178 | Introduce automatic power management for the RAT APIs |
| TIDRIVERS-1170 | NVSSPI25X0 driver fails to read more than 1024 bytes at a time properly. |
| TIDRIVERS-1169 | LPRF board files do not enable UART ring buffer |
| TIDRIVERS-1157 | RF_runCmd() and RF_pendCmd() should not return RF_EventCmdError |
| TIDRIVERS-1147 | SPI drivers should support transfer timeout |
| TIDRIVERS-1136 | NoRTOS SemaphoreP_pend should use local ClockP structure |
| TIDRIVERS-1089 | RF driver – flush command does not remove the commands from the queue |
| TIDRIVERS-1083 | RF driver has a problem in handling background command |
| TIDRIVERS-1058 | Race condition in UARTCC26XX_read() implementation |
| TIDRIVERS-1020 | RF command with absolute start trigger failed with ‘Error past start’ when many clocks are active |
| TIDRIVERS-983 | RF driver hangs in RF_pendCmd in RFCC26XX_multiMode.c |
Upgrade and Compatibility Information
This release breaks compatibility with previous releases of the Core SDK in the following ways:
TIDRIVERS-983: RF driver hangs in RF_pendCmd in RFCC26XX_multiMode.c
The RF driver provides an method called RF_pendCmd() in order to be able to synchronize program execution in the applications context. This method is typically used together with the RF_postCmd() API, and receives:
- RF_Handle: returned by RF_open(),
- RF_CmdHandle: returned by RF_postCmd()
- RF_EentMask: bitmask of events which if occurs, program execution continues.
The RF_pendCmd() API had a potential issue when the RF_CmdHandle was representing a command-chain. In cases where the timing between the invocation of RF_postCmd() and RF_pendCmd() was not controlled properly, some of the commands within the chain may have been already executed by the RF core before the RF_pendCmd() was called. Since the method allows the user to subscribe to any events occurring during the execution of a chain, one could have subscribed to an event which was already fired causing the RF_pendCmd() to block forever.
The internal behaviour of the RF_pendCmd() method was redesigned in order to be able to handle such scenarios. The new implementation allows the user to:
- Subscribe to any event within a command chain and consequently continue the program execution on the first occurrence of any of these combined events.
- Unlock command execution and consume events that occured before invoking he RF_pendCmd() method.
- To call RF_pendCmd() multiple times on the same command handle, thus resynchronizing on different events.
TIDRIVERS-1157: RF_runCmd() and RF_pendCmd() should not return RF_EventCmdError
In addition to the behavioral improvements of the RF_pendCmd API, argument safety was also enhanced. In situations where an RF_ALLOC_ERROR code was passed to the RF_pendCmd() method, the RF_pendCmd() returned with RF_EventLastCommandDone. The return value of RF_pendCmd() always reflects the combined events which were issued during command execution and match the criteria provided by the user as input arguments to synchronize program execution upon. The user can also subscribe to these events with a callback providing the same bit mask to RF_postCmd(). Since the command execution could not begin due to error, returning RF_eventLastCommandDone was incorrect.
An alternative way to run commands synchronously is to invoke the RF_runCmd() method. In case the same situation occurs (allocation error), RF_runCmd() returned with RF_EventCmdError. Having two different return values was an inconsistency in the implementation of the API. Also, since RF_EventCmdError could not be passed as an input argument to any of the RF_postCmd() and RF_pendCmd() methods, the definition of this event was wrong.
Due to these differences, the return value of RF_runCmd() and RF_pendCmd() was synchronized. In case an allocation error occurs, both functions unlock with a return value of zero (0). An empty (0) return value interpreted as an error code reflects a run-time issue occurred before the execution of the body of API. This restores consistency to the definition of RF_EventMask type and enabled the elimination of the special return value RF_EventCmdError. Removing this define might causes compilation error in applications where this value was hardcoded.
A typical use cases can be implemented in the following way:
/* Correct usage of RF_runCmd() */
RF_EventMask terminationReason = RF_runCmd(...);
if (terminationReason == RF_EventLastCmdDone)
{ ... }
else if (terminationReason == ...)
{ ... }
else if (terminationReason == 0)
{ /* Error, RF_runCmd() had no effect. */ }
/* Correct usage of RF_pendCmd() */
RF_EventMask events = RF_pendCmd(rfHandle, commandHandle, ...);
if (events == 0)
{ /* Error, RF_pendCmd() did not have any effect due to an invalid command handle */ }
else {
if (events & (RF_EventLastCmdDone | RF_EventCmdAborted | RF_EventCmdStopped | RF_EventCmdCancelled)
{ /* Command terminated */ }
if (events & ...)
{ /* Events during command execution. */ }
}TIDRIVERS-1109 RF_cancelCmd() and RF_flushCmd() return RF_StatInvalidParamsError after command has finished
The RF driver provides two methods to be able to cancel commands that were previously submitted to the RF driver through the RF_postCmd() method: RF_cancelCmd() and RF_flushCmd(). These methods interact with the internal command queues and receive a command handle as an input argument.
In the below use case when the command was already executed, these functions returned with RF_StatInvalidParamsError. This behavior was surprising.
/* Submit a command to the RF driver. */
RF_CmdHandle cmdHandle = RF_postCmd(...);
/* Delay the execution. The RF core executes the submitted command in the mean time. */
Task_sleep(timeout);
/* Cancel the RF command. */
RF_Stat status = RF_cancelCmd(..., cmdHandle, ...);To improve the usability of this API, a new return value was introduced: RF_StatCmdEnded. In the above situation, as long as the driver stores cached information on the command which was already executed, the new return value will be issued. Calling the RF_postCmd() method several times will eventually overwrite the cached information and the default RF_StatInvalidParamsError will be returned afterwards.
Host Support
See the SDK release notes for a description of which host operating systems are supported in this release.
Dependencies
See the SDK release notes for a description of which components and tools are required to work with this product.
Device Support
See the SDK release notes for a list of TI devices that are supported in this product.
Validation Information
The Core SDK was validated with the following components:
- Code Composer Studio 7.3.0
- ARM 16.9.3.LTS
- GNU Code Generation Tools
- gcc-arm-none-eabi-6-2017-q1-update
- IAR Code Generation Tools
- ARM 8.11.2
- XDCTools 3.50.03
Known Issues
| ID | Summary |
|---|---|
| TIRTOS-476 | POSIX threads render as single task in execution graph |
| TIDRIVERS-1237 | ADCBuf driver fails on CC2640R2 for sampling frequencies > ~20kHz |
| TIDRIVERS-1208 | NoRTOS HwiPCC26XX_construct not setting the correct priority when called from UARTCC26XX_Open |
| TIDRIVERS-858 | Stack Underflow in SHA256 finish |
| TIDRIVERS-723 | UARTCC26XX.c accepts invalid open parameters |
| TIDRIVERS-439 | RF_ratCompare works intermittently in single mode code when future commands are posted |
| TIDRIVERS-406 | Warning in sensorI2C.c when building BLE CCS projects using I2C |
| TIDRIVERS-386 | Timing difference from SYSRESET as compared to a hard reset |
| TIDRIVERS-206 | Display driver does not support float |
| TIDRIVERS-204 | LCDDogm128 writes outside buffer |
| TIDRIVERS-188 | SPICC26XXDMA / UDMACC26XX - Bus faults not handled |
| TIDRIVERS-146 | Possible bug in LCD driver (DOGM 128-6) for drawing/clearing vertical lines |
| TIDRIVERS-92 | Incorrect thread safety in LCD_open |
Versioning
This product’s version follows a version format, M.mm.pp.bb, where M is a single digit Major number, mm is 2 digit minor number, pp is a 2 digit patch number, and b is an unrestricted set of digits used as an incrementing build counter.
Prior Release Changes
Core SDK 3.20.02 (Jul 10 2017)
New Features
None
Bugs Resolved
| ID | Summary |
|---|---|
| TIDRIVERS-1136 | NoRTOS SemaphoreP_pend should use local ClockP structure |
Core SDK 3.20.00 (May 25 2017)
New Features
| ID | Summary |
|---|---|
| TIRTOS-1069 | NoRTOS RF examples should be provided for all boards |
| TIRTOS-1036 | Supply Portable example with native RTOS APIs |
| TIRTOS-1022 | Support NoRTOS build for CC13xx/CC26xx |
| TIRTOS-1019 | Update CC13xx/CC26xx builds to use -DDeviceFamily_CC13X0, etc |
| TIRTOS-1009 | Add examples for NVS for internal and external SPI FLASH when available |
| TIRTOS-991 | Optimize DPL for size |
| TIRTOS-988 | Provide all single-task driver examples also for Non-RTOS |
| TIRTOS-948 | pthread_cond_timedwait should support CLOCK_MONOTONIC |
| TIRTOS-615 | Create example for UARTMon module |
| TIDRIVERS-1021 | ti/mw/lcd should be updated to use DPL to allow use with nortos |
| TIDRIVERS-1008 | Need Posix sleep and usleep for NoRTOS |
| TIDRIVERS-987 | RF driver - Only accept RF mode in single mode which is compatible with the device family |
| TIDRIVERS-986 | RF driver - RF_open/RF_close threading issue |
| TIDRIVERS-975 | Replace variable type unsigned int to uint32_t in single-mode RF driver |
| TIDRIVERS-971 | Provide NVS driver for SPI FLASH |
| TIDRIVERS-958 | Follow up on BLE stack RF_Object issue (RF.h) |
| TIDRIVERS-938 | Add examples to doxygen how to use the RF driver in case of synth lock error |
| TIDRIVERS-926 | [RF driver] - Enable override trimming required on CC26x0R2 BLE5 coded PHY |
| TIDRIVERS-925 | Replace turning off extFlash in PIN examples with bit-banged SPI PIN macro |
| TIDRIVERS-922 | Update PDM doxygen about which SCLK_HF I2S can run off of |
| TIDRIVERS-916 | Board.html should specify pin functions for communication buses |
| TIDRIVERS-900 | Various driver pin encodings need to be explained better |
| TIDRIVERS-895 | Do not specify HWI/SWI priorities in the board files, but rather in the application code |
| TIDRIVERS-891 | Rename ADC_convertRawToMicroVolts to ADC_convertToMicroVolts |
| TIDRIVERS-887 | Capture Driver top level implementation review and fix |
| TIDRIVERS-881 | Construct and destruct APIs for DPL |
| TIDRIVERS-865 | Add support for resetting the device if JTAG_PD is turned on due to noise on TCK (CC2640_R2) |
| TIDRIVERS-853 | Move I2S dependency on uDMA from PDM driver to power driver |
| TIDRIVERS-781 | CC13xx/26xx drivers should use DPL for OS independence (or use without RTOS) |
| TIDRIVERS-780 | DPL for non-RTOS support for CC13xx/CC26xx |
| TIDRIVERS-488 | Review TI-RTOS SemaphoreP implementation with goal to reduce stack usage |
Bugs Resolved
| ID | Summary |
|---|---|
| TIRTOS-954 | Update ADC examples to show microvolt values |
| TIDRIVERS-1054 | Correct the IEEE RX command definition |
| TIDRIVERS-1029 | Executing RF_yield while the RAT is OFF causes the RF driver hang |
| TIDRIVERS-1024 | Remove unnecessary fxn param in PDMCC26XX_utils.c driverlib call |
| TIDRIVERS-1023 | Inproper handling of shared interrupts of IEEE foreground/background commands |
| TIDRIVERS-1015 | Fix Chameleon 5x5 AUXIO-DIO mapping |
| TIDRIVERS-1011 | Fix vulnerability in CryptoCC26XX.h CCM example |
| TIDRIVERS-1005 | SemaphoreP_Params_init() should set mode to COUNTING |
| TIDRIVERS-1001 | Refactor interrupt handling in the RF driver |
| TIDRIVERS-984 | Expand the common RF_RadioSetup union with the BLE5 definition |
| TIDRIVERS-931 | NVS cannot use block larger than flash page size |
| TIDRIVERS-928 | NVSCC26XX driver does not lock interrupts while accessing the flash |
| TIDRIVERS-549 | NVSCC26XX driver does not disable line buffers |
Core SDK 3.10.03 (Mar 23 2017)
New Features
None
Bugs Resolved
| ID | Summary |
|---|---|
| TIRTOS-1021 | Update CC13xx/CC26x driverlib (with RF patch for cc26x0r2) |
| TIDRIVERS-992 | ti/mw/remotecontrol/buzzer.c references driverLib (should be driverlib) |
Core SDK 3.10.02 (Mar 1 2017)
New Features
None
Bugs Resolved
| ID | Summary |
|---|---|
| None | None |
Core SDK 3.10.01 (Feb 24 2017)
New Features
None
Bugs Resolved
| ID | Summary |
|---|---|
| TIRTOS-984 | Update imports.mak to match components in CCSv7.1 GA |
Core SDK 3.10.00 (Feb 15 2017)
New Features
| ID | Summary |
|---|---|
| TIRTOS-946 | Release.cfg should use policyMin instead of policySpin |
| TIRTOS-925 | IAR Examples.html should reference .eww and not .ipcf files any longer |
| TIRTOS-849 | Capture example needs to be replaced by CapturePWM |
| TIRTOS-842 | Need Mailbox example in the product |
| TIRTOS-750 | The CoreSDK is carrying around unnecessary files/directories |
Bugs Resolved
| ID | Summary |
|---|---|
| TIRTOS-933 | CCS platform warning with TI-RTOS examples |
| TIRTOS-900 | Display driver not printing float values |
| TIRTOS-891 | RTOS build in IAR should be an .ewp and preferably a dependent project like in CCS |
| TIRTOS-785 | Board_ADCBUFCHANNEL0 should be changed to Board_ADCBUF0CHANNEL0 for consistency |
| TIRTOS-776 | Posix usleep() function implemented in millisecond and not in microseconds |
| TIRTOS-709 | RTOS config projects are available only in makefile for IAR |
| TIRTOS-415 | IAR tools must be installed in non-default location to work with gmake |
| TIDRIVERS-745 | Change reverse() in source\ti\mw\lcd\SharpGrLib.c to SharpGrLib_reverse() |
Core SDK 3.01.01 (Dec 9 2016)
New Features
| ID | Summary |
|---|---|
| TIRTOS-838 | Update the IAR/Arm compiler tools to version 7.80.x |
| TIRTOS-832 | kernel examples should get stack size from linker.cmd files like driver examples |
| TIRTOS-821 | remove ‘eclipse’ directory from the product, CCSv7 needs only .metadata folder |
Bugs Resolved
| ID | Summary |
|---|---|
| TIRTOS-814 | Update primary_heap size logic in TI and GCC linker .cmd files |
| TIRTOS-606 | Makefiles should support tools directory names that contain spaces |
| TIDRIVERS-796 | Display_getType compile error for Display_DISABLE_ALL |
Core SDK 3.01.00 (Nov 9 2016)
New Features
| ID | Summary |
|---|---|
| TIRTOS-759 | Update TI tools to 16.9.0 to be ready for CCSv7.0 |
| TIRTOS-756 | Update examples to use Display_printf instead of print0, etc. |
| TIRTOS-745 | Display_Type_UART should disable RX to allow power savings |
| TIRTOS-705 | Power Management doc needs updating for CoreSDK |
| TIRTOS-543 | Update all Drivers examples with Display module usage as necessary |
| TIRTOS-248 | Move TI-RTOS driver documentation out of the user guide and into doxygen |
| TIDRIVERS-738 | Deprecate ti.drivers.Config as apps should supply libs on command line |
| TIDRIVERS-735 | Remove instrumented driver libraries and provide only release libraries |
| TIDRIVERS-601 | Update Power APIs for MISRA compliance |
| TIDRIVERS-569 | Update UART Display driver to function like an LCD |
Bugs Resolved
| ID | Summary |
|---|---|
| TIRTOS-552 | Spiloopback example master/slave needs synchronization |