This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[Cortex-M33 FVP]:SecureFault with SAU disable

Hello,

I am using Cortex-M33 FVP model to run the Keil RTX TrustZoneV8M RTOS example.
Have also tried to experiment with the memory map configuration and the corresponding SAU region programming for NS/S patitioning and the behaviour is as expected.

However when i try to disable the SAU usage in the system, I am seeing SECUREFAULT when switching from NS to S.
Here is the procedure i followed:


1) Configure SAU_INIT_CTRL=0 in TrustZoneV8M\RTOS\CM33_s\RTE\Device\ARMCM33_DSP_FP_TZ\partition_ARMCM33.h

=> Not attempting to program the SAU.

2) Disable SAU in the model,
cpu0.SAU=0x0                                          # (int   , init-time) default = '0x4'    : Number of SAU regions (0 => no SAU) : [0x0..0x8]

cpu0.SAU_CTRL.ENABLE=0                                # (bool  , init-time) default = '0'      : Enable SAU at reset

cpu0.SAU_CTRL.ALLNS=1                                 # (bool  , init-time) default = '0'      : At reset, the SAU treats entire memory space as NS when the SAU is disabled if this is set

VECTOR=SECUREFAULT FaultCause=SecureFault invalid transition SecurityState=SECURE

I also noticed that, If i enable the SAU but set ALLNS=1 ( both in SW and FVP config), the behaviour is still the same.

Note; I am not sure if this is even a valid experiment. Our target HW platform will not have an SAU.

Thanks,

Diwakar

Parents
  • Hi Diwakar,

    Do you mean the SecureFault happened when switching from S to NS (rather from NS to S)?

    If SAU is not enabled and ALLNS is 0, then the whole address is Secure, and when the processor try to switch to Non-secure side by executing BXNS / BLXNS, and the branch target landed in another Secure address, it should failed the Security check and hence the fault exception is normal.

    If your system don't have SAU, and still need to use TrustZone, then you should set ALLNS to 1. In that case the Security attribute of the system would be defined by IDAU only. The IDAU security attribute mapping can be found in AN505 Example IoT Subsystem design for V2M-MPS2+ (DAI0505B_example_iot_kit_subsystem_for_v2m_mps2.pdf) section 3.4 (table 3.1)

    Please note you still need to configure the Memory Protection Controller (MPC) and Peripheral Protection Controller (PPC) to partition the memory blocks and peripherals into Secure and Non-secure.

    regards,

    joseph

    Note: if you are working for silicon vendors that licensed Cortex-M33, it is likely that you are entitle to support. Or if you are from tool or RTOS vendor, we also have a separate support arrangement for these ecosystem partners.

Reply
  • Hi Diwakar,

    Do you mean the SecureFault happened when switching from S to NS (rather from NS to S)?

    If SAU is not enabled and ALLNS is 0, then the whole address is Secure, and when the processor try to switch to Non-secure side by executing BXNS / BLXNS, and the branch target landed in another Secure address, it should failed the Security check and hence the fault exception is normal.

    If your system don't have SAU, and still need to use TrustZone, then you should set ALLNS to 1. In that case the Security attribute of the system would be defined by IDAU only. The IDAU security attribute mapping can be found in AN505 Example IoT Subsystem design for V2M-MPS2+ (DAI0505B_example_iot_kit_subsystem_for_v2m_mps2.pdf) section 3.4 (table 3.1)

    Please note you still need to configure the Memory Protection Controller (MPC) and Peripheral Protection Controller (PPC) to partition the memory blocks and peripherals into Secure and Non-secure.

    regards,

    joseph

    Note: if you are working for silicon vendors that licensed Cortex-M33, it is likely that you are entitle to support. Or if you are from tool or RTOS vendor, we also have a separate support arrangement for these ecosystem partners.

Children