STM32CubeIDE STM32U575 MPU RBAR_A registers not working correctly in SFRs Debug Window?

[BCowp.1]

When debugging the operation of the MPU on the STM32U575 I'm confused by the apparent behaviour of the RBAR_Ax registers in the SFR window of STM32CubeIDE 1.10.1

From the ARM docs I think (but I'm not 100%) that the RBAR_A1, RBAR_A2 & RBAR_A3 registers in the Cortex-M33 are "shortcuts" to the RBAR register (aka RBAR_A0) of subsequent memory regions.

In other words, my understanding is that setting MPU_RNR = 1 and accessing the MPU_RBAR is the same as setting MPU_RNR = 0 and accessing MPU_RBAR_A1.

However, when I observe the SFRs window during debug I note that all of the RBAR_Ax registers show the same value.

Either I'm not understanding something or something's broken.

To be clear, when I change (for example) the value in RBAR_A1, the value of RBAR_A2 also changes to match it.

[Wijeden RHIMI]

Hello@ BCowp.1,

Thank for your posting !

It seems that you have used the same address for the 3 different registers: MPU_RBAR_A1, MPU_RBAR_A2 and MPU_RBAR_A3. So it is quite normal to have the same value :smirking_face:.

I will come back to you as soon as possible until we will approve if it is a bug :ok_hand: .

Best regards,

Wijeden,

[BCowp.1]

Hi Wijeden,

Thank you for your reply and for investigating this.

I'm not quite sure what you mean? These are hardware registers (in an ST device) being interrogated by an ST provided debug tool, so I have little control over the address that they reside at!

As it happens I think have got to the bottom of this; alias registers are a little peculiar in how they appear to operate. They seem to only work as aliases for different MPU regions when writing (but not reading).

So RNR = 4 and a write to RBAR_A1 does in fact write to the RBAR (proper) of RNR = 5. However the RBAR value for region 5 cannot be read back in the same way (via RNR = 4 and RBAR_A1).

Obviously the ARM documentation was roundly useless here, I managed to stumble upon some obscure reference to this behaviour with NVIC alias registers which I can't find now.

The ST HAL library seems to reflect this behaviour correctly when I interrogate at runtime.

The SFRs window in the debugger context should definitely not be updating all the alias registers with the same apparent value.

While we're on the SFR window, you appear to be missing the Limit Registers; MPU_RLAR and MPU_RLAR_A1 to MPU_RLAR_A3?

Thanks,

Ben

[LaurentL]

Hello,

Can you try latest STM32CubeIde version 1.11.2 (or at least 1.11.0), there has been an update on CM33 svd on MPU RLAR registers.

[BCowp.1]

Hi Laren,

Thanks for that suggestion; after updating to 1.11.2 I can now see the RLAR registers.

The behaviour of the RBAR_Ax registers is still not correct (unless I am mistaken, which is very possible).

For example:

When I set RNR = 0x4 and set RBAR_A1 = 0x20000000, I then expect to see RBAR_A0 = 0x20000000 when I subsequently set RNR = 0x5. That's my understanding of alias registers anyway.

However this is not what happens in the SFR window for the debug perspective. Setting an alias register appears to have no effect of the "master" RBAR of the next MPU region.

Ben