• State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 21 subscribers
  • Views 3745 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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

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
  • 0 Arm Employee Badge in reply to vix

    Yes, I have definitely seen cases of sbrk being overriden by users, and I don't see any reason why you won't be able to do the same with the __malloc_lock/unlock symbols: i.e. it should be fine.

    Sadly I do not have any advice I can give for FreeRTOS, that is likely a question best asked on some FreeRTOS-related forum.

    Thank you for the link to https://nadler.com. It was a really interesting read! If you have any advice on how we can improve the Arm GNU Toolchain, please let us know any we'll take your feedback on board.