Hi,
I have scenario where SCS.AIRCR.BFHFNMINS is the default value of 0, which if I understand correctly means that whenever there is hard-fault, it would be trapped by secure hard-fault handler.
On the non-secure side, I have some test code running in non-secure unprivileged thread mode with PSP_NS and non-secure privileged thread mode with MSP_NS.
When I deliberately generate a hard-fault in both these modes that is,
1. Non-secure (NS) unprivileged thread (UT) mode with PSP_NS and
2. Non-secure (NS) privileged thread (PT) mode with MSP_NS
I land in secure hard-fault handler as expected.
However, in both the cases, I get the same LR/EXC_RETURN value of 0xFFFFFFB9.
How can I distinguish where the hard-fault happened? Is there a way to determine if the hard-fault occurred in NS UT with PSP_NS or in NS PT with MSP_NS?
Without this information, is there a way to find out the stacked PC of the instruction generating the hard-fault.
Best,
Rajiv
Hi Rajiv,
The CONTROL_NS.SPSEL provides the information you needed (Assumed you already checked EXC_RETURN and confirmed that it was in Non-secure thread mode when the fault happened).
regards,
Joseph
Thank you Joseph for the reply.
That's correct. I totally missed the existence of CONTROL_NS.SPEL.
For the design that I am currently exploring, since I posted the question, I moved the HardFault handler to Non-secure and it seems to be working as expected.