Release Notes

Table of Contents

Introduction

This is a GA release of the Core SDK 4.30.01.02 for MSP432E4 devices.

Documentation

Open the documentation overview web page file in the SDK’s Doc folder for a full list of documentation.

What’s New

Upgrade and Compatibility Information

This release breaks compatibility with previous releases of the Core SDK in the following ways:

Example/SysConfig Updates

All examples in this release have been updated to use SyscConfig. SysConfig generates .c and .h files with the various configuration data structures and constants. These files were previously written by hand. Check the User’s Guide for more information about SysConfig.

Here is a short summary of the changes to each example:

Previous Release This release
Hand written files with #defines and C structures example.syscfg (generates files with #defines and C structures)
Board.h, CCXXXX_LAUNCHXL.h ti_drivers_config.h
CCXXXX_LAUNCHXL.c ti_drivers_config.c
#defines are named Board_GPIO_LED0, etc. #defines are named CONFIG_GPIO_LED_0, etc.
pin settings common to all examples are shown in Board.html pin settings unique to each example are commented in ti_drivers_config.h

IAR RTOS plugin .dll

The ROV tool for IAR requires an update to work properly. If you are an ROV user, follow the instructions on this forum page: https://e2e.ti.com/support/processors/f/791/t/832561. If you don’t use ROV, you can proceed with the standard debugging sessions. The ROV tool does not affect any other funcationality.

Crypto API changes

The Crypto APIs have changed in the following ways:

TIDRIVERS-3849

Public and private keys as well as signature components hash, r, and s are now represented in octet string (OS) format as defined by SEC 1: Elliptic Curve Cryptography when using the ECDSA driver. Conversion from OS format to elliptic curve parameters and coordinates is now handled internally within the ECDSA driver itself.

The move from little-endian integers to represent public and private keying material to OS format has the following implications:

Previous Release This release
Private keying material considered as little-endian integer Private keying material considered as big-endian integer
Hash considered as little-endian integer Hash considered as big-endian integer
r considered as little-endian integer r considered as big-endian integer
s considered as little-endian integer s considered as big-endian integer
Public keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. Public keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer.

As a result, public keys are now one byte longer than before and formatting of public and private keys as well as signature components r, s, and hashes within the application must be reviewed.

In practice, this will mean reversing the buffers containing the private key, r, s, hash, and public key coordinates as well as adding the formatting byte to the public keying material.

Since most networking stacks specify public keys to be formatted in OS format for transport over the network, this should result in the application no longer needing to convert to and from OS format. The OS formatted public key and signature received over the network can be used and stored without reformatting within the application itself.

Previously, the hash output of the chosen hash function had to be reversed in order to pass it into the ECDSA driver. This is no longer required. The hash output may be passed into the driver without any byte reversal.

Here is a table that illustrates the changes at byte level:

