• State Not Answered
  • Replies 4 replies
  • Subscribers 19 subscribers
  • Views 848 views
  • Users 0 members are here
Options
Related
How was your experience today?

ARM GNU Toolchain 13.2Rel1 newlib issue with sprintf and floating point

vix

I need to use sprintf with floating point numbers (%f format specifier) in a project based on rpmsg_lite_str_echo_rtos on the cortex-M (NXP Processor).
I use the recommended arm-gnu-toolchain-12.3.rel1-mingw-w64-i686-arm-none-eabi
I see that when I call

sprintf(str, "%d" 3);

the number 3 is printed to the string str.

But if I have a floating point number and I use "%f" format specifier

sprintf(str, "%f" 3.5);

I get
ASSERT ERROR " Balloc succeeded ": file "/data/jenkins/workspace/GNU-toolchain/arm-12/src/newlib-cygwin/newlib/libc/stdlib/mprec.c" Line "783" function name ""

It seems similar to this error
forum.pjrc.com/index.php
that points to this fix
github.com/.../f88aece242178ff0c187d56e34a79645fbc44a23

Is there a way to have sprintf working with floating point numbers?

Parents
  • 0 in reply to Stam Markianos-Wright

    Hi  

    thanks for your answer.

    You're right and newlib-nano doesn't contain floating point support.

    With --specs=nano.specs floating point numbers ar enot printed at all (I imagine the printing function is expanded to "do nothing").

    This is the reason why I removed the --specs=nano.specs option (as suggested here https://community.toradex.com/t/enable-floating-point-support-sprintf/8035/3)

    But after I remove  --specs=nano.specs to use the standard newlib, I see the Balloc error.

    The error comes at runtime (i.e., during execution), and it doesn't  matter if the str is on the stack, or on the heap.

    I use FreeRTOS, and after a lot of investigation, I think that the issue comes from here

    https://nadler.com/embedded/NXP_newlibAndFreeRTOS.html

    This is for NXP uP, but the behavior is general: newlib is not threadsafe by default, and a lot of attention must me used when using it with FreeRTOS.

    Can you confirm that in the toolchain newlib allows to reimplement the following hooks?

    sbrk, __malloc_lock/unlock

    Do you have suggestions on how to implement the under FreeRTOS?

Reply
  • 0 in reply to Stam Markianos-Wright

    Hi  

    thanks for your answer.

    You're right and newlib-nano doesn't contain floating point support.

    With --specs=nano.specs floating point numbers ar enot printed at all (I imagine the printing function is expanded to "do nothing").

    This is the reason why I removed the --specs=nano.specs option (as suggested here https://community.toradex.com/t/enable-floating-point-support-sprintf/8035/3)

    But after I remove  --specs=nano.specs to use the standard newlib, I see the Balloc error.

    The error comes at runtime (i.e., during execution), and it doesn't  matter if the str is on the stack, or on the heap.

    I use FreeRTOS, and after a lot of investigation, I think that the issue comes from here

    https://nadler.com/embedded/NXP_newlibAndFreeRTOS.html

    This is for NXP uP, but the behavior is general: newlib is not threadsafe by default, and a lot of attention must me used when using it with FreeRTOS.

    Can you confirm that in the toolchain newlib allows to reimplement the following hooks?

    sbrk, __malloc_lock/unlock

    Do you have suggestions on how to implement the under FreeRTOS?

Children
No data