• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 22 subscribers
  • Views 2938 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

sprintf() function behaving strange...

henk van winkoop

Hi,

I'm using uVision IDE V4.53.0.0 and the sprintf() function behaves strange... my piece of code:

_disable_irq();

len = sprintf((char*)myBuf,"%+2.2fV  %+1.3fA",9.13788,-0.004069);

_enable_irq();

This will create a string in myBuf:

"+9.14V -0.004A"

This code is called each 500ms. Suddenly after a minute or so it generates:

"-7265617330774872000000/0/0000000.000000000/0/000000000.00V +17574296777337024000/0/0000.000A"

where /0/ stands for "about 40 zero's"

Also 'len' contains a value of 66 (in stead of 15) which is the position of the first '.' in the resulting string.

As all interrupts are disabled the variables cannot be overwritten by some interrupt handler.

Does anybody know?

Thanks,

Henk

Parents Reply Children
  • 0 in reply to Andy Neil

    Hi,

    I increased the stack by 512 Bytes but the problem still exists.

    I modified the code in such a way that when the conversion fails it immediately re-executes the sprintf() function. But it still returns the same erroneous string.

    The only cause I can think of is that the sprintf() function declares some static variables which are used for conversion and that my program somehow overwrites one or more of these static variables.

    So for now I quit using sprintf() for float values and I did write my own conversion function which runs solid as a rock.

    Thanks,

    Henk

  • 0 in reply to henk van winkoop

    Maybe 512 wasn't enough...?

    A simple way to catch a stack overflow is to put a data-access breakpoint just beyond the "expected" end of the stack; then, if that breakpoint ever "fires", you know you've got an overflow.

  • 0 in reply to Andy Neil

    A simple way to catch a stack overflow is to put a data-access breakpoint just beyond the "expected" end of the stack; then, if that breakpoint ever "fires", you know you've got an overflow.

    Except, of course, if the stack overflows by a giant leap right across your trap, instead of walking nice and slowly into it...