STM32H533 Memory mapped OCTOSPI SAU violation

[mtallatta]

Hello,

 

I’m working on STM32H533 project with trust zone and secure and non-secure firmware.

The project has an OCTOSPI external flash w25q64jvssiq memory, configuring the OCTOSPI in the non-secure side.

 

I have configured the SAU unit for memory mapped mode, gice access to the OCTOSPI from the secure side with HAL function: HAL_GTZC_TZSC_ConfigPeriphAttributes(GTZC_PERIPH_OCTOSPI1,GTZC_TZSC_PERIPH_NSEC | GTZC_TZSC_PERIPH_NPRIV);

 

At the non-secure side I can write/read the memory using QSPI instruction. Also I can change to memory mapped mode and have access with debugging tool (uVision).

When I change to memory mapped mode and use any instruction to acces directly to memory an interruption occurs and give back to secure side on SecureFault_Handler showing AUVIOL violation.

 

 

Attached you can find the SAU configuration file, made by myself because STM32CubeMX does not make any change in the file, like this post: 

 

So, obviously I missed something or I’m doing some mistake, I need help ASAP to solve this issue.

Kind regards,

 

[mtallatta]

The file of SAU configuration.

[Jocelyn RICARD]

Hello ​@mtallatta ,

You have the regions 4 and 6 that address the same area at 0x90000000.

Please remove or disable one of the 2 regions, I guess this will solve your issue

Best regards

Jocelyn

[mtallatta]

Hello ​@Jocelyn RICARD ,

 

Thanks for your observation, I fixed SAU file removing section 4.

Now the problem is that memory mapping isn't working; I've tried different SAU configurations, but it's not possible. If I revert the SAU file to the previous configuration, the mapped mode works fine with the same starting code.

 

 

[Kelvintavarez]

It looks like the key point to investigate is the SAU/GTZC configuration versus the actual memory-mapped OCTOSPI address range. Since indirect QSPI read/write works from the non-secure side but a direct memory-mapped access triggers AUVIOL, I’d first verify that the complete OCTOSPI memory window is marked with the expected security and privilege attributes.

I’d also check the resulting SAU configuration in the debugger rather than relying only on the configuration file. The fault address and the SAU region boundaries should help determine whether the access is falling outside the intended non-secure region.

It may also be worth checking whether the GTZC peripheral attribute configuration and the SAU settings are consistent, since both can affect the security attribution of the access.