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

Kernel
1

bluehash wrote on Tuesday, July 14, 2015:

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.1f\r\n”, 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.

2

tlafleur wrote on Tuesday, July 14, 2015:

Most printf are NOT Rtos safe

3

rtel wrote on Wednesday, July 15, 2015:

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.

4

bluehash wrote on Wednesday, July 15, 2015:

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 = ICFEDIT_size_cstack { };
define block HEAP with alignment = 8, size = ICFEDIT_size_heap { };

Any more suggestions RTE?

5

rtel wrote on Wednesday, July 15, 2015:

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.