sprintf %f not working ?!?

paolo239955_stm1 · ‎2009-05-10

Posted on May 10, 2009 at 10:21

paolo239955_stm1 · ‎2011-05-17

Posted on May 17, 2011 at 09:58

Hi all,

I am in big trouble with my app, EWARM 5.20 + uC/OS II. I have a task writing a floating on an output buffer, like this:

char outval[16];

float me->INval__ = 123.456;

sprintf (outval, ''%f'', me->INval__);

well, sprintf writes randomly ''0.000'' or ''-nan'' (or other garbage) to outval buffer.

I stepped thru all the (s)printf assembler to check the stack pointer, it stays inside his bounds. I tried changing from ARM mode to THUMB mode, no relief. The strangest thing of all, if I put a simple sprintf loop in main task without creating any other task sprintf woks well. Something to do with task switching ?

I am desperate , please help !

mark9 · ‎2011-05-17

Posted on May 17, 2011 at 09:58

I believe that printf etc are not thread safe by default. If you are using IAR, you need to recompile DLIB with locks.

Otherwise, it sounds like you might have a local stack pointer that is being accessed outside of the scope of the local function, i.e.

float* foo() {

float local = 123.456;

return &local;

}

is bad. If you try dereference *foo(), you will get junk, not 123.456. Or you should check to make sure all your stacks are big enough, since it smells like stack corruption.

sr_shinde · ‎2011-05-17

Posted on May 17, 2011 at 09:58

Hi all,

verify the C standard that is being used by compiler.

Make it C99.

Regards

Sai

hoyen · ‎2011-05-17

Posted on May 17, 2011 at 09:58

Hi,

I don't know your compiler (but i'm fairly sure this compiler use a GCC toolchain) but according to my previous experience with GCC and libraries provided with it by default (NewLib):

The Float support for sprintf, vsprintf family... also scanf... IS NOT INCLUDED and COMPILED inside the library.

The library has been built to be CPU-Memory light, according to the embedded word with tiny processor.

Plenty of people dis-encourage use of float in a embedded project...

If you are still using float,

and if my memory is good, have a look to:

http://www.codesourcery.com/sgpp/lite/arm

This GNU Tools chain should support float with printf by default(to be confirmed)

or

Recompile the Newlib library.

Regards.

Damien HOYEN

jomedfree · ‎2011-05-17

Posted on May 17, 2011 at 09:58

I also faced a lot of trouble trying different GCC tool chains with printf float in the past 12 months.

From now (I haven't check the last march'09 version of Yagarto), the only tool chain that exhibits nice behavior with float and printf/sprintf is Idealist from Anglia. But I am not a GCC expert in order to tell you why this toolchain works...

In the past, I was using 8 bits 8051 ÂµC family with Keil compiler, everything was fully C compliant with float/printf support, it only takes something like 20k to support it on this ''prehistoric'' 8 bits ÂµC instead of something close to 40k on...32 bits up to date machine (if someone get a clear explanation, he will be welcome).

Good luke for your job.

grheard · ‎2011-05-17

Posted on May 17, 2011 at 09:58

Quote:

On 09-04-2009 at 15:52, Anonymous wrote:

Hi all,

I am in big trouble with my app, EWARM 5.20 + uC/OS II. I have a task writing a floating on an output buffer, like this:

char outval[16];

float me->INval__ = 123.456;

sprintf (outval, ''%f'', me->INval__);

well, sprintf writes randomly ''0.000'' or ''-nan'' (or other garbage) to outval buffer.

I stepped thru all the (s)printf assembler to check the stack pointer, it stays inside his bounds. I tried changing from ARM mode to THUMB mode, no relief. The strangest thing of all, if I put a simple sprintf loop in main task without creating any other task sprintf woks well. Something to do with task switching ?

I just started experiencing this exact same issue. Mine is with IAR v5.30 uC/OS-II v2.88 on an STM32F103 Cortex-M3 microcontroller. sprintf works fine if used in main before invoking OSStart(). Upon entering the ''start task'', sprintf no longer works. Understand that there is no task switching going on as the system only has this 1 high priority task. Also, IAR's documentation declares that the sprintf varieties are reentrant safe. I'm very perplexed, this was working fine a day or two ago with all 10 system tasks running. The oddity is that only the float conversions are affected. All other number conversions continue to operate normally. Very strange.

hoyen · ‎2011-05-17

Posted on May 17, 2011 at 09:58

Hi all,

Just a things:

When you use a printf() function, keep in mind this function will use a huge quantity of stack, something like 2K of RAM, if my memory is good. Always provide a huge stack for each thread calling a printf() fonction.

Regards.

damien Hoyen