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.

CCS 5.5 vs CCS 6 GCC toolchain problem? -- (s)printf won't print floats

UPDATE:

I have two configurations of the same project, both under CCS5.5, but one configuration uses gcc 4.7.3 from CCSv5 path and the alternate configuration uses gcc 4.7.4 from the CCS6 installation path.

Executable compiles fine in both configurations but the executable built with 4.7.4 will not (s)printf floats.

My understanding would be that newlib's printf was compiled without float support.

I am attaching an example project with the two alternate configurations.

Has the floating point support for printf been omitted by mistake?

Argiris

[original message follows]

Hi all,

I have been using CCS5.5 to develop a small project with TM4C123B and recently I installed the newer CCS6 on another computer. I moved my source files to a new project on the new CCS6 and I seem to be missing something, because my sprintf calls format floating point arguments as garbage.

Both projects use GCC that is bundled in the CCS, but CCS5.5 uses an older release of GCC. All project settings seem the same (hard floating point, same optimization level -- tried all options without any change --, same libraries (I'm using the math library "-lm" in addition to the default ones).

An example of the code is below. The sprintf fills the buffer lcdstr with "Set: 0.00V" on the first execution (correctly) on both compilers.

When using the new Linaro compiler from CCS6, the buffer on the next loop iteration becomes "Set:8.AV" while on the old toolchain it works just fine ("Set:10.00V").

It has to be something different in the compiler, but what...? I tried turning off the optimizer but there was no change.

Any ideas please???


#include <stdint.h> #include <stdio.h> char lcdstr[40]; //scratchpad int Test_AnodeVolts(int c) { float V=0; float stepf=10; int i; while(1){ if (Key_hit()) break; sprintf(lcdstr,"Set:%0.2fV",V);// <===== this line prints the floating point argument as garbage SetVolts( V ); LCD_DispStrCentered(1, lcdstr); V+=stepf; if (V>400-10) stepf=-10; if (V<0+10) stepf=+10; for (i=0; i<16; i++){ [do some stuff] } Delay_ms(500); } }

Edit:

I tried to increase the stack size in case printf would overrun it  (with no luck) -- mainly because of the following observation:

Another point that seems different from CCS5.5 to CCS6, is that when debugging and stopped on a breakpoint the call stack displays a lot more call frames than it should. There are interspersed stack frames pointing to "_fini()" at 0xfffffffe .. Where the debugger shouldn't go, at least because it's unaligned and I'm using plain C, not C++ which would need destructors to run. Am I doing something wrong or the libc is missing something?

example.zip
  • Please see the update information and project demonstrating the problem.

  • Hi,

    I am sorry, I think this thread went under our radar screen.

    I am able to reproduce this issue but unfortunately the maintainer of the GCC toolchain cannot (I posted this question at the Launchpad forum), and I am unsure where the problem resides. Perhaps a side-by-side assembly comparison would need to be done, but I am not very well versed in CortexM assembly.

    In the meantime, where you able to find out the root cause for this issue or any additional behavior that could shed some additional light to the problem?

    Regards,

    Rafael

  • Thank you for looking into this.

    I do not have much other details. I know it is the same regardless of the optimization level used.

    I noted that the gcc maintainer tested with 4.8 version, which is newer and the difference may be gone?

    Regarding the assembly comparison:

    I did a dump of both executables (with 4.7.3 and 4.7.4) and the only meaningful difference is at _sbrk(). Look at the end of the dump files attached. It seems that _sbrk() is different. sprintf accesses some areas after the end of _sbrk().


    If there are (or should be) initialized data up there, then this could (?) be the cause.

    I cannot look into it immediately, but will do so at first convenience.

    Meanwhile, please let me know if you have any further suggestions.

    Argiris

    dumps.ZIP