I hope I've got it. ![:)]( "Smile")
So, basically, when FPCCR.ASPEN (Automatic state preservation) is enabled (default), anything interrupting when CONTROL.FPCA is set (FPU supposedly still being used), will start with an automatic extended stack frame.
The lazy bit (LSPEN) just defers the stack pushes, but still reserves the space on stack, regardless if the FPU is used or not in this new context. It will stall and do the writes only if and when FPU is really used (CONTROL.FPCA being set again).
Any eventually subsequent nested interrupts will behave the same (using the extended stack frame only if the previous interrupt messed with CONTROL.FPCA) .
So it's better not to forget about CONTROL.FPCA after finishing with FPU, in any context, and be aware of consequences.
https://developer.arm.com/documentation ... ms?lang=en
So, basically, when FPCCR.ASPEN (Automatic state preservation) is enabled (default), anything interrupting when CONTROL.FPCA is set (FPU supposedly still being used), will start with an automatic extended stack frame.
The lazy bit (LSPEN) just defers the stack pushes, but still reserves the space on stack, regardless if the FPU is used or not in this new context. It will stall and do the writes only if and when FPU is really used (CONTROL.FPCA being set again).
Any eventually subsequent nested interrupts will behave the same (using the extended stack frame only if the previous interrupt messed with CONTROL.FPCA) .
So it's better not to forget about CONTROL.FPCA after finishing with FPU, in any context, and be aware of consequences.
https://developer.arm.com/documentation ... ms?lang=en
Statistics: Posted by gmx — Tue Sep 10, 2024 4:59 am