Hi
We found the issue when using floating-point calculations in the mulitple ISR, then the floating-point number will be not as expected sometimes.
After adding "VPUSH {D0-D15}" in the beginning of the interrupt callback and adding "VPOP {D0-D15}" in the end of the interrupt callback, the issue will not occur anymore.
I think the cause is the floating-point register set is not automatically saved and restored for Cortex-R52+, is that right ?
What is the suggestion for such issue ?
Is it necessary to pop and push FPSCR manually ?
BR, Grace
Grace WANG said:I think the cause is the floating-point register set is not automatically saved and restored for Cortex-R52+, is that right ?
That's correct.
Cortex-R52 implements Armv8-R AArch32. In AArch32, the general purpose and floating-point registers are not automatically saved on exception entry (or restored on exception return). It's up to software to stack whichever registers it needs/wants to use in the exception handlers.
The same goes for registers such as the FPSCR. Avoiding the overhead is why some software chooses not to use FP/Neon in exception handlers.
This guide might be useful: https://developer.arm.com/documentation/den0042/a/Exceptions-and-Interrupts/Exception-handling It was written more for the Cortex-R4/5, but the basics of exception handling remain the same
Hi Martin
I see the Cortex-R programming guide only mentions about the Rn, LR, etc, for exception handling, but no floating-point registers. Is there any document to indicate that the floating-point registers for Cortex-R need be saved and restored manually and also any guide or instruction process for that ?
Yeah, I suspect that's because of the assumption that a lot of interrupt handler code will avoid the FP registers to save the overhead.
In terms of a list, it's more the other way around. The architecture lists those registers which are updated on exception entry/exit. Any other register you update, or cause to be updated, that effects where the exception was taken from potentially has to be saved/restored. The architecture doesn't spell it out as you might deliberately choose to save/restore some registers. For example, you might use registers to pass arguments in and out of a system call.