• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 265 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F280039-Q1: Any guideline can help customer migrate COFF to ELF

Shuqing Zhou
Expert 3705 points

Part Number: TMS320F280039-Q1
Other Parts Discussed in Thread: C2000WARE, SYSCONFIG

Hi team,

I ask this for my customer.

My customer want to migrate COFF project to ELF project.

We follow this: https://software-dl.ti.com/ccs/esd/documents/C2000_c28x_migration_from_coff_to_eabi.html

But something is missing: 

for example, customer need to modify the #pragma DATA_SECTION(TestInfo ,"FixValue ");
const u32 ulTestInfo = 0x11223344 to attribute((retain, section(“FixValue”))) const u32 ulTestInfo = 0x11223344;

If they don't do this, they can't find the variable ulTestInfo in map file.

And although after this change, the storage order of variables in memory is change.

 

But this is not included in the document we provide

could you help to check any other iteams needed to pay attention to in addition to the file: https://software-dl.ti.com/ccs/esd/documents/C2000_c28x_migration_from_coff_to_eabi.html

BRs

Shuqing

  • 0
    TI__Mastermind 36153 points

    Hi Shuqing,

    The F28003x device family (including TMS320F280039-Q1) supports only EABI (ELF) format going forward — COFF is legacy [1]. This means migration is not optional for customers moving to this platform. The Flash API libraries are distributed in both EABI ELF and COFF formats (FlashAPI_F28003x_FPU32_EABI.lib and FlashAPI_F28003x_FPU32_COFF.lib), so the correct library must be selected to match the output format [2].

    Addressing the Specific Issues Raised

    1. #pragma DATA_SECTION → __attribute__((retain, section())) and Map File Visibility

    Your customer's observation is correct and important. In ELF/EABI, the linker performs unused-section elimination by default. Under COFF, all sections were kept regardless of whether they were referenced. In ELF:

    • __attribute__((retain)) is required to prevent the linker from discarding unreferenced symbols. Without it, a const variable placed in a named section but never explicitly referenced in code will be stripped — which is why ulTestInfo disappeared from the map file.
    • __attribute__((section("FixValue"))) replaces the #pragma DATA_SECTION syntax.

    The combined syntax your customer is using is correct:

    __attribute__((retain, section("FixValue"))) const u32 ulTestInfo = 0x11223344;

    2. Memory Storage Order Changes

    Under COFF, variables within a section were typically placed in declaration order. Under ELF, the linker may reorder input sections within an output section. To control ordering in ELF:

    • Use explicit SECTIONS directives in the linker command file with ordered input section specifications
    • Consider using the linker --order option or placing critical variables in separate named sections with explicit placement in the linker command file
    • If exact ordering matters (e.g., for calibration tables or fixed-address structures), use a struct to guarantee layout rather than relying on linker placement order

    Additional Migration Items to Watch Beyond the Official Guide

    Based on common COFF-to-EABI migration pitfalls on C2000, here are items your customer should verify:

    Area
    COFF Behavior
    ELF/EABI Change
    Action Required
    #pragma DATA_SECTION
    Always retained
    May be stripped
    Add __attribute__((retain, section()))
    #pragma CODE_SECTION
    Always retained
    May be stripped
    Add __attribute__((retain, section())) for unreferenced code
    #pragma RETAIN
    N/A
    Needed for unreferenced symbols
    Add __attribute__((retain)) or #pragma RETAIN (EABI supports this pragma)
    Section naming
    Sections prefixed with . optional
    ELF convention uses . prefix
    Verify linker command file section names match
    Initialized variables
    .ebss / .econst
    .bss / .const / .data
    Update linker command file section names
    C initialization
    _c_int00 boot, copy tables
    Different copy table format, --rom_model or --ram_model
    Verify boot/init sequence and linker flags
    Linker command files
    COFF section names
    ELF section names differ
    Rebuild linker .cmd files for ELF sections
    far keyword
    Used in COFF large model
    Not applicable in EABI
    Remove far qualifiers
    Intrinsics / built-ins
    Some COFF-specific
    May have EABI equivalents
    Check compiler release notes
    Flash API library
    FlashAPI_F28003x_FPU32_COFF.lib
    FlashAPI_F28003x_FPU32_EABI.lib
    Swap library file [2]
    GCC extensions
    May not be enabled
    Required for EABI compilation
    Enable "Support for GCC extensions" in compiler settings [2]

    Recommendation

    The official migration guide your customer is following is the primary resource, but it does have gaps as your customer discovered. I would recommend:

    1. File a documentation feedback request with TI to add the retain attribute requirement and memory ordering differences to the official guide
    2. Review the TI C2000 compiler user's guide (SPRU514) for the complete list of pragma-to-attribute mappings
    3. Rebuild the linker command file from scratch using C2000Ware EABI example linker files as a starting template rather than converting the COFF linker file manually
    4. Compare map files section-by-section between the COFF and ELF builds to catch any missing variables or unexpected relocations

    To help refine this recommendation further, it would be helpful to know:

    • The complete list of #pragma directives used in the customer's COFF project (DATA_SECTION, CODE_SECTION, RETAIN, etc.)
    • Whether the customer is using custom linker command files or C2000Ware-provided ones
    • The specific CCS and compiler versions being used
    • Whether the customer relies on specific memory addresses for variables (fixed-address calibration data, bootloader interfaces, etc.)
    • Whether the project uses any assembly files that may need syntax updates for ELF
    1. F28002x to F28003x Migration Guide (SPRUIW4)
    2. F28003x Flash API Reference Guide (SPRUJ27C)

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Expert 3705 points

    Hi Fleenor,

    1. In EABI project, for this function, if customer use pragma to allocate the Timer0IntIsr to .TI.ramfuc, it can successfully

    but for this gwFileInfo, if customer use pragma, it can't be placed in app_file_info section(can be placed in app_file_info section in COFF project using pragma)

    customer need to use attribute to realize their requirement

    Is it must to change all the pragma to attribute when customer migrate COFF to EABI?

    2. Customer use below lib

    Could you give the latest version of these lib and give me the release note for these lib? can't find specific information in C2000ware SDK release note

    3. Is needed to replace the driver source when it migrate from COFF to EABI?

    BRs

    Shuqing

  • 0 in reply to Shuqing Zhou
    TI__Mastermind 36153 points

    Hi Shuqing,

    Addressing your three follow-up questions directly.

    1. Must All #pragma Be Changed to __attribute__ When Migrating to EABI?

    No — not all pragmas must be converted, but the behavior differs between functions and unreferenced data.

    The reason #pragma CODE_SECTION(Timer0IntIsr, ".TI.ramfunc") works is that Timer0IntIsr is an ISR – it's referenced by the interrupt vector table, so the ELF linker doesn't strip it. The pragma successfully places it in .TI.ramfunc because the linker sees it as "used." (See image of code and map file verifying this.)

    However, gwFileInfo (a constant variable placed in a custom section like app_file_info) is not explicitly referenced by other code – it exists for external tools, debuggers, or fixed-address reads. In ELF, the linker’s unused-section elimination strips it silently. That’s why #pragma DATA_SECTION alone fails for this variable, but it works in COFF (where everything was kept regardless). (The images show the conversion from #pragma DATA_SECTION to __attribute__((retain, section("app_file_info"))) for gwFileInfo.)

    The rule is:

    • If a symbol placed via #pragma DATA_SECTION or #pragma CODE_SECTION is referenced elsewhere in the code, the pragma syntax still functions in EABI.
    • If the symbol is unreferenced (calibration data, version info, fixed-address constants), you must add __attribute__((retain, section("..."))) or #pragma RETAIN to prevent stripping.

    Practical recommendation: Audit every #pragma DATA_SECTION in the project and add __attribute__((retain, section("..."))) for any variable that isn't directly referenced in code. For referenced symbols, the pragma syntax still functions, but converting to __attribute__ syntax is the forward-looking best practice for EABI. This adds clarity and can improve future maintainability.

    2. Library Versions and Release Notes

    Based on the image provided, you're using libraries from C2000Ware 6.00.01.00. The file names in the image confirm the availability of both COFF and EABI versions.

    Here's a summary of relevant information:

    • F28003x support (driverlib, bitfield, SysConfig, and libraries) was first added in C2000Ware 4.00.00.00.
    • EABI Flash API libraries for F28003x were added starting in C2000Ware 4.00.00.00, with a Functional Safety Quality Flash API v1.58.10 for F28003x added in 4.02.00.00.
    • IQmath, driverlib, and device libraries are updated with each C2000Ware release
    • Both EABI and COFF library versions are distributed in C2000Ware, and compilation requires "Enable support for GCC extensions" (enabled by default in compiler v6.4.0+).
    • Important: Make sure you are linking the EABI versions of the libraries (e.g., driverlib_eabi.lib, cla2_math_library_eabi.lib, its2800_fpu32_fast_supplement_eabi.lib) to your project, as shown in the provided image.

    The detailed per-library changelogs are embedded within the C2000Ware installation directory rather than the top-level SDK release notes. Look in:

    C2000Ware_x_xx_xx_xx/libraries/flash_api/f28003x/
