STM32U5A5 Trustzone Application

[batuburgu]

Hi!

I'm working on a Trustzone enabled application in STM32U5A5 nucleo board and have some questions in my mind. 

I have used the configurations of the example project for the Trustzone, which you can find below:

 - TZEN=1
 - SECWM1_PSTRT=0x0  SECWM1_PEND=0xFF  meaning all 128 pages of Bank1 set as secure
 - SECWM2_PSTRT=0xFF SECWM2_PEND=0x0   meaning no page of Bank2 set as secure, hence Bank2 non-secure  

I have enabled SAU and left it with the default configuration. I've also enabled the GTZC_S. 

In my application, I'm using TAMP mechanism of the RTC to create an interrupt when the output signal doesn't match the input signal. 

First question:
My application can boot from the secure app and jump to non-secure app without any problems. But in the MX generated NonSecure_Init() function, after the line 

SCB_NS->VTOR = VTOR_TABLE_NS_START_ADDR

The SCB->VTOR_NS register doesn't change, remains as 0x0 (according to the SFR in the debug interface). After the boot to non-secure app, SCB->VTOR_S value appears to be VTOR_TABLE_NS_START_ADDR. When I go to secure app for some reason, the SFR shows the VTOR register as the secure address. Is it normal for VTOR_NS to be always zero and for VTOR_S to be changing in every application change?

Second Question:

I've configured TAMP interrupts on the secure application. Therefore; when an interrupt occurs, my code jumps to secure app from the non-secure one. The interrupt does its job and the application can run normally if the TAMP interrupt (or presumabelly any other secure interrupt) doesn't occur until the PC returns to the NS app. (I've checked it with stopping the code at the interrupt, connecting the TAMP pins so that it won't cause an interrupt again and resuming the code.) 

I've also noticed that if I stop the code at the TAMP_IRQ, it can handle the interrupts without any problem even if I don't short the TAMP pins.

But if the TAMP interrupt occurs again before the application returns to the NS (it happens quite often since the TAMP comparator is working parallel to the CPU runtime), my code goes to SecureFault_Handler(). 

How can I overcome this problem? 

Thanks in advance. 

[Jocelyn RICARD]

 Hello @batuburgu ,

First SCB->VTOR_NS cannot be read back. It always returns 0. This is a cortex limitation as far as I know, quite annoying.

Regarding TAMPER interrupt, I'm not sure what actually happens but you need to know that SRAM2 will be read at 0 as a consequence of the TAMPER. So, it is possible that you get this fault because you are using this SRAM2 in your interrupt handler.

Best regards

Jocelyn

[batuburgu · Accepted solution]

Hi @Jocelyn RICARD,

Firstly, thanks for your quick response and the information about the SCB->VTOR_NS. I've been thinking that I'm doing something wrong up to now.

About the TAMPER, my interrupts doesn't utilize any region inside the SRAM2. But I believe that I've found the issue.

The default TrustZone configuration marks SRAM1 and SRAM2 as secure RAM regions, since the stack will start from the top of the allocated RAM, it is initialized at the top of the SRAM2.

When a TAMPER interrupt triggers, it erases the SRAM2 and therefore the stack, meaning that the return address of the interrupt is gone. Which causes the MCU to go to HardFault. (I can see in the call stack that the address 0x0 is called, which matches your contribution "SRAM2 will be read at 0 as a consequence of the TAMPER"). When I move the stack to SRAM1, the problem gets solved.

I have one more question left on my mind though, why doesn't the stack get erased if I stop the code inside the interrupt and reconnect the TAMPER pins? Does the TAMPER mechanism need the APB3 to be functional to perform the erase or does it have another connection to the SRAM2 that is not visible inside the block diagram provided in the datasheet? 

[thismarkjohnson]

Yes, that VTOR behavior is normal on STM32U5 — only the currently active security state’s VTOR is visible, so VTOR_NS reads as 0 while you’re in Secure, and VTOR_S updates when switching contexts. For the TAMP issue, this usually happens because the secure interrupt isn’t fully cleared or re-entrancy isn’t handled; make sure the TAMP flag is cleared before exit and consider masking the TAMP IRQ or deferring it until you safely return to the Non-Secure world.