• State Not Answered
  • Replies 4 replies
  • Subscribers 19 subscribers
  • Views 840 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?

  • 0

    Sorry for pushing, but no news idea on what happens here with nanolib?

  • 0
    Hi there,

    I haven't been able to replicate this on my side, yet (compiling for a Cortex-M0 and running on a FastModel).

    Is this with --specs=nano.specs? I believe newlib-nano does not contain floating-point support out-of-the-box. You can include some limited support by manually pulling in two symbols. You can do this by adding `-u _scanf_float -u _printf_float` to your command line, but if you are planning on using floating-point numbers more than just printf/scanf, you would be better off switching to the standard newlib (i.e.: remove --specs=nano.specs from your command line and the compiler will link with the standard newlib instead)

    If that doesn't help your situation, are you able to share more information on:
    * Does that error happen when actually running the code on the target, or at compile-time?
    * How have you defined the "str" pointer here? Is global or local, or is it malloc-ed on the heap?
    * What is your full compiler command line when you are seeing this issue?

    With those I should be able to replicate your issue to investigate further

    Thank you,
    Stam
  • 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?

  • 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?