Parameter Previous Release This release
Private keying material {
0x13,0x0e,0xed,0x5e,0xb9,0xbb,0x8e,0x01,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}
{
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x01,0x8e,0xbb,0xb9,0x5e,0xed,0x0e,0x13
}
Hash // This is the byte reversed SHA256 hash
// of the ASCII string
// “Example of ECDSA with P-256”
{
0xC4,0xA8,0xC8,0x99,0x28,0xCF,0x80,0xB6,
0xE4,0x42,0xD5,0xBD,0x28,0x4D,0xE3,0xFD,
0x3A,0x13,0xD8,0x65,0x0C,0x41,0x1C,0x21,
0x48,0x95,0x79,0x2A,0xA1,0x41,0x1A,0xA4,
}
// This is the SHA256 hash of the ASCII string
// “Example of ECDSA with P-256”
{
0xA4,0x1A,0x41,0xA1,0x2A,0x79,0x95,0x48,
0x21,0x1C,0x41,0x0C,0x65,0xD8,0x13,0x3A,
0xFD,0xE3,0x4D,0x28,0xBD,0xD5,0x42,0xE4,
0xB6,0x80,0xCF,0x28,0x99,0xC8,0xA8,0xC4,
}
r {0xa6,0x41,0x5f,0xc9,0xf0,0x29,0xdd,0xb5,
0x3c,0x3d,0x6e,0xe6,0xa2,0x54,0x9a,0x10,
0xac,0xdd,0x43,0x78,0x48,0x24,0xd7,0xfc,
0xd2,0x0d,0xca,0xe8,0xe8,0x82,0x28,0x70,}
{0x70,0x28,0x82,0xe8,0xe8,0xca,0x0d,0xd2,
0xfc,0xd7,0x24,0x48,0x78,0x43,0xdd,0xac,
0x10,0x9a,0x54,0xa2,0xe6,0x6e,0x3d,0x3c,
0xb5,0xdd,0x29,0xf0,0xc9,0x5f,0x41,0xa6,}
s {0xb3,0xf5,0x2b,0x0a,0x6f,0x31,0x04,0x25,
0x0a,0x72,0x94,0xfe,0xfd,0xe7,0xf1,0x17,
0x99,0x3d,0x27,0xd9,0x7f,0x12,0xc3,0x4e,
0xdf,0x6f,0xa7,0x93,0xec,0x38,0x16,0xc0,}
{0xc0,0x16,0x38,0xec,0x93,0xa7,0x6f,0xdf,
0x4e,0xc3,0x12,0x7f,0xd9,0x27,0x3d,0x99,
0x17,0xf1,0xe7,0xfd,0xfe,0x94,0x72,0x0a,
0x25,0x04,0x31,0x6f,0x0a,0x2b,0xf5,0xb3,}
Public keying material {
//X
0x5F,0x9D,0x9B,0xE5,0x63,0x8C,0x66,0x63,
0xF1,0x0E,0x3A,0xDE,0x92,0xAF,0x03,0xAE,
0x65,0x82,0x88,0x99,0x89,0x37,0xFB,0xAD,
0xE7,0xBA,0x1A,0x97,0xC6,0x4D,0x45,0xF0,
//Y
0x36,0x4F,0x03,0x0D,0xDE,0x9C,0xE5,0x47,
0x3F,0xFA,0xB5,0x75,0xCE,0x21,0x3B,0x2A,
0xE6,0x43,0x96,0x1F,0xE5,0x94,0x65,0x4E,
0x1F,0x2D,0x2E,0x59,0xE3,0x3E,0xB9,0xB5,
}
{
// Formatting byte
0x04,
//X
0xF0,0x45,0x4D,0xC6,0x97,0x1A,0xBA,0xE7,
0xAD,0xFB,0x37,0x89,0x99,0x88,0x82,0x65,
0xAE,0x03,0xAF,0x92,0xDE,0x3A,0x0E,0xF1,
0x63,0x66,0x8C,0x63,0xE5,0x9B,0x9D,0x5F,
//Y
0xB5,0xB9,0x3E,0xE3,0x59,0x2E,0x2D,0x1F,
0x4E,0x65,0x94,0xE5,0x1F,0x96,0x43,0xE6,
0x2A,0x3B,0x21,0xCE,0x75,0xB5,0xFA,0x3F,
0x47,0xE5,0x9C,0xDE,0x0D,0x03,0x4F,0x36,
}
TIDRIVERS-3847

The per-message secret number (PMSN) parameter of the ECDSA_OperationSign struct was removed. Signing a message with a known PMSN would allow attackers to derive the private key from the signature. On devices with a keystore, this method could also be used to exfiltrate the private key from the keystore. Consequently, the driver will ensure that a suitable PMSN is generated and discarded internally. On CC26X2, the TRNG is used to generate the PMSN internally.

TIDRIVERS-3816

