STM32U5G9 TrustZone MPCBB

[rdl_42]

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:

 

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

Thanks,

-Rob

[Aime]

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
 

[rdl_42]

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]

 

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.