• State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 20 subscribers
  • Views 1918 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

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 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.

Reply
  • 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.

Children
No data