Skip to main content
KWuer
KWuer
Associate II
April 29, 2019
Question

CubeIDE sprintf does not work with %f

  • April 29, 2019
  • 5 replies
  • 13635 views

When I create a new project and put in "-u _printf_float"  as linker option and select "Use float with printf from newlib-nano (-u _printf_float) then sprintf does not convert float values.

but when I import a TrueStudio project where sprintf works with floats, then it works also in CubeIDE. What did I miss?

Compiler Settings:

-mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DSTM32F446xx -DDEBUG -c -I../Inc -I../Drivers/CMSIS/Include -I../Drivers/STM32F4xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F4xx/Include -I../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb

Linker settings:

-mcpu=cortex-m4 -T"D:\HiDrive\STM32\workspace_1.0.0\printf\STM32F446RETX_FLASH.ld" --specs=nosys.specs -Wl,-Map="${ProjName}.map" -Wl,--gc-sections -static -u _printf_float --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -u _printf_float -Wl,--start-group -lc -lm -Wl,--end-group

This topic has been closed for replies.

5 replies

KWuer
KWuerAuthor
Associate II
April 29, 2019

It looks like that I found the problem. The linkersript is wrong. The value _estack = 0x2001ffff; should be point one byte after the stack _estack = 0x20020000;

Then snprintf works again.

See also: https://stackoverflow.com/questions/28746062/snprintf-prints-garbage-floats-with-newlib-nano

Tesla DeLorean
Tesla DeLorean
Guru
April 29, 2019

>>The value _estack = 0x2001ffff;

I can't believe that continues to permeate

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
GStra.1
GStra.1
Associate
February 19, 2020

I'm experiencing the same problems using

STm32cubeide Version: 1.2.1 with Nucleo-F446RE.

My printf works with strings and integers but crashes

my microcontrollor when i try to print floats.

You have said that the mistake is in linker file definition

_estack.

In my link file i read:

/* Highest address of the user mode stack */

_estack = ORIGIN(RAM) + LENGTH(RAM); /* end of "RAM" Ram type memory */

_Min_Heap_Size = 0x200; /* required amount of heap */

_Min_Stack_Size = 0x400; /* required amount of stack */

/* Memories definition */

MEMORY

{

 RAM  (xrw)  : ORIGIN = 0x20000000, LENGTH = 128K

 FLASH  (rx)  : ORIGIN = 0x8000000, LENGTH = 512K

}

What do you think?

G.

Piranha
Piranha
Principal III
February 19, 2020

Your _estack is OK. Look for soft/hard floating point compiler configuration and this:

https://community.st.com/s/question/0D50X0000BB1eL7SQJ/bug-cubemx-freertos-projects-corrupt-memory

GStra.1
GStra.1
Associate
February 19, 2020

Below my compiler configuration:

-ffunction-sections -fdata-sections -Wall -fstack-usage --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb

Is it not enough?

Ml.1
Ml.1
Associate
October 26, 2020

Hello,

I am using STM32F429VE microcontroller with stm32cube ide and I have the same problem, but I can not get fix it yet. I tried both:

*change _estack definition in linker file.

*add "-u _printf_float" as linker option

I attach both images. What is wrong?

Thanks!

RaphyLoulou
RaphyLoulou
Associate
November 13, 2020

Hello,

I read many topics dealing with the issue concerning float and sprintf, which I have on my CubeIDE project with STM32G474 microcontroller.

_estack definition in the linker file is good: _estack = ORIGIN(RAM) + LENGTH(RAM);

and project option are correct as mentionned previously.

The workaround that correct this issue is simply to remove the _sbrk function definition that can be found within sysmem.c file. It seems to get in conflict with memory management scheme used by FreeRTOS, even if I don't have the exact explanation.

Good luck!

hs2
hs2
Visitor II
November 14, 2020

Here is an explanation for the heap issues.

RaphyLoulou
RaphyLoulou
Associate
November 16, 2020

Well, thank you for the explanation's link. This is very interesting to learn, and lead me to review the memory management options set within CubeIDE project. This had more impacts than I expected but works well if you correctly follow the implementation suggested by DRNadler. Nevertheless this doesn't explain why simply removing the faulty _sbrk function works (but maybe doesn't works well, in fact I can't find the function that could be called instead...).

Terms & ConditionsAccessibility statement