Readme for C2000 Code Generation Tools v21.6.0.LTS (2024)

Table of Contents

The C2000 CGT v21.6.0.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.

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

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.

Compiler defect reports can be tracked at the Development Tools bug database at:

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

Enumerated type changes

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] 

.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 in v21.6.0.LTS:

Known defects in v21.6.0.LTS: