STM32L1 M3 + IAR printf float crashes FreeRTOS – alignment looks ok @8

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.

STM32L1 M3 + IAR printf float crashes FreeRTOS – alignment looks ok @8

Most printf are NOT Rtos safe

STM32L1 M3 + IAR printf float crashes FreeRTOS – alignment looks ok @8

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.

STM32L1 M3 + IAR printf float crashes FreeRTOS – alignment looks ok @8

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?

STM32L1 M3 + IAR printf float crashes FreeRTOS – alignment looks ok @8

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.