Public keys, private keys, public Vs, private Vs, hashes, r, generator points, pre-shared secrets, and shared secrets, are now represented in octet string (OS) format as defined by SEC 1: Elliptic Curve Cryptography when using the ECJPAKE driver. Conversion from OS format to elliptic curve parameters and coordinates is now handled internally within the ECJPAKE driver itself.

The move from little-endian integers to represent public and private keying material to OS format has the following implications:

Previous Release This release
Private keying material considered as little-endian integer Private keying material considered as big-endian integer
Private v material considered as little-endian integer Private v material considered as big-endian integer
Hash considered as little-endian integer Hash considered as big-endian integer
r considered as little-endian integer r considered as big-endian integer
Pre-shared secret considered as little-endian integer Pre-shared secret considered as big-endian integer
Public keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. Public keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer.
Public V material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. Public V material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer.
ZKP generator point keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. ZKP generator point keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer.
Shared Secret keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. Shared secret keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer.

As a result, public keys, public Vs, shared secrets, and ZKP generator points are now one byte longer than before and formatting of all public V, private v, public keys, private keys, r, hashes, pre-shared secrets, and shared secrets within the application must be reviewed.

In practice, this will mean reversing the buffers containing the private key, private v, r, hash, pre-shared secret, public key coordinates, public V coordinates, generator point coordinates, and shared secret coordinates as well as adding the formatting byte to the public key, public V, generator point, and shared secret.

Since most networking stacks specify public keys to be formatted in OS format for transport over the network, this should result in the application no longer needing to convert to and from OS format. The OS formatted public key and signature received over the network can be used and stored without reformatting within the application itself.

Previously, the hash output of the chosen hash function had to be reversed in order to pass it into the ECJPAKE driver. This is no longer required. The hash output may be passed into the driver without any byte reversal.

Here is a table that illustrates the changes at byte level:

Parameter Previous Release This release
Private keying material {
0x13,0x0e,0xed,0x5e,0xb9,0xbb,0x8e,0x01,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}
{
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x01,0x8e,0xbb,0xb9,0x5e,0xed,0x0e,0x13
}
Private v material {
0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}
{
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x0F
}
Hash // This is the byte reversed SHA256 hash
// of the ASCII string
// “Example of ECDSA with P-256”
{
0xC4,0xA8,0xC8,0x99,0x28,0xCF,0x80,0xB6,
0xE4,0x42,0xD5,0xBD,0x28,0x4D,0xE3,0xFD,
0x3A,0x13,0xD8,0x65,0x0C,0x41,0x1C,0x21,
0x48,0x95,0x79,0x2A,0xA1,0x41,0x1A,0xA4,
}
// This is the SHA256 hash of the ASCII string
// “Example of ECDSA with P-256”
{
0xA4,0x1A,0x41,0xA1,0x2A,0x79,0x95,0x48,
0x21,0x1C,0x41,0x0C,0x65,0xD8,0x13,0x3A,
0xFD,0xE3,0x4D,0x28,0xBD,0xD5,0x42,0xE4,
0xB6,0x80,0xCF,0x28,0x99,0xC8,0xA8,0xC4,
}
r {
0xff,0xff,0xff,0xff,0x00,0x00,0x00,0x00,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xbc,0xe6,0xfa,0xad,0xa7,0x17,0x9e,0x84,
0xf3,0xb9,0xca,0xc2,0xfc,0x63,0x25,0x3d,
}
{
0x3d,0x25,0x63,0xfc,0xc2,0xca,0xb9,0xf3,
0x84,0x9e,0x17,0xa7,0xad,0xfa,0xe6,0xbc,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0x00,0x00,0x00,0x00,0xff,0xff,0xff,0xff,
}
Pre-shared secret // The pre-shared secret can be any
// byte-string <= 32 bytes.
// This one is 15 bytes.
{
0x74,0x73,0x65,0x74,0x65,0x6B,0x61,0x70,
0x6A,0x64,0x61,0x65,0x72,0x68,0x71
}
// The pre-shared secret can be any
// byte-string <= 32 bytes.
// This one is 15 bytes.
{
0x71,0x68,0x72,0x65,0x61,0x64,0x6A,0x70,
0x61,0x6B,0x65,0x74,0x65,0x73,0x74,
}
Public keying material {
//X
0x5F,0x9D,0x9B,0xE5,0x63,0x8C,0x66,0x63,
0xF1,0x0E,0x3A,0xDE,0x92,0xAF,0x03,0xAE,
0x65,0x82,0x88,0x99,0x89,0x37,0xFB,0xAD,
0xE7,0xBA,0x1A,0x97,0xC6,0x4D,0x45,0xF0,
//Y
0x36,0x4F,0x03,0x0D,0xDE,0x9C,0xE5,0x47,
0x3F,0xFA,0xB5,0x75,0xCE,0x21,0x3B,0x2A,
0xE6,0x43,0x96,0x1F,0xE5,0x94,0x65,0x4E,
0x1F,0x2D,0x2E,0x59,0xE3,0x3E,0xB9,0xB5,
}
{
// Formatting byte
0x04,
//X
0xF0,0x45,0x4D,0xC6,0x97,0x1A,0xBA,0xE7,
0xAD,0xFB,0x37,0x89,0x99,0x88,0x82,0x65,
0xAE,0x03,0xAF,0x92,0xDE,0x3A,0x0E,0xF1,
0x63,0x66,0x8C,0x63,0xE5,0x9B,0x9D,0x5F,
//Y
0xB5,0xB9,0x3E,0xE3,0x59,0x2E,0x2D,0x1F,
0x4E,0x65,0x94,0xE5,0x1F,0x96,0x43,0xE6,
0x2A,0x3B,0x21,0xCE,0x75,0xB5,0xFA,0x3F,
0x47,0xE5,0x9C,0xDE,0x0D,0x03,0x4F,0x36,
}
Public V material {
// X
0x5F,0x9D,0x9B,0xE5,0x63,0x8C,0x66,0x63,
0xF1,0x0E,0x3A,0xDE,0x92,0xAF,0x03,0xAE,
0x65,0x82,0x88,0x99,0x89,0x37,0xFB,0xAD,
0xE7,0xBA,0x1A,0x97,0xC6,0x4D,0x45,0xF0,
// Y
0x36,0x4F,0x03,0x0D,0xDE,0x9C,0xE5,0x47,
0x3F,0xFA,0xB5,0x75,0xCE,0x21,0x3B,0x2A,
0xE6,0x43,0x96,0x1F,0xE5,0x94,0x65,0x4E,
0x1F,0x2D,0x2E,0x59,0xE3,0x3E,0xB9,0xB5
},
{
// Formatting byte
0x04,
// X
0xF0,0x45,0x4D,0xC6,0x97,0x1A,0xBA,0xE7,
0xAD,0xFB,0x37,0x89,0x99,0x88,0x82,0x65,
0xAE,0x03,0xAF,0x92,0xDE,0x3A,0x0E,0xF1,
0x63,0x66,0x8C,0x63,0xE5,0x9B,0x9D,0x5F,
// Y
0xB5,0xB9,0x3E,0xE3,0x59,0x2E,0x2D,0x1F,
0x4E,0x65,0x94,0xE5,0x1F,0x96,0x43,0xE6,
0x2A,0x3B,0x21,0xCE,0x75,0xB5,0xFA,0x3F,
0x47,0xE5,0x9C,0xDE,0x0D,0x03,0x4F,0x36,
}
ZKP generator // NIST-P256 generator point
{
//X
0x96,0xc2,0x98,0xd8,0x45,0x39,0xa1,0xf4,
0xa0,0x33,0xeb,0x2d,0x81,0x7d,0x03,0x77,
0xf2,0x40,0xa4,0x63,0xe5,0xe6,0xbc,0xf8,
0x47,0x42,0x2c,0xe1,0xf2,0xd1,0x17,0x6b,
//Y
0xf5,0x51,0xbf,0x37,0x68,0x40,0xb6,0xcb,
0xce,0x5e,0x31,0x6b,0x57,0x33,0xce,0x2b,
0x16,0x9e,0x0f,0x7c,0x4a,0xeb,0xe7,0x8e,
0x9b,0x7f,0x1a,0xfe,0xe2,0x42,0xe3,0x4f
}
// NIST-P256 generator point
{
// Formatting byte
0x04
//X
0x6b,0x17,0xd1,0xf2,0xe1,0x2c,0x42,0x47,
0xf8,0xbc,0xe6,0xe5,0x63,0xa4,0x40,0xf2,
0x77,0x03,0x7d,0x81,0x2d,0xeb,0x33,0xa0,
0xf4,0xa1,0x39,0x45,0xd8,0x98,0xc2,0x96,
//Y
0x4f,0xe3,0x42,0xe2,0xfe,0x1a,0x7f,0x9b,
0x8e,0xe7,0xeb,0x4a,0x7c,0x0f,0x9e,0x16,
0x2b,0xce,0x33,0x57,0x6b,0x31,0x5e,0xce,
0xcb,0xb6,0x40,0x68,0x37,0xbf,0x51,0xf5,
}
Shared secret {
// X
0x96,0xC2,0x98,0xD8,0x45,0x39,0xA1,0xF4,
0xA0,0x33,0xEB,0x2D,0x81,0x7D,0x03,0x77,
0xF2,0x40,0xA4,0x63,0xE5,0xE6,0xBC,0xF8,
0x47,0x42,0x2C,0xE1,0xF2,0xD1,0x17,0x6B,
// Y
0xF5,0x51,0xBF,0x37,0x68,0x40,0xB6,0xCB,
0xCE,0x5E,0x31,0x6B,0x57,0x33,0xCE,0x2B,
0x16,0x9E,0x0F,0x7C,0x4A,0xEB,0xE7,0x8E,
0x9B,0x7F,0x1A,0xFE,0xE2,0x42,0xE3,0x4F
}
{
// Formatting byte
0x04,
// X
0x6B,0x17,0xD1,0xF2,0xE1,0x2C,0x42,0x47,
0xF8,0xBC,0xE6,0xE5,0x63,0xA4,0x40,0xF2,
0x77,0x03,0x7D,0x81,0x2D,0xEB,0x33,0xA0,
0xF4,0xA1,0x39,0x45,0xD8,0x98,0xC2,0x96,
// Y
0x4F,0xE3,0x42,0xE2,0xFE,0x1A,0x7F,0x9B,
0x8E,0xE7,0xEB,0x4A,0x7C,0x0F,0x9E,0x16,
0x2B,0xCE,0x33,0x57,0x6B,0x31,0x5E,0xCE,
0xCB,0xB6,0x40,0x68,0x37,0xBF,0x51,0xF5
}
TIDRIVERS-3779

