double/float problem with *printf

flashyarm wrote on Friday, April 22, 2011:

Dear FreeRTOS people,

Ive been messing around with an annoying problem in FreeRTOS and after few hours of testing, google searching i still cant resolve my problem. I am currently developing on a LM3S6965 Ethernet Eval Board.

In my project its necessary to use float and double but i cant seem to get it right.

INT8U buffer[50];
float value = 123.45;
sprintf(buffer, "%3.2f", value);

When following code has been executed the buffer still remains 0x00 in all fields. Although normal integers does work with sprintf.

The interesting part of my config looks like following:

#define configUSE_PREEMPTION		1
#define configUSE_IDLE_HOOK			0
#define configUSE_TICK_HOOK			0
#define configCPU_CLOCK_HZ			( ( unsigned portLONG ) 50000000 )
#define configTICK_RATE_HZ			( ( portTickType ) 100 )
#define configMINIMAL_STACK_SIZE	( ( unsigned portSHORT ) 40 )
#define configTOTAL_HEAP_SIZE		( ( size_t ) ( 2400 ) )
#define configMAX_TASK_NAME_LEN		( 12 )
#define configUSE_TRACE_FACILITY	0
#define configUSE_16_BIT_TICKS		0
#define configIDLE_SHOULD_YIELD		0
#define configUSE_CO_ROUTINES 		0
#define configUSE_MUTEXES			1

And my portmacro.h

/* Architecture specifics. */
#define portSTACK_GROWTH			( -1 )
#define portTICK_RATE_MS			( ( portTickType ) 1000 / configTICK_RATE_HZ )		
#define portBYTE_ALIGNMENT			8

Basically it does not function in any way by using float or double.

Is it a hardware restriction or have a simply overseen something?

Thanks in advance.

rtel wrote on Friday, April 22, 2011:

Many of the standard FreeRTOS demos include a tiny printf()/sprintf() implementation that is contained in a file called printf-stdarg.c.  Are you including this file in your build, because it does not include floating point support.  If you are including it, simply remove it to fall back to the default compiler provided library version, and then it should work (but will also take a lot more stack space to execute).


flashyarm wrote on Friday, April 22, 2011:

Thanks for the quick reply richardbarry.

I am using a template from Code Red and as far as i can see in the directory theres no such file as printf-stdarg.c

flashyarm wrote on Saturday, April 23, 2011:

Unfortunately the problem was not solved, but i found another solution.

oahmad2 wrote on Friday, May 20, 2011:

Do you mind sharing your solution.  I was having the exact same issue and I saw this post.  I’m curious as to how you solved it.

flash86 wrote on Friday, April 13, 2012:

Dear freeRTOS Team!

I am facing the exact same problem with my STM32F4. I am using the same settings like flashyarm. I found that this problem only occures when using the port.c for the Cortex M4F with FPU support activated. when using the M3 port ( no FPU support) it is working well. However internally the floating point calculations seem to be right, because when i cast them to int and then call printf() the values are right. Is there any solution to this?

@flashyarm could you please be so kind to share your solution with us?


rtel wrote on Friday, April 13, 2012:

Some of these problems were caused by stack alignment issues with 8 byte data types.  The Cortex-M4F code is new, so could potentially have the same problem, but there are safeguards in the code now that should prevent it.  Put a break point on entry to a task (before the variable declarations), and look at the stack pointer value when the break point is hit - is it eight byte aligned?


flash86 wrote on Friday, April 13, 2012:

Thanks richardbarry for your quick reply!

You’re right it is not byte-aligned - The stack pointer value modulo 8 gives 4 rest.
How can I fix this?


rtel wrote on Friday, April 13, 2012:

Hmm.  Which FreeRTOS version are you using, and are you using the official FreeRTOS CM4F code?  If it is official code you should see something like this in the IAR CM4F port.c file:

portSTACK_TYPE *pxPortInitialiseStack( portSTACK_TYPE *pxTopOfStack, pdTASK_CODE pxCode, void *pvParameters )
	/* Simulate the stack frame as it would be created by a context switch
	interrupt. */
	/* Offset added to account for the way the MCU uses the stack on entry/exit
	of interrupts, and to ensure alignment. */
	pxTopOfStack -= 2;

That line of code should have taken care of your problem, but may need more or less subtracting from it.  I can look at this when I have some CM4F hardware with me.


flash86 wrote on Friday, April 13, 2012:

Hi richardbarry!
thanks for your answer!

I am using the latest freertos V7.1.0 but I am using the RVDS port.c for KEIL. Changing the value of pxTopOfStack does not take any effect. Any Ideas?

Thanks for your effort!

rtel wrote on Friday, April 13, 2012:

Please try the following.

In FreeRTOS/Source/Portable/RVDS/ARM_CM3/portmarco.h, add the following line:

#define portALIGNMENT_ASSERT_pxCurrentTCB ( void )

then, in FreeRTOS/Source/Portable/RVDS/ARM_CM3/port.c, change the first line in pxPortInitialiseStack() from

pxTopOfStack -= 2;


pxTopOfStack -= 1;

and let me know if that fixes the problem of printing floating point numbers. 

Thanks and regards.

flash86 wrote on Saturday, April 14, 2012:

You’re great!

This fixes my Problem, now it’s working just fine!

Thank you!