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.

TMS320F28335: EABI Flash28335_API_V210.lib for F28335.

Part Number: TMS320F28335


We are having trouble with the Flash28335_API_V210.lib. We are using EABI libraries in our current project and now we need to Erase, Program, and Verify flash sectors from the MCU. The Flash28335_API_V210.lib contains COFF objects. Does TI have an EABI version of the Flash28335_API_V210.lib? If not, is there a workaround to perform those operations over the MCU flash memory?

warning: library "../Flash28335_API_V210.lib" contains TI-COFF object files
   which are incompatible with the ELF output file.  Ensure you are using the
   proper library.
   
...

"../F28335.cmd", line 324: warning: no matching section
	-lFlash28335_API_V210.lib(.econst)
"../F28335.cmd", line 325: warning: no matching section
	-lFlash28335_API_V210.lib(.text)
 
 undefined        first referenced
  symbol              in file     
 ---------        ----------------
 Flash28335_Erase ./main.obj
 
 error: unresolved symbols remain

  • Wilson,

    We do not have EABI supported flash API library for this device.  There isn't an option here other than to stick to coff based object for the project itself. 

    I'd like to understand this a bit more, is there a specific reason you need to go with EABI on the F28335?  This device pre-dates the switch over that we made from COFF to EABI significantly, so there was no anticipated support.

    Is there a feature you need in EABI that is not supported in COFF?  We can see if there is an alternative in the COFF based tools.

    Also, I'm assuming there is need to embed the API in your project, maybe for in the field erase/program?  If there is no update support required, the the flash API doesn't necessarily need to be included in the build.

    Best,

    Matthew

  • Matthew,

    Thanks for your response. Currently, we are using in our project the following libraries:
    rts2800_fpu32_eabi.lib

    rts2800_fpu32_fast_supplement_eabi.lib

    IQmath_fpu32_eabi.lib

    The last two have their COFF version, but not the first one. I have not dived deep into the pros and cons of EABI vs COFF. Our main concern is the execution time of the critic code since we are running an ISR at 50 KHz.

    We are implementing a custom bootloader (the current one in our system with other C2000 devices) to update our system in the field, so we need to be able to erase/program the MCU.

    I would appreciate any advice.

  • Wilson,

    Thanks for the update, after looking at this on my own install I believe the naming convention of our files is causing the issue here.

    Before we added EABI support, COFF was the only option we had in C2000, so those files did not have a "COFF" tag in the filename.  This is the issue with rts2800_fpu32_eabi file.  Its COFF counterpart is simply rts2800_fpu32.lib.  You should see this in the same dir as the EABI version you referenced above.

    It looks like at some point we started adding the "_coff" file label to some of the libs(the rts2800_fpu32_fast_supplement_eabi.lib is a good example), but I have older version of our tools that predate EABI, where even for that file there is no _coff.

    I'll look into why we did this for some files but not the main rts2800_fpu32.lib, but in the meantime you should be able to use this, along with the other coff based .libs to make the flash api work.

    Just an aside, one of the bigger changes that I'm aware between coff and eabi is that by default eabi initializes all variables where coff did not.  I've seen customers have longer start up time with eabi until they set the compile switch to disable this feature(coff doesn't do this by default).  Depending on how you've set up your eabi based projects you may see the coff be better in terms of startup time due to this.

    Best,

    Matthew