Hi Forum! I have a simple blink LED task running @100ms. I have a printf that outputs float values( via a semaphore) when the UART rx interrupt sees a n.

printf( "%0.1f|%0.1frn", value1, value2);

The code works for a few iterations, parsing commands and sending correct values out and then goes to a hardfault. if I remove the float values above and replace it with uint_16, it works ok.

Notes: - I'm using FreeRTOS 8.1.2. - FreeRTOS configs are generated by CubeMX. - Heap2 in use.

Thanks. Any help is appreciated.

Most printf are NOT Rtos safe

Are you calling printf() from inside the interrupt? If so, that is definitely a bad idea.

Does printing floats work in a task? If not, then check the printf() configuration in the project options as in IAR you can select how much functionality printf() has.

The only time in the past where printing floats has been a problem is when the stack is only 4 bytes aligned, rather than 8. The tasks do have 8 byte aligned stacks, so another potential issue would be that the stack used by interrupts (which is the same as that used by main()) is only 4 rather than 8 byte aligned. That stack is set up by the tools.

Regards.

Thanks for the response, RTE.

I'm not running printf in an interrupt. A separate task pends/waits on a semaphore to parse data. That semaphore is only posted when a n is received on the receive interrupt.

The IAR icf file which defines the alignment is already at 8. I know FreeRTOS also has an alignment of 8. define block CSTACK with alignment = 8, size = ICFEDITsizecstack { }; define block HEAP with alignment = 8, size = ICFEDITsizeheap { };

Any more suggestions RTE?

It is likely floating point will use more stack. Do you have stack overflow detection turned on? http://www.freertos.org/Stacks-and-stack-overflow-checking.html

Although it could be a fault inside the library function occurs before the kernel has a chance to check the stack, so you could just try doubling the stack size used by that task as a test.