Readme for C2000 Code Generation Tools v21.6.1.LTS

Long-Term Support Release
Compiler Downloads and Documentation
TI E2E Community
Defect Tracking Database
New Features:
Resolved defects
Known defects

Long-Term Support Release

The C2000 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 Downloads and Documentation

Documentation for the “TI C2000 Optimizing Compiler User’s Guide” and the “TI C2000 Assembly Language User’s Guide” is available online at:

https://www.ti.com/tool/C2000-CGT

TI E2E Community

Questions concerning TI Code Generation Tools can be posted to the TI E2E Community forums at:

E2E Development Forum

The following is the top-level webpage for all of TI’s Code Generation Tools.

Code Generation Tools Landing Page

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:

https://sir.ext.ti.com/

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

More efficient data accesses for lower 16-bits of memory: The C2000 compiler has a new feature for more efficiently accessing data with addresses in the lower 16-bits of memory. This can be done with either the location attribute:
```
 __attribute__((location(0x100))) extern struct PERIPH peripheral; 
```
Or dereferencing a literal (either of below):
```
 #define peripheral (*((struct PERIPH)(0x100)))
 struct EPWM_REGS volatile* const epwm1 = (struct EPWM_REGS *)(0x4000); 
```
CLA improved loading of 16-bit constants: Previously, the C2000/CLA compiler would produce the following assembly for the loading of a 16-bit constant:
```
 MOVIZ MR0,#0
 MOVXI MR0,#256
 MMOV16 @_g,MR0
 
```
For the use case of uint16_t, the first MOVIZ instruction is unnecessary and has now been eliminated.
Improved performance for library calls to fmaxf/fminf: Calls to the C99 library functions fmaxf and fminf in FPU32 mode and in relaxed mode will now use instructions MAXF32 or MINF32 rather than function calls. This does not apply to the “double” variants.

Improved performance for MIN/MAX conditionals with volatile variables: Conditionals like below would have generated code that used MINF32 or MAXF32:

 val1 = (val1>val2)?val2:val1;

However, if either variable was volatile then the generated code would instead involve slower code with branches.

      MOVW DP,#_val2 
      MOV32 R0H,@_val2 
      MOV32 R1H,@_val1 
      CMPF32 R1H,R0H 
      MOVST0 ZF, NF 
      B $C$L1,GT 
      MOVL ACC,@_val1
      B $C$L2,UNC 
 $C$L1:
      MOVL ACC,@_val2
 $C$L2:
      MOVL @_val1,ACC

Performance improvements have been made to avoid using branches and instead generate more efficient code sequences using conditional stores. eg:

 MOV32 R0H,@val1
 MOV32 R2H,@val2
 CMPF32 R0H,R2H
 MOV32 R0H,@Val2,GT
 MOV32 R0H,@Val1,LTE
 MOV32 @val1,R0H

Improved performance for several HWINTDIV routines: In the 18.12.0.LTS release, the initial HWINTDIV implementation had inefficiencies with directly loading integer constants into floating point registers. This release includes improvements with directly loading into floating pointer registers for 22-bit unsigned and signed positive integers for either numerator or denominator.

Live Firmware Update

To support updating EABI firmware images of C28x/CLA devices without powering them down, a new feature is available which allows preserving global and static symbol addresses at memory locations of a previous ELF executable alongside updating certain symbol addresses. This behavior is controlled by the following symbol attributes:

 __attribute__((preserve))
 __attribute__((update))

Path to a reference ELF executable can be provided to the compiler using the following compiler option:

 --lfu_reference_elf,-lfu=path

When performing a “warm” start i.e. a Live Firmware Update using an executable compiled with this feature, the preserve symbols are located at exactly the same addresses as before while symbols that are update can move to a different address and must be re-initialized using a new autoinit RTS routine called:

 void __TI_auto_init_warm();

This routine should be called from a custom entry point in order to not re-initialize all the symbols whose values in memory should be preserved.

If the update attribute is specified for one or more symbols then a new section .TI.update is created by the Linker and all update symbols are collected into this section. When this is the case, a new entry in the Linker command file to place this new .TI.update section in an appropriate memory range is required.

It is also possible to choose whether to preserve the locations of all global and static symbols by default or to only preserve when a symbol attribute is specified using the following compiler option:

 --lfu_default[=none,preserve]

The compiler defaults to preserving all global and static symbol addresses if found in the reference ELF executable unless an __attribute__((update)) is specified for a symbol. When -–lfu_default=none is specified, the compiler only preserves the addresses of those symbols which have __attribute__((preserve)) specified and is free to move the variables which have __attribute__((update)) specified.

It is also important to note that when variables are preserved for LFU, .TI.bound sections are created for each of these variables. When such sections are contiguous in memory, the Linker is able to coalesce them into single output sections and therefore reduce the number of CINIT records required to initialize them. The coalescing of bound sections is only enabled for Live Firmware Update at present.

For hand written assembly code, it is possible to have preserve behavior for symbols using a combination of a new directive .preserve <symbols_name> and adding a section for that symbol to be a subsection of .TI.bound as well as specifying .elfsym directives to indicate behavior. For e.g., to preserve the address of var0:

.preserve var0  ; In asm header block

…

.global ||var0||

.sect ".TI.bound:var0", RW

.elfsym ||var0||, SYM_PRESERVE(1)

…

.sblock ".TI.bound:var0"

For update behavior, simply making the section for that variable a subsection of TI.update and adding an .elfsym for that symbol is sufficient. For e.g. to update var1:

 .global ||var1||
 .sect “.TI.update:var1”, RW
 .elfsym ||var0||, SYM_UPDATE(1)
 …

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-10116	C2000 long-long compares using MINL/MINCUL used invalid indirect-postinc addressing mode
CODEGEN-10058	Compiler fails to handle bare \r as a line separator
CODEGEN-9831	ARM hextool boot table max block size limitation (when used with C28 on-chip boot loader)
CODEGEN-9631	CLA: Loads of 16bit signed, negative integers to MRn registers will incorrectly zero-extend by 16 bits rather than sign-extend
CODEGEN-9599	Some compiler diagnostic ID numbers changed in releases after 2019
CODEGEN-9423	C28 high priority fpu interrupt routines may not always save/restore RB register when isr uses RPTB
CODEGEN-9422	C28 –isr_save_vcu_regs=on does not always save/restore VCU registers
CODEGEN-9330	Severe slowdown of link-time DWARF compaction in COFF projects
CODEGEN-8471	Hex utility, when splitting a section as required by the bootloader, ignores the section alignment for the second part of the split
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:

Known defects – dynamic