CC13xx/CC26xx SimpleLink Core SDK 7.10.02.00 Release Notes
Table of Contents
Introduction
This is a General Availability (GA) release of the Core SDK 7.10.02.00 for the CC26xx and CC13xx devices.
Documentation
Open the Documentation Overview file in the docs/ folder for a full list of documentation.
What’s New
- Added Arm® TrustZone® support to SimpleLink™ drivers
- Standardized Vector Table Section Names
- Use of inclusive technical terminology
- Logging component updates
- A summary of changes made in the current release of this product can be found in the product Change Log.
Upgrade and Compatibility Information
Enabling Arm® TrustZone®
SimpleLink™ drivers now support Arm® TrustZone® on CC13x4/CC26x4 devices. The Trusted Firmware-M (TF-M) implementation from Texas Instruments (TI) is based on Arm®’s open-source TF-M implementation. It controls the non-secure application’s access to the secure drivers and key storage.
In particular, TI’s persistent key storage is implemented using TF-M’s Internal Trusted Storage (ITS) service which implements PSA Internal Trusted Storage APIs to write keys to on-chip flash memory that is protected from non-secure application. TI’s TF-M supports secure execution, secure key storage, cryptographic operation, and initial attestation.
While it is recommended that cryptographic keys be stored in secure storage using Key Store driver when using TF-M, all SimpleLink™ APIs support both plaintext keys and key store keys to ensure backward compatibility. The following crypto drivers have support for TF-M along with secure key storage.
SimpleLink™ Driver | TF-M support | Key Store support |
---|---|---|
AESCBC | ✓ | ✓ |
AESCCM | ✓ | ✓ |
AESCMAC | ✓ | ✓ |
AESCTRDRBG | ✓ | ✓ |
AESECB | ✓ | ✓ |
AESGCM | ✓ | ✓ |
Attestation | ✓ | ✓ |
CryptoKey | ✓ | ✓ |
ECDH | ✓ | ✓ |
ECDSA | ||
EDDSA | ||
ECJPAKE | ||
SHA2 | ✓ | ✓ |
TRNG | ✓ |
Refer to tfm_empty
and tfm_aescbc
examples to get started with TF-M. TF-M and Key Store support for ECDSA, EDDSA, ECJPAKE, and TRNG drivers will be available in the future.
Support for PSA Cryptography API
Apart from TF-M support for SimpleLink™ driver APIs, we also support PSA Cryptograhy API using TF-M.
- C code available at
source/third_party/psa_crypto
Standardization of Vector Table Section Names
The vector table section names have been standardized and consolidated into one section name for the initial vector table in flash, .resetVecs
, and one section name for the vector table in RAM used at runtime, .ramVecs
. Previously, a number of different names were used across operating systems and toolchains. Some linker files had multiple section names for each of these in the same file, even though only one was being used.
If you are using a TI-provided linker file, there is nothing for you to do. All linker files shipped in the SDK have been updated, and this change will be transparent to you.
If you have customized a TI linker file or made your own, you will need to update the vector table section names used therein. The tables below only give an indication of what needs to be updated. This is because some of the previous directives within linker files were silently ineffective because they did not match section placement attributes and pragmas in the C code defining the vector table.
We recommend that you take a look at the relevant linker file in source/ti/boards
and copy the linker directives related to the vector tables contained in those files into your own and then modify from there if needed.
Toolchain | RTOS | Flash Vecs Section Before | Flash Vecs Section After |
---|---|---|---|
TICLANG | TI-RTOS7 | .intvecs |
.resetVecs |
TICLANG | FreeRTOS | .resetVecs |
.resetVecs |
TICLANG | NoRTOS | .intvecs |
.resetVecs |
GCC | TI-RTOS7 | .intvecs |
.resetVecs |
GCC | FreeRTOS | .resetVecs |
.resetVecs |
GCC | NoRTOS | .resetVecs |
.resetVecs |
IAR | TI-RTOS7 | .intvec |
.resetVecs |
IAR | FreeRTOS | .intvec |
.resetVecs |
IAR | NoRTOS | .intvec |
.resetVecs |
Toolchain | RTOS | RAM Vecs Section Before | RAM Vecs Section After |
---|---|---|---|
TICLANG | TI-RTOS7 | .vecs |
.ramVecs |
TICLANG | FreeRTOS | .vtable_ram |
.ramVecs |
TICLANG | NoRTOS | .vtable_ram |
.ramVecs |
GCC | TI-RTOS7 | .vtable |
.ramVecs |
GCC | FreeRTOS | .ramVecs |
.ramVecs |
GCC | NoRTOS | vtable_ram |
.ramVecs |
IAR | TI-RTOS7 | Hardcoded in C | .ramVecs |
IAR | FreeRTOS | .vtable_ram |
.ramVecs |
IAR | NoRTOS | .ramVecs |
.ramVecs |
Inclusive Terminology
As part of TI’s commitment to use inclusive technical terminology, we are updating legacy terminology to reflect the updated terminology used by the relevant industry standards bodies.
Some of these legacy terms are featured in APIs. Function names, structure field names, defines, and SysConfig field names are all impacted. As a result, several compatibility breaks are included in this Core SDK version compared to the previous one.
We have tried to minimize the impact on final applications where possible.
- SysConfig: SysConfig recognizes the legacy names to ensure that you do not get an immediate SysConfig error when rebuilding an existing project. If you change a setting in the SysConfig UI, the legacy names in your
.syscfg
file will be updated to the appropriate name automatically, for example,spi0.mosiPin
will be updated tospi0.picoPin
. - Driver API: Several top-level APIs are impacted that may be called directly from application code. By default, recompiling the application without any further changes will result in a compilation error as the compiler states that an undeclared function is being called. Even if that only results in a warning, the application will fail to link. There are two immediate options to get the application to compile again:
- Change all references in your application code to refer to the new terms as given in the conversion table below. Specifically, look at the entries for top-level APIs (
SPI.h
,I2C.h
,I2S.h
). - Provide
ENABLE_LEGACY_TERMINOLOGY
as a project-level define when compiling your application. This is a limited, temporary, backwards compatibility mode that will use the preprocessor to redefine the legacy terms to the inclusive terms. Support for this mode will be removed in the next SDK release. Additionally, using it carries the risk that it interacts poorly with existing application code if that code contains legacy terminology as substrings.
Below is a table that contains a mapping of legacy terms to inclusive terms for public APIs. Many other internal APIs and structure field names have changed as well. If you are accessing a private API or structure field directly, please look in the relevant .c and .h files for the new names.
Legacy API | Inclusive API | Header File |
---|---|---|
SPI_Mode.SPI_MASTER |
SPI_Mode.SPI_CONTROLLER |
SPI.h |
SPI_Mode.SPI_SLAVE |
SPI_Mode.SPI_PERIPHERAL |
SPI.h |
I2C_Transaction.slaveAddress |
I2C_Transaction.targetAddress |
I2C.h |
I2S_Role.I2S_MASTER |
I2S_Role.I2S_CONTROLLER |
I2S.h |
I2S_Role.I2S_SLAVE |
I2S_Role.I2S_TARGET |
I2S.h |
I2S_Params.MCLKDivider |
I2S_Params.CCLKDivider |
I2S.h |
Logging Update
The logging component has seen significant updates this release. It had remained in an early beta state for several releases. These changes are focused mainly on improving the usability of the end-to-end logging solution. The core functionality and technical architecture underlying the solution remains the same.
Changes include:
- Updates file structure for easier discovery
- Host tools in
tools/log/
- C and SysConfig in
source/ti/log/
- Revized and clarified LogLevel list:
Level | Explanation |
---|---|
Log_DEBUG | This should be the default level, reserved to be used by users to insert into applications for debugging. Libraries used in production should avoid using this level. |
Log_VERBOSE | This level is recommended to be used in libraries to emit verbose information |
Log_INFO | This level is recommended to be used in libraries to emit simple information |
Log_WARNING | This level is recommended to be used in libraries to emit warnings. It is up to the library developer to decide what constitutes a warning, but it should typically indicate something unexpected, but not something that leads to system failure |
Log_ERROR | This level is recommended to be used in libraries to emit errors. Typically, this should be used when something has failed and the system is unable to continue correct operation |
Log_ALL | This enables all levels |
- SysConfig UI updates
- Simplified creation of LogModules
- Configurable LogLevel per LogModule
- Per-LogModule selection of LogSink
- Improved Doxygen documentation
- Fixed ROV support for LogBuf sink
- Log versioning in
.out
metadata - If you have an old
.out
file, you can now find the exact tool version required to decode emitted logs - Improved timestamp encoding and host-side decoding
- Support for interlacing multiple log streams in Wireshark
These expansions of the logging ecosystem are planned for future releases:
- Additional LogSinks (UART, RF Tracer, etc.)
- Logging-enabled components such as drivers and kernels
- Logging-enabled asserts
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 12.2.0
- GNU Code Generation Tools
- ARM GCC 9.2019.q4.major-0
- IAR Code Generation Tools
- ARM 9.32.1
- TI Clang Code Generation Tools
- ARM ti-cgt-armllvm_2.1.2.LTS-0
- FreeRTOS 202104.00-0
- SysConfig 1.10.0
- XDCTools 3.62.01.15
- Python 3.8.10
New Features
ID | Summary |
---|---|
TIRTOS-2171 | Update Core SDK User Guide |
TIDRIVERS-5807 | Remove unused SPI implementation SPIDMACC26XX.c/h |
TIDRIVERS-5777 | Update to APIs to use inclusive technical terminology |
TIDRIVERS-5695 | SPI Driver: Add support for partial return queued transfer |
TIDRIVERS-5693 | spiffsinternal example uses incorrect block size |
TIDRIVERS-5632 | Example aesKeyAgreement ends up in while(1) when button 2 is pressed |
TIDRIVERS-5604 | XOSC_LF RTC temperature compensation |
TIDRIVERS-5210 | GPIO-owning drivers should call GPIO_init() and GPIO_setConfig() to set direction |
TIDRIVERS-1453 | Create Power_reset() function |
LPRFXXWARE-777 | Update to APIs to use inclusive technical terminology |
Fixed Issues
ID | Summary |
---|---|
TIDRIVERS-5959 | ECDH Curve25519 little-endian shared secret buffer overflow |
TIDRIVERS-5922 | ECDH driver overwrites result buffer for Montgomery curves in little-endian format |
TIDRIVERS-5917 | Setting GPIO_setConfig NO_DIR and then an output mux with GPIO_setMux causes line glitch |
TIDRIVERS-5912 | tfm-enabled examples are not loading on IAR |
TIDRIVERS-5839 | I2CCC26XX uses hard-coded BASE address and interrupt vector number |
TIDRIVERS-5828 | LP_EM_CC1312PSIP: Wrong I2C pin configuration when using BP-BASSENORS* BoosterPack |
TIDRIVERS-5827 | i2secho example: Wrong pin configuration for LP_EM_CC1312PSIP |
TIDRIVERS-5799 | SPI driver does not release standby power constraints and wakeup from CS is not functional on CC23X0 |
TIDRIVERS-5786 | Temperature driver can return incorrect reading if used shortly after the BATMON module has been enabled. |
TIDRIVERS-5769 | cc13x2x7_cc26x2x7 FreeRTOS pregenerated configurations not generated |
TIDRIVERS-5750 | Race condition in SemaphoreP_nortos pend |
TIDRIVERS-5686 | UART2 invokes write-callback twice |
TIDRIVERS-5507 | Core SDK libraries cannot be rebuilt in-field |
TIDRIVERS-5453 | Unintentional fall-through in SPICC26X2DMA.c |
TIDRIVERS-5267 | Failures during AES one-step operations may prevent future operations from running |
LPRFXXWARE-822 | PKAGetECCResult() casts a uint8_t* to uint32_t * without checking word alignment |
LPRFXXWARE-779 | Incorrect NUM_INTERRUPTS define value on CC13X4/CC26X4 |
LPRFXXWARE-736 | IOC define for I2C1 clock pin is wrong on CC13X4/CC26X4 |
LPRFXXWARE-735 | SPI module only supports registering interrupts for SPI0 and SPI1 on CC13X4/CC26X4 |
Known Issues
ID | Summary |
---|---|
TIRTOS-2164 | Simultaneous TI-RTOS 6 and TI-RTOS 7 support causes CCS XDS include path warning for TI-RTOS 6 |
TIPOSIX-4 | clock_nanosleep() with CLOCK_REALTIME broken on msp432 |
TIDRIVERS-4844 | Implement restrictions in errata note IOC_01 in SysConfig |
TIDRIVERS-4127 | ADCBuf causes jitter when switching clock sources |
TIDRIVERS-1642 | NVSSPI25x driver does not work when using internal SPI CS |
SYSBIOS-642 | Seconds_getTime() for MSP432P always returns ‘0’ in nanoseconds field |
SYSBIOS-446 | Reported CPU load is not 100% when a task is in “while 1 {}” loop |
SYSBIOS-98 | Load module won't work correctly if the TI-RTOS Power module is enabled for CC3200 or MSP432 |
FREERTOS-8 | Tasks view in ROV for FreeRTOS does not show if a task is blocked on a semaphore or mutex |
Customer Support
- Use the E2E support forums for customer support.
- Use the External Bug and Enhancement System to track issues.
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
A summary of changes made in previous releases of this product can be found in the product Change Log.