Thanks for the prompt response.
Understood, and fair point. But grep’ing for vApplicationFPUSafeIRQHandler in the source shows that it’s only referenced in the GCC/ARM_CA9 port, not in the GCC/ARM_CA53_64_BIT port. The Cortex-A web page ( https://freertos.org/Using-FreeRTOS-on-Cortex-A-Embedded-Processors.html ) appears to really only apply to the GCC/ARM_CA9 port. The text that’s sort of in a title position on that page says it’s specific to the A9, but the link itself lacks the “9”, so it’s sort of confusing.
Grep’ing through the source in FreeRTOS 10.4.1 shows that configUSE_TASK_FPU_SUPPORT is present in the GCC/ARM_CA9 port.c, but not in GCC/ARM_CA53_64_BIT. So, as the OP stated, the port that works with the Zynq Ultrascale MPSoC does NOT include the configUSE_TASK_FPU_SUPPORT option. I believe the OP was able to work around this based on the back and forth discussion above, but it leaves the GCC/ARM_CA53_64_BIT/port.c in a state where this interrupt and FPU stack problem is still present and not handled in the same way as the CA9 port.
In the end, I guess the point is that the ports for the CA9 and CA53, and the corresponding demos for the Zynq A9 and Zynq MPSoC A53 platforms, are not actually similar in these ways, even though the web page ( https://freertos.org/Using-FreeRTOS-on-Cortex-A-Embedded-Processors.html ) sort of implies that it’s valid for the Cortex A processors as a whole, with the exception of the three locations on the page where it specifically calls out the A9.
The final question, then, is whether or not the port and demo for the A53 will be updated to match what’s in the port and demo for the A9? If not, no worries, but it doesn’t seem like this difference is intentional. Thanks, again,for the interaction.