The F2837xD/S/07x devices are among the first C2000 device families to support both Common Object File Format (COFF) and Embedded Application Binary Interface (EABI). Refer https://software-dl.ti.com/C2000/docs/optimization_guide/phase1/index.html#application-binary-interface-abi for more information. EABI overcomes several limitations of COFF, which includes the symbolic debugging information not being capable of supporting C/C++, and the limit on the maximum number of sections and length of section names and source files. Note that EABI and COFF are not compatible and conversion between the two formats is not possible. The following is a brief summary of EABI differences compared to COFF.

• Direct initialization
  • Uninitialized data is zero by default in EABI.
  • Initialization of RW data is accomplished via linker-generated compressed copy tables in EABI.
• C++ language support
  • C++ inline function semantics: In COFF, inline functions are treated as static inline and this causes issues for functions that cannot be inlined or have static data. In EABI, inline functions without the ‘static’ qualifier have external linkage.
  • Better template instantiation: COFF uses a method called late template instantiation and EABI uses early template instantiation. Late template instantiation can run into issues with library code and can result in long link times. Early instantiation uses ELF COMDAT to guarantee templates are always instantiated properly and at most one version of each instantiation is present in the final executable.
  • Table-Driven Exception Handling (TDEH): Almost zero impact on code performance as opposed to COFF which uses setjmp/longjmp to implement C++ exceptions Features enabled by EABI.
• Features enabled by EABI
  • Location attribute: Specify the run-time address of a symbol in C-source code.
  • Noinit/persistent attribute: Specify if a symbol should not be initialized during C auto initialization.
  • Weak attribute: Weak symbol definitions are pre-empted by strong definitions. Weak symbol references are not required to be resolved at link time. Unresolved weak symbols resolve to 0.
  • External aliases: In COFF, the compiler will make A an alias to B if all calls to A can be replaced with B. A and B must be defined in the same file. In EABI, the compiler will make A an alias to B even if B is external.
• Calling convention
  • Scalar calling convention is identical between COFF and EABI.
  • Struct calling convention (EABI):
    • Single field structs are passed/returned by value corresponding to the underlying scalar types.
    • For FPU32, homogenous float structs with size less than 128 bits will be passed by value.
    • Passed in R0H-R3H, then by value on the stack.
    • Structs that are passed by value are also candidates for register allocation.
    • For FPU64, the same applies for 64-bit doubles (R0-R3).
• Double memory size
  • In EABI, double is 64-bit size while in COFF, double is still represented as 32-bit size.
  • C/C++ requires that double be able to represent integer types with at least 10 decimal digits, which effectively requires 64-bit double precision.

Table 3-1 summarizes the compiler-generated section names used by COFF and EABI.

For more information about EABI and the migration process, see the following reference guides:

• TMS320C28x AssemblyLanguage Tools User’s Guide
• TMS320C28x OptimizingC/C++ Compiler User’s Guide
• C2000Migration from COFF to EABI https://software-dl.ti.com/ccs/esd/documents/C2000_c28x_migration_from_coff_to_eabi.html