Public and private keys for the ECDH driver are now represented in octet string (OS) format as defined by SEC 1: Elliptic Curve Cryptography. Conversion from OS format to elliptic curve parameters and coordinates is now handled internally within the ECDH driver itself.

The move from little-endian integers to represent public and private keying material to OS format has the following implications:

Previous Release This release
Private keying material considered as little-endian integer Private keying material considered as big-endian integer
Public keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. Public keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer.
Shared Secret keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. Shared secret keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer.

As a result, public keys and shared secrets are now one byte longer than before and formatting of public and private keys within the application must be reviewed.

In practice, this will mean reversing the buffers containing the private key and the public key coordinates as well as adding the formatting byte. Since most networking stacks specify public keys to be formatted in OS format for transport over the network, this should result in the application no longer needing to convert to and from OS format. The OS formatted public key received over the network can be used and stored without reformatting within the application itself.

Here is a table that illustrates the changes at byte level:

Parameter Previous Release This release
Private keying material {
0x13,0x0e,0xed,0x5e,0xb9,0xbb,0x8e,0x01,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}
{
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x01,0x8e,0xbb,0xb9,0x5e,0xed,0x0e,0x13
}
Public keying material {
//X
0x5F,0x9D,0x9B,0xE5,0x63,0x8C,0x66,0x63,
0xF1,0x0E,0x3A,0xDE,0x92,0xAF,0x03,0xAE,
0x65,0x82,0x88,0x99,0x89,0x37,0xFB,0xAD,
0xE7,0xBA,0x1A,0x97,0xC6,0x4D,0x45,0xF0,
//Y
0x36,0x4F,0x03,0x0D,0xDE,0x9C,0xE5,0x47,
0x3F,0xFA,0xB5,0x75,0xCE,0x21,0x3B,0x2A,
0xE6,0x43,0x96,0x1F,0xE5,0x94,0x65,0x4E,
0x1F,0x2D,0x2E,0x59,0xE3,0x3E,0xB9,0xB5,
}
{
// Formatting byte
0x04,
//X
0xF0,0x45,0x4D,0xC6,0x97,0x1A,0xBA,0xE7,
0xAD,0xFB,0x37,0x89,0x99,0x88,0x82,0x65,
0xAE,0x03,0xAF,0x92,0xDE,0x3A,0x0E,0xF1,
0x63,0x66,0x8C,0x63,0xE5,0x9B,0x9D,0x5F,
//Y
0xB5,0xB9,0x3E,0xE3,0x59,0x2E,0x2D,0x1F,
0x4E,0x65,0x94,0xE5,0x1F,0x96,0x43,0xE6,
0x2A,0x3B,0x21,0xCE,0x75,0xB5,0xFA,0x3F,
0x47,0xE5,0x9C,0xDE,0x0D,0x03,0x4F,0x36,
}
Shared secret {
// X
0x96,0xC2,0x98,0xD8,0x45,0x39,0xA1,0xF4,
0xA0,0x33,0xEB,0x2D,0x81,0x7D,0x03,0x77,
0xF2,0x40,0xA4,0x63,0xE5,0xE6,0xBC,0xF8,
0x47,0x42,0x2C,0xE1,0xF2,0xD1,0x17,0x6B,
// Y
0xF5,0x51,0xBF,0x37,0x68,0x40,0xB6,0xCB,
0xCE,0x5E,0x31,0x6B,0x57,0x33,0xCE,0x2B,
0x16,0x9E,0x0F,0x7C,0x4A,0xEB,0xE7,0x8E,
0x9B,0x7F,0x1A,0xFE,0xE2,0x42,0xE3,0x4F
}
{
// Formatting byte
0x04,
// X
0x6B,0x17,0xD1,0xF2,0xE1,0x2C,0x42,0x47,
0xF8,0xBC,0xE6,0xE5,0x63,0xA4,0x40,0xF2,
0x77,0x03,0x7D,0x81,0x2D,0xEB,0x33,0xA0,
0xF4,0xA1,0x39,0x45,0xD8,0x98,0xC2,0x96,
// Y
0x4F,0xE3,0x42,0xE2,0xFE,0x1A,0x7F,0x9B,
0x8E,0xE7,0xEB,0x4A,0x7C,0x0F,0x9E,0x16,
0x2B,0xCE,0x33,0x57,0x6B,0x31,0x5E,0xCE,
0xCB,0xB6,0x40,0x68,0x37,0xBF,0x51,0xF5
}

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:

Known Issues

ID Summary
TIRTOS-1959 IAR project is not rebuilt after .syscfg file is modified
TIDRIVERS-3636 I2C_transfer() occasionally fails when called from an interrupt context
TIDRIVERS-1642 NVSSPI25x driver does not work when using internal SPI CS

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