2024-10-01 05:58 AM
I am using STM32U585 and I stumbled upon the following problem:
If a device is configured with TrustZone enabled (TZEN=1) there is different behavior in the following situations:
1. SPI is configured without DMA and CPU is running non-secure code in privileged mode in that case the CPU is able to read/write to SRAM1 (from IRQ handler)
2. SPI is configured using GPDMA and CPU is running non-secure code in privileged mode however in this case the GPDMA is not able to read/write to SRAM1
Reading the documentation I would expect that SRAM1 when TrustZone is enabled allows only secure / privileged access, but how does then the first described situation work at all, how does CPU have access to SRAM1 at all when it is running non-secure code?
Solved! Go to Solution.
2024-10-03 08:54 AM
Just to close this question by myself for anyone stumbling upon same problem in future.
In the “AN5347 - Arm® TrustZone® features for STM32L5 and STM32U5 Series“ it says “All memory map is fully secure through the IDAU/SAU, until the secure code enables the SAU and define regions for non-secure resources.” thus CPU is in secure state if SAU is not enabled after power-up.
So, in my case CPU is actually running in secure state and also in privileged mode so it has access to SRAM1.
And for GPDMA the “RM0456 - Reference manual STM32U5 Series Arm®-based 32-bit MCUs” says “When the TrustZone is activated, peripherals are set as nonsecure and unprivileged after reset.”, so the GPDMA cannot access the SRAM1 in that situation.
2024-10-01 07:00 AM
The second scenario fails because the GPDMA lacks the necessary permissions or security configuration to access that memory region. The GPDMA should be configured to operate in the correct security domain. You might need to adjust the security attribution settings for the GPDMA to allow it to access the same memory regions as the CPU.
2024-10-01 10:19 PM
Hi liaifat85,
thanks for quick answer.
I actually would like to understand how is that CPU running non-secure code can access secure SRAM1?
I suspect that DMA uses different bus and it checks secure attribute, and that for CPU access to RAM secure attribute is not checked, thus things work in that case.
2024-10-03 08:54 AM
Just to close this question by myself for anyone stumbling upon same problem in future.
In the “AN5347 - Arm® TrustZone® features for STM32L5 and STM32U5 Series“ it says “All memory map is fully secure through the IDAU/SAU, until the secure code enables the SAU and define regions for non-secure resources.” thus CPU is in secure state if SAU is not enabled after power-up.
So, in my case CPU is actually running in secure state and also in privileged mode so it has access to SRAM1.
And for GPDMA the “RM0456 - Reference manual STM32U5 Series Arm®-based 32-bit MCUs” says “When the TrustZone is activated, peripherals are set as nonsecure and unprivileged after reset.”, so the GPDMA cannot access the SRAM1 in that situation.