2026-01-25 1:45 PM
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 0The 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 0Please can the MMT be updated to patch this?
2026-01-25 10:53 PM
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.
2026-01-26 1:51 AM
2026-01-26 5:48 AM
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.
2026-01-26 7:02 AM - edited 2026-01-26 11:29 AM
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
2026-01-27 1:03 AM
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.