• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 490 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.

Tivaware software much bigger. Is it normal?

Leonardo B
Prodigy 170 points
Other Parts Discussed in Thread: TM4C1294NCPDT

Hello,


I am porting the software from a CortexM3 LM3S (using StellarisWare), to a Cortex M4 TM4C1294ncpdt (TivaWare), using GCC with -Os directive.

I have only replaced a LIB_DIRECTORY variable from 'StellarisWare' to 'TivaWare', then I replaced the old functions/defines with the correspondent new ones and then changed the uC pins to adapt the new PCB.

Then I compiled it,  and got the final HEX file.

There I found some interesting (bad) effect: The Hex file size grown from 5kB to 32kB.

After some tests, I have found that by copying the function's content to my code instead of using it from the lib, I  save a lot of space.


After some modifications, I got a simple example that explain what is happening:

If I compile the code with a "var = MAP_SysCtlClockGet();", the HEX file size is 18468 bytes.

If I just replace this single command with "var = 12000;", the HEX file size goes down to 4203 bytes.

(after the command, i just use 'var' to make some delay routines.)

This same problem happens with many other functions on the lib.


Is this 'normal' ?

Am I missing something?

Thank you.

  • 0
    TI__Guru**** 244400 points

    Hello Leonardo,

    The MAP function uses the ROM version if it is available and the define TARGET_IS_TM4C129_RAx (x is the version of the device namely 1,2 or 3) is put during compile time.

    If the ROM version is not available or the define is not put, then it will map the function to Flash causing an increase in code size.,

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 170 points

    Hello Amit,

    I understand that part, but it seem that if I need to use one function from the lib, the whole object is being included on final binary.

    In the example, by just using "MAP_SysCtlClockGet" I am including the whole sysctl.o, and no optimization is being done to 'remove' from binary the unused functions/data. (I am using -Os directive on GCC).

    As I said, if I copy the function contents directly to my code, the final HEX stays little.

    I am not really sure what am I missing. Do I need to add any option/directive to make this optimization? Or do I need to make a new lib with only the needed functions inside it, so it stays little?

    The GCC option "--gc-sections" don't appear to be reducing the code size.

    Thank you,

  • 0 in reply to Leonardo B
    TI__Guru**** 244400 points

    Hello Leonardo,

    Is this in CCS environment or is it standalone GCC compiler.

    Can you please send the options for compiler and linker that you are using?

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 170 points

    Hello Amit,

    Thank you for your help!

    I have already solved the problem.

    It seems the "--gc-sections" option was wrongly used. When I fixed this problem, it started to work.

    Then ALL sections were considered "unused" and the final Hex file size was 32bytes.

    Then I add the option -uFirstFunction to the linker (where FirstFunction is a defined function). It causes this function (and all function called by it) to be marked as 'used', so the final binary can be made.

    The final HEX file size was around 6kB, which is way better than before.

    But I still think the "-uFunction" option is like a hack being done. Do you know if there is a better way to point this to the compiler? (it's already as the "Reset Handler" on section _vector)

    (I am using standalone GCC: arm-none-eabi-gcc, version 4.9.1, binutils 2.24 )

    Thank you!

  • 0 in reply to Amit Ashara
    Prodigy 170 points

    Hello Amit,

    In fact, the option compiled with --gc-sections and -uFunction doesn't seem to work (compiles fine, but don't run on uC).

    The same code, compiled without these parameters, runs fine on our uC.

    Probably the -u option may not be the right solution.

    What do you suggest?

    Thank you!

  • 0 in reply to Leonardo B
    TI__Guru**** 244400 points

    Hello Leonardo,,

    That is why I asked for the compile and linker switches. I need to see what all is being used.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 170 points

    Hello Amit,


    Sorry for the delay.


    I could solve this problem.

    It seems the right way to do it is to input the -eVector option to the linker, where "Vector" is the address to the interrupt vector. Now it's working.

    Thank you!

  • 0 in reply to Leonardo B
    TI__Guru**** 244400 points

    Hello Leonardo,

    Thank you for bringing this back to the forum. Might I as well ask for a snapshot of how the the compile and link switches come up. Would be a good reference check for people who may end up with the same issue.

    Regards

    Amit