STM32U535 Memory Mapped OCTOSPI from NonSecure Context

[anthonyw_bytesnap]

I'm working on a project which is being ported over to be TrustZone aware, part of this project makes use of an OCTOSPI configured in memory mapped mode for file access. Base settings come from the IOC however the memory mapping is executed in source.

In the non-TrustZone project this works without issue, however in the TrustZone aware one it is triggering a SecureFault upon trying to access a memory region.

// Sample access that causes the SecureFault
uint32_t testAccess = *(uint32_t *)0x90008000;

The SAU reports an AUTHVIOL error for the address 0x9000_8000.

The SAU is configured to enable NonSecure access to the region 0x9000_0000 through 0x9FFF_FFFF.

The MPCWM settings have also been configured to mark the same region as NonSecure and Unprivileged

The OCTOSPI DMA channel is configured for NonSecure and Unprivileged

The MPU is disabled, however we have also tested with enabling the MPU in both contexts and mapping the same region to be Non-Secure, Unprivileged with no success.

I am able to read the JEDEC flash ID via HAL_OSPI_Receive in the NonSecure context so am confident that the physical link is working correctly, the problem seems to be uniquely tied to Memory Mapped mode.

Additionally if I use a NSC function to read the memory mapped address from the Secure context it works as expected, confirming there must be another region/setting that is still Secure despite the configuration.

Finally I have also attempted to set the OCTOSPI1_S address space to NonSecure in the SAU which resolved the SecureFault but saw all data Read-As-Zero.

Is there anyway to operate a memory mapped OCTOSPI from the NonSecure context, directly reading those memory addresses?

[Jocelyn RICARD]

Hello @anthonyw_bytesnap ,

"The SAU reports an AUTHVIOL error for the address 0x9000_8000.

The SAU is configured to enable NonSecure access to the region 0x9000_0000 through 0x9FFF_FFFF."

If you get a secure fault, this means you don't need to go further. Issue is the SAU configuration.

What did you do to setup the area non secure ? Did you double check the SAU configuration ?

Best regards

Jocelyn

[anthonyw_bytesnap]

Thanks @Jocelyn RICARD ,

I have confirmed the SAU configuration looks valid, however based on my mentioned tests above I can see that despite the OCTOSPI being configured in the Non-Secure context, something about Memory Mapped mode is still trying to access the OCTOSPI1_S address space behind the scenes.

If I add an SAU region for the OCTOSPI1_S Alias address (I don't have the sources at the moment, but it is somewhere around the 0x05DA_0000 space) the memory mapping no longer throws a Secure Fault but simpley results in Read-As-Zero being returned.

I was able to create a cutdown test project which also leveraged the MPU to ensure that the external flash region is configured. In this instance I instead receive data access violations and MemManage Faults.

Are there any sample projects that demonstrate proper usage of a memory mapped XSPI flash with TrustZone from the NonSecure world?

[anthonyw_bytesnap · Accepted solution]

I was able to resolve this issue in the end after external support form an ST FAE.

The resolution consisted of three steps ultimately:

A core issue with the SAU configuration I've yet to understand. Restarting from a fresh SAU configuration and adding the region resolved the Secure Fault.

I was then stuck with Read-As-Zero faults on the memory mapped mode, initial support identified this rightly as the MPCWM needing configuration. However after configuring that I was still getting Read-As-Zero problems.

The final piece of the puzzle was the RCC_GTZC clock not being enabled, for whatever reason the following line was absent from the generated GTZC configuration.

__HAL_RCC_GTZC1_CLK_ENABLE();

After adding this to the MPCWM configuration in Secure/Core/Src/gtzc_s.c the memory mapped OCTOSPI now works perfectly