Printf Float in Interrupt Service Routine gives wrong values.

pixt wrote on Monday, January 16, 2017:


I am using FreeRTOS+TCP from FreeRTOS Lab Version 160919 on the Zedboard with a ZYNQ SOC.
I have set up an interrupt using a counter in the APU. My interrupt service routine contains the following snippet of code:

double string = 2.3345;
printf(“value: %f \r\n”,string);

If I activate the interrupt I only get strange values in my UART console:
value: 23045066114377635280957554934828970424954912390364025862244197895673641598237541359790173769008596786348032.000000

If I start the interrupt without using FreeRTOS by leaving out the setup of the vector table and the start of the task scheduler in the main function, the value I get is the expected:
value: 2.3345

Could you please help me explain this behaviour? It seems the installation of the vector table corrupts the execution of printf in the ISR somehow. Printf with integer values works fine in both cases.

Best regards,

heinbali01 wrote on Monday, January 16, 2017:

There are two things to look at:

● The Zynq processor (Cortex-A9) has a set of FPU registers, which (by default) are not saved on stack. See

● It would be amazing if printf() works as expected from within an ISR
Especially when printf() or it descendants make use of FreeRTOS API’s.

There is an ISR-safe version of snprintf() in the FreeRTOS distribution:


From within an ISR, I would write logging to char buffers, and print them from a normal task.

rtel wrote on Monday, January 16, 2017:

Not sure if this is the same thread I just replied to - but if this is
on a Cortex-A then an issue has been discovered with alignment for
floats inside an interrupt. If this effects you then please use float
outside of the ISR (printf() should not be used in an ISR really
anyway), and if that is not helpful get back to us here and we will let
you know the fix.

pixt wrote on Tuesday, January 17, 2017:

Yes, it is a Cortex-A9 processor. I need to use float in the ISR because I do some high frequency calculation which is controlled by a timer interrupt. The fix would be really helpful, thank you.

rtel wrote on Tuesday, January 17, 2017:

In FreeRTOS/Source/portable/GCC/ARM_CA9/portASM.S you will find the
following code:

/* Call the interrupt handler. */
PUSH {r0-r3, lr}
LDR r1, vApplicationIRQHandlerConst
BLX r1
POP {r0-r3, lr}
ADD sp, sp, r2

I think the fix is to change both occurrences of r0-r3 to r0-r4, which
adjusts the alignment of the stack within the vApplicationIRQHandler
function slightly.

pixt wrote on Wednesday, January 18, 2017:

Yes, that did the trick. Thank you very much!