C2000Ware_x_xx_xx_xx/libraries/math/IQmath/
C2000Ware_x_xx_xx_xx/driverlib/f28003x/


    3. Is Driver Source Replacement Needed for COFF-to-EABI Migration?

    The driverlib source code itself is format-agnostic – it's C source that gets compiled into whichever output format your project targets. You do not need to replace driverlib .c and .h source files when switching from COFF to EABI.

    What does need to change:

    • Pre-built library files (.lib) must be the EABI versions (e.g., driverlib_eabi.lib instead of driverlib_coff.lib).
    • Motor control and InstaSPIN libraries now support both COFF and EABI formats – select the correct variant.
    • Linker command files must be updated to use ELF section names (.bss/.const/.data instead of .ebss/.econst).

    If you're building driverlib from source as part of your project, simply recompiling with EABI settings is sufficient.

    To help refine this further, it would be helpful to know:

    • Whether the project includes assembly files that may need ELF syntax updates.
    • Whether the customer is using custom linker command files or C2000Ware templates. (To assess possible ELF section name changes.)

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Expert 3705 points

    Hi Fleenor,

    1. I want to emphasize again customer isn't use C2000Ware 6.00.01.00, please check for the picture again!!!

    Fleenor said:
    Based on the image provided, you're using libraries from C2000Ware 6.00.01.00.

    2. I can't find these library release note in below path, please check again!!!!

    Fleenor said:
    he detailed per-library changelogs are embedded within the C2000Ware installation directory rather than the top-level SDK release notes.

    3. I just want to know the latest library now we released and these library release note, please answer me directly!!!

    How I can trust you other question's answer??

    BRs

    Shuqing

  • 0 in reply to Shuqing Zhou
    TI__Mastermind 36153 points

    Hi Shuqing,

    1) The pictures you shared show use of C2000Ware 6.00.01.00. 

    Can you help me understand what version is being used then?

    2) Apologies for the previously incorrect reference to changelog details. The associated details can found in the locations below:

    C2000Ware_26_00_00_00\libraries\flash_api\f28003x\docs (Flash API Library specific - See Page 40 of the PDF)

    C2000Ware_26_00_00_00\change_log.html (Detailed changelog with changes/updates across C2000ware)

    3) The latest C2000Ware release will always contain the latest version of the associated libraries, this is always available for download at: 

    https://www.ti.com/tool/C2000WARE/#downloads

    The latest release can be found at:

    https://www.ti.com/tool/download/C2000WARE/26.00.00.00.STS

    I hope this properly addresses your questions.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Shuqing Zhou
    TI__Mastermind 36153 points

    Hi Shuqing,

    I wanted to follow up on our previous discussion regarding the COFF to EABI migration for the TMS320F280039-Q1.

    I hope the information I provided about:

    1. The #pragma vs __attribute__((retain, section())) usage patterns
    2. The C2000Ware library locations and changelogs
    3. Driver source requirements for EABI migration

    ...has been helpful for your customer's migration effort.

    I'd like to check in on a few items:

    • Has your customer been able to successfully complete the migration using the guidance provided?
    • Are there any remaining issues with variable placement, memory ordering, or section elimination that need clarification?
    • Did the customer find the library version information and changelogs in the paths I referenced?

    Regarding the C2000Ware version: I see from the screenshot that the path shows C2000Ware_6.00.01.00. If this is incorrect and a different version is being used, please share the correct version number so I can provide version-specific guidance.

    Additional support: If your customer is still encountering specific technical issues with:

    • Unreferenced symbols being stripped from the map file
    • Memory layout differences between COFF and ELF builds
    • Linker command file section mapping
    • Any assembly file syntax updates needed for ELF

    ...please provide the details and I'll be happy to investigate further.

    I want to ensure your customer has a smooth migration experience. Please let me know the current status or if there are any outstanding blockers.

    Best Regards,

    Zackary Fleenor