You copied the Doc URL to your clipboard.


In Armv8-M processors with Arm TrustZone technology for Armv8-M implemented, the BFHFNMINS bit in the Application Interrupt and Reset Control Register (AIRCR) is available and is programmable by Secure privileged code only.

The possible values of this bit are:

BusFault, HardFault, and NMI are Secure.
BusFault and NMI are Non-secure and exceptions can target Non-secure HardFault.

It can be used in Armv8-M devices where TrustZone technology is used for firmware protection. This is a common where software assets are preloaded and can be utilized by third-party software developers, but at the same time it must not be possible to reverse engineer the preloaded software

If the application contains Secure libraries or a Secure RTOS, then the fault handling code interacts with the Secure code and the HardFault exception must be executed in Secure state. In such cases, AIRCR.BFHFNMINS must not be set to 1. If the code running in the Non-secure state needs to handle faults, then it should enable the individual Non-secure exceptions (UsageFault, MemManage Fault, etc for example) so that these faults can be handled by the Non-secure state and don’t escalate to a Secure HardFault.

In applications where only a single security state is needed, it may be desirable to run in the Non-secure state and lock down access to the Secure state to prevent malicious root kits being installed by an attacker. In these situations, it may be desirable to set AIRCR.BFHFNMINS to 1 before locking down the Secure state so that HardFaults and NMI’s can be handled by the Non-secure state.


Software must clear the Bus Fault Address Register (BFAR) when setting AIRCR.BFHFNMINS to avoid exposure of the last fault address to the Non-secure state.

In some cases, when a Secure exception is triggered, the Secure handler may need to trigger the execution of Non-secure code. In cases where the original Secure exception is higher than the AIRCR.PRIS threshold (i.e. a lower numerical value), ARM does not recommend calling the Non-secure code directly from the Secure handler, as this could allow Non-secure software to gain a higher than expected execution priority level. Instead the handler can pend a Non-secure second-level exception handler so that the exception event can be handled by Non-secure software. ARM recommends that Secure exceptions only allow further execution of Non-secure code if the exception wasn’t caused by an attempted attack

Some of the fault handlers that are written for the Armv6-M and Armv7-M architecture contain code that extracts stacked program counters from the stack frame. Some of these handlers might need to be changed because the fault handler might be in the Secure world, while the stack frame is in the Non-secure stack, so the code to locate the stack frame must be changed.

Was this page helpful? Yes No