cancel
Showing results for 
Search instead for 
Did you mean: 

How to get printf() float / double support working on F7

Michael B
Associate III

I've been fighting with this too long and can't figure it out. I've added uart communication for use with printf() by implementing the following in syscalls.c:

__attribute__((weak)) int _write(int file, char *ptr, int len)
{
   HAL_StatusTypeDef status = HAL_UART_Transmit(&huart1, (uint8_t *)ptr, len, 0xFFFF);
   return (status == HAL_OK ? len : 0);
}

That works fine with printf. But printing floats or doubles causes it to hang when it tries to output the number. I have enabled -u _printf_float in the MCU Settings of STM32CubeIDE (also tried adding it manually to the Linker flags).

double test = 1.2345;
printf("test: %f\r\n", test);
arm-none-eabi-g++ -o "ProjectTest.elf" @"objects.list"  -l:libtouchgfx-float-abi-hard.a -mcpu=cortex-m7 -T"B:\gitrepo\ProjectTest\STM32F746NGHX_FLASH.ld" --specs=nosys.specs -Wl,-Map="ProjectTest.map" -Wl,--gc-sections -static -L../Middlewares/ST/TouchGFX/touchgfx/lib/core/cortex_m7/gcc --specs=nano.specs -mfpu=fpv5-sp-d16 -mfloat-abi=hard -mthumb -u _printf_float -Wl,--start-group -lc -lm -lstdc++ -lsupc++ -Wl,--end-group

I don't really know how to debug this further, and I've read many relevant posts but nothing I've tried has worked. I really need it to, as the debugger in STM32CubeIDE is a pile of junk and the watcher shows incorrect values for variables.

Also note I'm using FreeRTOS here, not sure if it's an issue with stack alignment or how to debug that.

Help a brutha out?

1 ACCEPTED SOLUTION

Accepted Solutions

@Community member​ - Presuming you're using FreeRTOS or similar (you didn't say), the answer to your problem is most likely here:

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

http://www.nadler.com/embedded/newlibAndFreeRTOS.html

@Markus GIRDLAND​ - This is about one customer per week, no? And that's only the customers that ask on this forum.

Any updates as to when this will be fixed?

Also, I forgot to mention, please mention to your Architecture Team that NXP is shipping the heap_useNewlib I provided on my website with MCUxpresso.

@Community member​ - Please confirm this fixes your problem.

Hope this helps,

Best Regards, Dave

View solution in original post

11 REPLIES 11

@Community member​ - Presuming you're using FreeRTOS or similar (you didn't say), the answer to your problem is most likely here:

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

http://www.nadler.com/embedded/newlibAndFreeRTOS.html

@Markus GIRDLAND​ - This is about one customer per week, no? And that's only the customers that ask on this forum.

Any updates as to when this will be fixed?

Also, I forgot to mention, please mention to your Architecture Team that NXP is shipping the heap_useNewlib I provided on my website with MCUxpresso.

@Community member​ - Please confirm this fixes your problem.

Hope this helps,

Best Regards, Dave

That was fast, I was just adding the bit about FreeRTOS as you responded. I'll take a look at that and see if it helps out, will let you know!

@Dave Nadler​ I see you're about as frustrated with the ST dev teams as I am with the overall lack of action on much needed updates. This very much is the issue I'm encountering as I can repro the same error you outlined. Reviewing your page about it to see how I might go about dealing with a fix

Michael B
Associate III

In a Stack Overflow style effort, I'll post a complete solution here (thanks to @Dave Nadler​ )!

As outlined in this link - it's a newlib problem with task concurrency in FreeRTOS that has yet to be patched, that was poorly implemented by ST, and is generated by CubeMX. Memory corruption occurs when using printf() and likely other things too, see the details on it at that link.

To fix:

  1. Exclude Src/sysmem.c
  2. Exclude Middlewares/Third_Party/Source/portable/MemMang/heap_4.c
  3. Add Src/heap_useNewLib.c (provided at the link above)

As a side note, I have added this to my STM32CubeIDE project patcher (1.0.2) too so you don't need to do this every time you generate code, at least until ST fixes their code.

No update since Monday, no.

It has been given "Critical" status with "Give high attention" priority.

Your website is also linked in the ticket with a reminder to look through it to avoid "a few pitfalls that you can end up in if you select one of the pre-defined heap implementations in FreeRTOS."

I ask you to check an alternative.

https://bitbucket.org/AVI-crak/sprint/src/default/sPrint.c

It should be noted that for simultaneous printing from multiple streams to one physical communication interface, it is necessary to win arbitration of access to this interface. At one point in time, only one thread should be able to use a physical port.

Does ST use an actual bug tracker or ticket system - and if so is it accessible by customers to track reports?

Even if they do use, unfortunately it's not accessible to customers. They are directing customers to this unimaginably crippled forum where most of the information quickly goes off of the first page and is forgotten. Though in last days they seem to be more active in participating and solving reported problems. At least some improvement...

reporting Bugs via this forum is entirely pointless. Time to open source this ****