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

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.

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.

  1. 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).
  2. 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:

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

These expansions of the logging ecosystem are planned for future releases:

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:

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

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.