Readme for MSP430 Code Generation Tools v21.6.1.LTS
Table of Contents
Long-Term Support Release
The MSP430 CGT v21.6.x.LTS release is an LTS (Long-Term Support) release.
Definitions
Short-Term Support (STS) release: All STS branches will be made reactive upon creation. A patch release for this branch will only be created for production stop issues and will only contain fixes for the production stop issues. For all other issues, users are advised to wait for the next STS branch, which may also contain new features. STS releases will occur approximately every 3 months up until the first LTS release in a release stream.
Long-Term Support (LTS) release: The LTS branch will be active upon creation. The branch will be active for at least 2 years. Production stop defects will be addressed within 2 weeks of being reported. Critical defects will be addressed within 90 days. Defect repairs are proactively applied to each release stream. The LTS release is intended for customers to lock down on tools.
Compiler Documentation and Information
Documentation for the “TI MSP430 Optimizing Compiler User’s Guide” and the “TI MSP430 Assembly Language User’s Guide” is available online at:
https://www.ti.com/tool/MSP-CGT
TI E2E Community
Questions concerning TI Code Generation Tools can be posted to the TI E2E Community forums at:
The following is the top-level webpage for all of TI’s Code Generation Tools.
If submitting a defect report, please attach a scaled-down test case with command-line options and the compiler version number to allow us to reproduce the issue easily.
Defect Tracking Database
Compiler defect reports can be tracked at the Development Tools bug database at:
New Features:
Enumerated type changes
The exact type chosen for enumerated types and for enumeration constants has changed from previous branches for certain compilation modes. In particular, the compiler will now choose the same signedness for the underlying integer type for enumerated types in strict C mode as it always did in relaxed (default) C mode; the size of the underlying types chosen does not change.
That is, in strict ANSI mode, sometimes the compiler chose a signed type when it should have chosen the corresponding unsigned type. Also, the exact type of some enumeration constants may change in C mode. The C standard requires that all enumeration constants that will fit in “signed int” must have type “signed int,” which was not being observed in previous versions. Most programs will not be able to tell the difference. If you don’t assign an integer that does not correspond to an enumeration constant belonging to the enumerated type to a variable of that enumerated type, and you don’t perform arithmetic on enumerated types or enumeration constants, it is extremely difficult to tell the difference between the old behavior and the new behavior.
See the compiler user’s guide for the precise details of how underlying integer types for enumerated types and the types of enumeration constants are chosen.
Performance improvements
Pragmas MUST_ITERATE, UNROLL, and CODE_ALIGN: The MSP compiler now supports pragmas MUST_ITERATE, UNROLL and CODE_ALIGN. See Compiler user guide for more details.
BIC instruction optimization: The compiler now optimizes below expression to a single BIC instruction:
dst &= ~src to BIC instruction.
The improvement has now been extended for below case with multiple occurrences:
extern unsigned char src, dst0, dst1;
The compiler now generates below for --opt_level=off,0-4:
void func(void)
{
dst0 &= ~src;
dst1 &= ~src;
}BIC.B &src+0,&dst0+0
BIC.B &src+0,&dst1+0
Generate CRCs over memory ranges
Along with generating CRCs over output sections, the compiler can now generate CRCs over certain memory ranges. This feature is enabled by some new syntax added to the linker command file.
MEMORY
{
GROUP
{
MEMRANGE1 : origin = 0x000000, length = 0x000100
MEMRANGE2 : origin = 0x000100, length = 0x000100
} crc(_symbol, algorithm="CRC32_PRIME")
}The MEMORY directive now supports a top-level GROUP keyword, which will let users specify logical groups of memory ranges. These groups can then be CRC’ed by invoking the ‘crc’ operator.
The above is a snippet of a linker command file. The file describes two memory ranges that span from 0x0 -> 0x200, and there’s crc invocation that will compute a CRC32_PRIME over that range of memory.
Like CRC tables, the result will be stored in a table format, that’s accessible from the runtime via a linker-generated symbol (‘symbol’ in the example above). See the user guide for more information regarding the format of the table.
All CRC algorithms supported by CRC tables will also be supported by CRCs over memory ranges.
CRCs over memory ranges can only be computed over continuous blocks of memory that are on the same page. This means that there can be no gaps between any of the memory ranges included in a GROUP.
Misra support deprecated
Misra support has been deprecated and removed from this LTS release. The MISRA checking functionality will be disabled.
The --check_misra option is deprecated and issues a Warning.
The --misra_advisory and --misra_required options are deprecated and issue a remark.
All 3 options have no effect.
Resolved defects
Resolved defects in v21.6.1.LTS:
| ID | Summary |
|---|---|
| CODEGEN-10285 | bitfield assign incorrectly shifting before extending for uint64_var.bf=int32_var |
| CODEGEN-10058 | Compiler fails to handle bare \r as a line separator |
| CODEGEN-10009 | MSP430 compiler segfaults with math operations on addresses of variables |
| CODEGEN-9599 | Some compiler diagnostic ID numbers changed in releases after 2019 |
| CODEGEN-9082 | Optimizer drops part of a compound conditional expression controlling a loop |
| CODEGEN-9023 | static constexpr string literals cause compiler to emit duplicate mangled name |
| CODEGEN-4942 | Conditional expression containing GNU statement expression crashes compiler in C++ mode |
Known defects
The following link will lead to an updated list of known defects in this release: