FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

STM32U5G9 TrustZone MPCBB

rdl_42
Associate III

‎2025-10-09 2:39 PM

I'm working with the STM32U5G9, trying to configure access to internal RAM blocks with TrustZone enabled.  Part of this configuration uses the HAL_GTZC_MPCBB_ConfigMem() function from stm32u5xx_hal_gtzc.c from STM32CubeU5 v1.7.0.

I see in that function a comment indicating:

  /* limitation: code not portable with memory > 512K */
  pMPCBB_desc->AttributeConfig.MPCBB_LockConfig_array[0] = READ_REG(mpcbb_ptr->CFGLOCKR1);

but the STM32U5G9 has several internal SRAM blocks with size over 512K:

 

rdl_42_0-1760045616550.png

Is TrustZone MPCBB control not fully supported by STMCubeU5 for the STM32U5Gx processors?  Am I missing something?

Thanks,

-Rob

Labels:
0 Kudos
3 REPLIES 3
Aime
ST Employee

‎2025-10-10 5:48 AM

Hi @rdl_42 ,
 

1. Hardware Support for Large SRAM in STM32U5G9

  • The STM32U5G9 device features multiple SRAM blocks (e.g., SRAM1 = 768 KB, SRAM3 = 832 KB, etc.) controlled by separate MPCBB instances.
  • Each MPCBB instance manages a maximum of 512 KB blocks (block size = 512 bytes, number of blocks accordingly).
  • The hardware supports multiple MPCBB controllers (MPCBB1 to MPCBB6) to cover all SRAM regions, including those larger than 512 KB.
     

2. HAL Limitation Comment Explanation

  • The comment in the HAL code:

  • means that the current HAL implementation assumes or is tested mainly for MPCBB regions up to 512 KB per instance.
  • This limitation is about the software abstraction and how the HAL driver handles the lock/config arrays internally.
  • It does not mean the hardware or TrustZone MPCBB feature itself is limited to 512 KB.

To solve this you need to ensure that size_in_superblocks is >= 32 so both CFGLOCKR1 and CFGLOCKR2 are configured

 

Best regards,
Aime
 

0 Kudos
rdl_42
Associate III
In response to Aime

‎2025-10-10 1:37 PM

Aime,

Thanks for you quick response.

After looking at the code and Section 5.8 of RM0456 Rev 5 more closely, it looks like the comment just isn't accurate.  The code works for the 832 KB and 768 KB SRAM resources supported on the STM32U5G9.

Thanks,

-Rob

Doug Barnes
Associate II
In response to rdl_42

‎2025-11-10 1:35 PM - edited ‎2025-11-10 1:38 PM

 

Rob I agree.  I noticed the comment about portability & raised an eyebrow as I too had successfully configured SRAMs of size 768K and 832K (U5A5).

Then I went and looked at stm32u5_hal_gtz.c and it was clear the file had been updated to handle the larger SRAM sizes.  (As someone who frequently updates code and forgets to check all the comments, I can relate.)

For example see the use of CFGLOCK2-enabled code:

/* limitation: code not portable with memory > 512K */
pMPCBB_desc->AttributeConfig.MPCBB_LockConfig_array[0] = READ_REG(mpcbb_ptr->CFGLOCKR1);

#if defined (GTZC_MPCBB_CFGLOCKR2_SPLCK32_Msk)
pMPCBB_desc->AttributeConfig.MPCBB_LockConfig_array[1] = READ_REG(mpcbb_ptr->CFGLOCKR2);
#endif /* GTZC_MPCBB_CFGLOCKR2_SPLCK32_Msk */

#endif /* defined(__ARM_FEATURE_CMSE) && (__ARM_FEATURE_CMSE == 3U) */

 

Kind of related: what I've learned to do now in my code when I realize there is a landmine, rather than just put in a comment (which (1) is not code, Ie. it won't catch mistakes at runtime, and (2) it is prone to rot), I put in an error check, an assertion, or best of all, a compile time check (with #warning or #error) when possible. 

0 Kudos
Top