With a support entitlement you can also get direct access to our team of highly-qualified Arm experts 24-hours a day
Open a support case
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.
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.
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.
Thanks Joseph. For some reason, i did not get notified that there was a response. Sorry for the delay in reply. I just noticed that i made a typo in my question. I am basically switching from Secure to Nonsecure (BLXNS).
I am using the M33 FVP model. On the FVP, i tried two things like below and got secure fault in both cases.
1) Disable SAU completely. Got the secure fault when switching from S to NS.
2) Enable the SAU, set the SAU regions to 0 and set ALLNS=1.
I now understand from your reply that when SAU is disabled, the security attributes are defined by IDAU.
I will check your feedback on the DAI0505B_example_iot_kit_subsystem_for_v2m_mps2.pdf and getback.
Yes, we have licensed the M33 and have also got license for the fastmodel portfolio for M33.
Can you let me know how to access support for such technical issues? Would it be through https://silver.arm.com/ ?
Yes, you can do it via https://silver.arm.com/support/
Or see the information in
I have a basic question about SAU/IDAU. When you stated earlier "If your system don't have SAU, and still need to use TrustZone, then you should set ALLNS to 1"
Does this mean, the SAU is present ( not completely disabled) but,the SAU regions are disabled and these regions are defined by external IDAU interface?
Yes, if your system have TrustZone support, then SAU Control register will be available, even if the number of SAU region is configured to 0.