I am using FreeRTOS (kernel V10.3.0) on a Zynq 7020 (PicoZed board).
I’ve recently discovered that a set of Floating Point Calculations occasionally fails. They are in a low priority task and I recently started a frequent interrupt (70 microsecond period) which enabled a high priority task. The FP Calculations in the low priority task fail every few minutes.
If I surround the calculations with taskENTER_CRITICAL()/taskEXIT_CRITICAL() the issues goes away.
I have tried setting use_task_fpu_support to 2. I have tried setting it to 1 and calling portTASK_USES_FLOATING_POINT(); at the start of every task. Neither one solves the problem. I have verified I am not doing any floating point in any ISR.
I am using FreeRTOS asymmetrically on both cores of the 7020. I see evidence that the issue happens on both cores. The only tasks common to both cores are Inter-processor Communications tasks which don’t do floating point (but still declare that they do, just in case).
The only explanation I can come up with is that FreeRTOS is not properly saving the FPU context on this processor.
Is this a known problem in this version of FreeRTOS? Has anyone seen this or have a work around (other than disabling task switching for any code path that might include Floating Point)?
There were some known problems with the standard library functions using floating point registers to optimize memory moves - could your issue be related to that?
Thanks for your reply. As mentioned, I have verified that none of my ISRs do any floating point math. They pretty much just gather info from the FPGA registers, put it in a message and send it to a task to handle.
If a library function was messing up the FP registers and it was inline with my calculations, then it would not have responded to me disabling task switching. And it would probably always ruin the calculation, not just sometimes.
It’s possible a library function in another task messes the floating point registers, but that just leads to the same conclusion, FreeRTOS is not properly preserving Floating Point Context across task switches.
BTW. I also realized that some FP Library routines are not re entrant, so in the one case that I was using the log() function, I surrounded it with taskENTER_CRITICAL()/taskEXIT_CRITICAL() and that made a difference, but did not solve the entire problem. No other code I have uses the log() function, so it really could not have been re entered, but I suspect it may take a few CPU cycles to calculate the natural log and represented a good sized temporal target to get the interrupt in.
Issues solved and Richard Barry was pointing in the right direction. My ISRs inform tasks of information by sending messages on message queues. FreeRTOS send on message queue invoked memcpy() to copy the message, at interrupt level. With no protection of the FP registers.