cancel
Showing results for 
Search instead for 
Did you mean: 

STM32U575 TrustZone access non secure area from secure mode

fed
Associate II

Flash Memory is divided in different zones Secure (also protected by watermark), NCS and NS. All of such zone are defined in the the partition_stm32U575xx.h and SAU is enabled.

MCU is in secure mode and want to write in the non secure area.

Erasing return without errors, writing return without errors, but reading back what have been wrote doesn't match with the original data.

We had similar issue on the L5 and in that case we had to promote the flash to secure using HAL_FLASHEx_GetConfigBBAttributes, perform all write operations then demote all blocks to non secure. 

Unfortunately the same trick here doesn't work.

Any suggestion or minimal example?

Thanks in advance

 

6 REPLIES 6
Roger SHIVELY
ST Employee

Hello @fed,

 

This post has been escalated to the ST Online Support Team for additional assistance. 

We'll contact you directly.

 

Regards,

Roger

Dear Roger,

           I have been contacted, but the problem is still open. At the moment I provided all information that has been requested but no answer since the last week.

 

Have a nice day

FDA

Hi @Roger SHIVELY , @fed 

For your information I have a similar issue, with SRAM : I can write to NS SRAM from S world where I expect it to fail. Here the post : My original post 

I did not try to read back what I wrote, this could be interesting to do. But in the debugger memory view I can see the values I wrote.

P.

Dear PatriceL,

 

        thanks for your contribution!

If I well interprets the ARM Cortex-M33 specification for the secure and non-secure state, i believe that the behaviour you have is correct; in fact it is stated that secure mode can always access both secure and non-secure. This make perfectly sense, since when the mcu start immediately after a reset you are in secure mode with privileged access and then is the secure mode that will start the non-secure application after preparing the environnent in terms of resources.

In my case I have a secure application that is a secure-boot implementation and from secure world I cannot access the area of flash that is configured as non-secure. 

 

Regards,

FED

yep, I have same reading as you. But, in the same time, as I spotted in my post, you can read this in STM32U5 reference manual: Any secure transaction trying to access nonsecure block in internal block-based SRAM or watermarked memory is considered as illegal.Correct TZIC settings allows the capture of the associated event and then generates the GTZC_IRQn interrupt to the NVIC. This applies for read, write and execute access.

 

So, something is wrong somewhere ;)

Hi PatriceL,

 

        I agree with you, it is not the first time I found misalignment between the documentation and the implementation and the general specs and after spending so many time on this products U5 I believe that we have more limitations than benefits, but I will wait for STM feedback before to exclude completely this product. 

 

Regarding your problem, I may understood wrong, but checking your original post I see:

 

/* Secure read/write access not allowed on nonsecure SRAM block*/

MPCBB_Area_Desc.SecureRWIllegalMode = GTZC_MPCBB_SRWILADIS_ENABLE;

 

And in the paragraph immediately after the one you posted I read the following:

 

Concerning the MPCBB controller, there is an option to ignore secure data read/write access on nonsecure SRAM blocks, by setting the SRWILADIS bit in the GTZC_MPCBBz_CR register. Secure read and write data transactions are then allowed on nonsecure SRAM blocks, while secure execution access remains not allowed.

 

So, you can try not to enable that flag and then you should find your illegal access spotted.

Hope this help

Cheers

FED