I want to know where the context was saved when a secure function was called in a non-secure interrupt function.
As shown in the figure, when a secure NSC function is called in a non-secure SVC interrupt service function,
the PUSH {R4-R6, LR} operation is executed. At this time, CONTROL_S==0x03, that is, the Thread/PSP state.
But the PSP_S=0X00000000, I want to know where the {R4-R6, LR} registers are pushed into?
By the way: the result of the program is normal.
Thank you!
Hi Yang,
As per your description above, I understand that the program has successfully transitioned from non-secure state to secure state. This effectively means that there is an SG instruction at secure entry point and the branch instruction used for NSC_function1() is correctly marked as Non-Secure-Callable attribute. Hence I would assume that the instruction PUSH {r4-r6,LR} should have got executed before calling NSC_function1() branch (i.e.) in Non-Secure state. If it is executed in Non-Secure state, then CONTROL_NS/Non-Secure stack pointers come into picture.
Hope this helps.
Thanks,
Uma
Hi Uma
Sorry for the unclear description of the problem.
Before executing the SG instruction, the CPU is in non-secure state , CONTROL_NS: 0X01
After executing the SG instruction, the CPU is in secure state, CONTROL_S: 0X03,
PSP_S: 0X00000000, and then executing “ PUSH{R4-R6, LR} ” instruction.
The “ PUSH{R4-R6, LR} ” instruction will be exectued in Secure world and the PSP_P is 0x00000000, so I don't understand where the "R4-R6, LR" will push into?
Thank you.
Thanks for the detailed snapshot.
Here are my observations and points to check
(1) In secure world, both PSP and PSP_LIM registers are at 0x0000_0000. PSP/stack pointer in use should be initialized to a value such that the stack operations could be descending.
(2) As per R-YVWT of (ARMv8M Architecture Reference Manual - ARM DDI 0553A.e (ID060617)), PUSH instruction is subject to stack limit checks.
(3) Hence as per R-DBSG, on a violation of stack limit check when an instruction updates stack pointer, "It is IMPLEMENTATION DEFINED on whether accesses to addresses equal to or above the stack limit value are performed"
In a nutshell,
(a) If you could check on the PSP/PSP_LIM values that need to be used in both secure and non-secure states, then you should be able to see correct results.
(b) If PSP/PSP_LIM of secure state is expected to 0x0000_0000, then you can check your implementation's behavior to see the access are allowed or ignored.
Thanks for the detailed answer.
I found the place where the "R4-R6,LR" registers pushed into, these registers are pushed into the where the MSP_S points.
I think this is because this NSC_function is called in the SVC interrupt function, so the CPU is still in Handler mode instead of Thread mode and should use the MSP_S stack pointer.
Here I want you to help me confirm a problem:
When the NSC function is called in a non-secure SVC interrupt function, and the CPU switches from a non-secure state to secure state. Is the CPU still in Handler mode?
If the CPU is still in Handler mode, then the usage of the MSP_S can be understood after the state swich. The only thing that is puzzling is why the IDE indicates that the SP value is 0X00000000 instead ot the value of the MSP_S. I think there may be an error in the IDE display.
Thank you very much.
Best Regards
Yang
Good to see that you have progressed with debugging the issue.
I am guessing that it could be an IDE display issue, however since I am not an expert in this area I can not comment on this regard.
Thanks
I want you to help me confirm a problem:
Thanks a lot.
Sorry, I missed this question earlier.
Yes. The CPU is expected to be in Handler mode only (assuming that there no asynchronous interrupt between the state transitions)