S32K3xx RTD default MPU implementation causes problems/seems wrong

AndreasStolze — Mon, 27 May 2024 13:10:53 GMT

Hi all,

we're having problems with MemManage faults being generated on startup. This is either a IACCVIOL or a DACCVIOL error.
This happens not in our own code, but already in RTD or NXP IPCF code.

I'm currently suspecting the MPU setup that's at fault, as when I am not defining MPU_ENABLED it works.

On further investigation, I am very puzzled about the MPU code provided by NXP in this file: "Platform_TS_T40D34M40I0R0\startup\src\system.c"
I am looking at the linker file from the Dio_Example_S32K358 of RTD 4.0.

Before we head into the file itself, I was also confused by this post:
https://community.nxp.com/t5/S32K/S32K312-W-R-FULL-access-MPU-address-leads-to-MemManage-exception/m-p/1773906

It seems to me that for the S32K3xx the wrong document was shown, as Cortex M7 is afaik ARMv7E-M architecture, thus not the Arm v7-M manual but this document must be used: https://developer.arm.com/documentation/ddi0489/latest/
This is quite important, as the MPU RBAR are different between those two architectures!

Here are the relevant snippets for Cortex M7:

Coming back to the start.c file:

The MPU is configured via the rbar and rasr arrays, for example region 6:

/*Ram unified section*/ #if defined(S32K396) || defined(S32K394) || defined(S32K344) || defined(S32K324) || defined(S32K314) || defined(S32K374)|| defined(S32K376) rbar[6]=(uint32)__INT_SRAM_START; /* Size: import information from linker symbol, Type: Normal, Inner Cache Policy: Inner write-back, write and read allocate, Outer Cache Policy: Outer write-back, write and read allocate, Shareable: No, Privileged Access:RW, Unprivileged Access:RW */ /* Disable subregion 7 & 8*/ rasr[6]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1)|(1<<15)|(1<<14); #else rbar[6]=(uint32)__INT_SRAM_START; /* Size: import information from linker symbol, Type: Normal, Inner Cache Policy: Inner write-back, write and read allocate, Outer Cache Policy: Outer write-back, write and read allocate, Shareable: No, Privileged Access:RW, Unprivileged Access:RW */ rasr[6]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1); #endif

Question 1

Why are the addresses of the linker are directly written into RBAR? The ADDR field is high withing the 32-bit word, and must be shifted. Furthermore, the shift is dependent on "N", which itself results of the "SIZE" field of RASR.

Also impacts of course currently the VALID and REGION field.

Question 2 (special case S32K344)

RAM section is 256 KB, thus subregions are 32 KB big. Top 2 regions 7 and 6 are disabled via "SRD" field. However, shouldn't region 5 also be disabled to get 160 KB size?

256 KB / 8 * 6 = 192 KB
256 KB / 8 * 5 = 160 KB

Further remark:

This table is not correct, at least because the code uses "__INT_SRAM_START" rather than "__RAM_CACHEABLE_START" as stated in the table. However, this is fine and should be even better, as this also includes the sram BSS section which should be fine to enable cache on as well.
Also the "ADDR" must somewhat be aligned based on the SIZE field. In the example __INT_SRAM_START is set to "ORIGIN(int_sram)" (so kind of aligned), but "__RAM_CACHEABLE_START" would be not aligned somewhere after sram BSS.

