cancel
Showing results for 
Search instead for 
Did you mean: 

Incorrect SAU Configuration From MMT on STM32H573 with Backup RAM Enabled

ben5050
Associate II

When using the memory management tool (MMT) on the STM32H573 to set the backup RAM as secure it generates an invalid secure attribution unit (SAU) config:

#define SAU_INIT_REGION5 1
#define SAU_INIT_START5 0x40000000 /* start address of SAU region 5 */
#define SAU_INIT_END5 0x400373FF /* end address of SAU region 5 */
#define SAU_INIT_NSC5 0

The above code is the last region the MMT defines for the SAU.

Typically the tool would define the region 0x40000000 to 0x4fffffff (the non-secure peripheral address space) as non-secure. However 0x40036400 is the start of the backup RAM address space which shouldn't be made non-secure.

Since this is the last SAU region, there is nothing configuring the region 0x40037400 to 0x4fffffff as non-secure, and so hard faults occur when e.g. trying to access the non-secure RCC address space.

I believe correctly generated code should look like the below:

#define SAU_INIT_REGION5 1
#define SAU_INIT_START5 0x40000000 /* start address of SAU region 5 */
#define SAU_INIT_END5 0x400363FF /* end address of SAU region 5 */
#define SAU_INIT_NSC5 0

#define SAU_INIT_REGION6 1
#define SAU_INIT_START6 0x40037400 /* start address of SAU region 6 */
#define SAU_INIT_END6 0x4FFFFFFF /* end address of SAU region 6 */
#define SAU_INIT_NSC6 0

Please can the MMT be updated to patch this? 

5 REPLIES 5
Mahmoud Ben Romdhane
ST Employee

Hello @ben5050 

Let me thank you for your post.

For more investigation, could you please provide your IOC.File.

Thanks

Mahmoud 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hi Mahmoud,

I've attached the IOC file.

Kind regards,

Ben

Hello @ben5050 ,

 

After checking internally, the SAU configuration generated by the Memory Management Tool is correct and expected.

When Backup RAM is secure on STM32H573, CubeMX intentionally ends the non-secure peripheral SAU region before the Backup RAM start address.

As a result, the non-secure SAU region is limited to 0x40000000-0x400363FF and the remaining address space is not automatically configured as non-secure, in accordance with Trust Zone security model.

Any additional non-secure peripheral regions must be explicitly defined by the user if required.

 

Thanks

Mahmoud

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Thanks for getting back to me so soon @Mahmoud Ben Romdhane,

After using the MMT to configure the SAU, the SAU is then greyed out and under the control of the MMT. So in order to fix this the user has to edit the generated code which is not obvious. It would be nice if there was some warning about this.

Also the region the MMT configures in the SAU as non-secure is 0x40000000-0x400373FF which includes the 0x40036400-0x400373FF region for the backup RAM which the whole point was to avoid.

Please correct me if I'm wrong, thanks again,

Ben

Hello @ben5050 

 

When the SAU is configured via the Memory Management Tool, the SAU view is intentionally locked, as the MMT becomes the single source of truth for Trust Zone configuration. This avoids inconsistencies between the graphical setup and the generated code. Any additional SAU regions must therefore be defined by the user if required by the application.

Regarding the address range: although the displayed non-secure region appears to extend up to 0x400373FF, when Backup RAM is configured as Secure, it is not exposed as non-secure. The security attribution applied by the SAU correctly protects the Backup RAM.

 

Thanks

Mahmoud

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.