/* Region Description Start End Size[KB] Type Inner Cache Policy Outer Cache Policy Shareable Executable Privileged Access Unprivileged Access -------- ------------- ---------- ---------- ---------- ---------------- -------------------- -------------------- ----------- ------------ ------------------- --------------------- 0 Whole memory map 0x00000000 0xFFFFFFFF 4194304 Strongly Ordered None None Yes No No Access No Access 1 ITCM 0x00000000 0x0000FFFF 64 Strongly Ordered None None Yes Yes Read/Write No Access 2 Program Flash 1 0x40000000 PFLASH SIZE PFLASH SIZE Normal Write-Back/Allocate Write-Back/Allocate No Yes Read-Only Read-Only 3 Data Flash 0x10000000 0x1003FFFF 256 Normal Write-Back/Allocate Write-Back/Allocate No No Read-Only Read-Only 4 UTEST 0x1B000000 0x1B001FFF 8192 Normal Write-Back/Allocate Write-Back/Allocate No No Read-Only Read-Only 5 DTCM 0x20000000 0x2001FFFF 128 Normal None None No Yes Read/Write Read/Write 6 SRAM CACHE __RAM_CACHEABLE_START __RAM_CACHEABLE_END __RAM_CACHEABLE_SIZE Normal Write-Back/Allocate Write-Back/Allocate No Yes Read/Write Read/Write 7 SRAM N-CACHE __RAM_NO_CACHEABLE_START __RAM_NO_CACHEABLE_END __RAM_NO_CACHEABLE_SIZE Normal None None Yes No Read/Write Read/Write 8 SRAM SHARED __RAM_SHAREABLE_START __RAM_SHAREABLE_END __RAM_SHAREABLE_SIZE Normal None None Yes No Read/Write Read/Write 9 AIPS_0/1/2 0x40000000 0x405FFFFF 6144 Strongly ordered None None Yes No Read/Write Read/Write 10 AIPS_3 0x40600000 0x407FFFFF 2048 Strongly ordered None None Yes No Read/Write Read/Write 11 QSPI Rx 0x67000000 0x670003FF 1 Strongly ordered None None Yes No Read/Write Read/Write 12 QSPI AHB 0x68000000 0x6FFFFFFF 131072 Normal Write-Back/Allocate Write-Back/Allocate No Yes Read/Write Read/Write 13 PPB 0xE0000000 0xE00FFFFF 1024 Strongly Ordered None None Yes No Read/Write Read/Write 14 Program Flash 2 0x00800000 PFLASH SIZE PFLASH SIZE Normal Write-Back/Allocate Write-Back/Allocate No Yes Read-Only Read-Only 15 ACE 0x44000000 0x440003FF 1 Strongly-ordered None None Yes No Read/Write Read/Write */

BR
Andreas

Edit: Exchanged link to documentation, was another document.

Re: S32K3xx RTD default MPU implementation causes problems/seems wrong

danielmartynek — Mon, 27 May 2024 14:32:48 GMT

Hi Andreas,

ARMv7E-M is Armv7-M implementation that includes the DSP extension.

In Arm Cortex-M7 Processor Technical Reference, there is reference to Armv7-M Architecture Reference Manual that I was using in that thread.

https://developer.arm.com/documentation/ddi0489/f/memory-protection-unit/mpu-functional-description?lang=en

You use the description from the Cortex-M7 Devices Generic User Guide r1p2

https://developer.arm.com/documentation/dui0646/c/Cortex-M7-Peripherals/Optional-Memory-Protection-Unit/MPU-Region-Base-Address-Register?lang=en

Which looks different.

But if the region is 32B, log2(32) = 5 = N.

For 4KB region, N = 12, and so on.

The address is written as a 32bit word to the whole register without any bit shift, but it must be alligned, at least 5 zeros at RBAR[4-0].

The system.c does not use the REGION bits of the RBAR register, because VALID = 0, REGION is ignored.

It uses the RNR register.

The size of region 6 is 128KB so a subregion is 16KB.

The MPU configuration is just an example.

The configuration is up to the user.

I haven't tested the RTD project yet on S32K358.

I will test it tomorrow and come back to you,

Regards,

Daniel

Re: S32K3xx RTD default MPU implementation causes problems/seems wrong

AndreasStolze — Tue, 28 May 2024 07:45:36 GMT

Hi Daniel,

thanks for the reply.

I'm getting it now, however, it is very implicitly done.

Due to the regions being at minimum 32 bytes, if you align the addresses accordingly, the lower 5 bits 0:4 will always be zero, as 2^5 = 32.
Going further, if you increase the region size, for each doubling, the needed bits shift by two, thus the N comes into place.

So I guess you don't need to test it, the code now makes implicitly sense.

Thank you
Andreas

topic Re: S32K3xx RTD default MPU implementation causes problems/seems wrong in S32K

S32K3xx RTD default MPU implementation causes problems/seems wrong

Re: S32K3xx RTD default MPU implementation causes problems/seems wrong

Re: S32K3xx RTD default MPU implementation causes problems/seems wrong