S32K中的主题 MPU Region0

MPU Region0

Catosh — Fri, 31 May 2019 11:49:17 GMT

Hi all,

I want to use MTB_DWT to monitor stack overflow and underflow on a S32K1x mcu (cm0+). I think (no evidence from ref manual) that DWT is accessible only throught the DAP interface and not from the processor.

In order to do so I "reserve" an empty buffer at the bottom of the stack and configure the MTB watchpoint for the address range for starting trace in case of access in that range.

Unfortunately, MTB is not able to trigger exceptions, so my approach is the following: I protect the SRAM_L area with the MPU and catch the exception (I did not check yet if MPU raises exceptions-- any hin on this?)

On S32K11x, I can see that the MPU is enabled out of reset with Region0 configured as:

WORD0 = 0x00000000

WORD1 = 0xFFFFFFFF

WORD2 = 0x0001F7DF

WORD3 = 0x00000001

I want to reconfigure region0, so I clear the bit in CSER[VLD] and update access control rights such as WORD3[VLD] is cleared.

But then writing to the RGD[0].WORD0 and RGD[0].WORD1 trigger an hard fault, even if the two VLD field are cleared.

Writing to REG1 does not raise any error.

Updating the region1 descriptor does not trigger any error.

any hint on this point?

Thanks and best regards,

Luca.

Edit: BTW, the example MPU_memory_protection from the SDK v3 does not trigger any error, the MPU_DRV_GetDetailErrorAccessInfo returns always a null value.

One more question about the MPU example from the SDK: according to the ref manual, pag. 261:

As shown in the third condition, granting permission is a higher priority than denying
access for overlapping regions

So the region0 configuration from the SDK should NEVER raise an error. Am I right?

Re: MPU Region0

danielmartynek — Wed, 05 Jun 2019 20:22:30 GMT

Hi Luka,

Regarding the Descriptor 0, please refer to Section 56.8 AHB-AP (S32K1xx RM rev.9):
“AHB-AP provides the debugger access to all memory and registers in the system (…) The MPU includes default settings and protections for the Region Descriptor 0 (RGD0) such that the Debugger always has access to the entire address space and those rights cannot be changed by the core or any other bus master.”

But the access rights of the other masters can be changed in the descriptor 0 - it can detect an access violation as well.

And it can be changed using the Region Descriptor Alternate Access Control 0 register.

Regarding the SDK example, have you pressed that button?

If pressed, the example disables descriptor 3.

Descriptor 3 gives a read access to the core in this flash region.

Whereas descriptor 2 does not.

So, if descriptor 3 is disabled, descriptor 2 detects an error on this flash read access.

Regards,
Daniel

Re: MPU Region0

Catosh — Thu, 06 Jun 2019 08:02:01 GMT

Hi Daniel,

thanks for your reply - I totally missed out the section 56.8. Now I'ts clear that I can change some region0 permissions but not the addresses. Maybe if there will be a rev10 of the manual a link between chapt15 and 56.8 could be helpful!

One side question, out of curiosity: how does the "protection" for the region0 work? Something like word0 and word1 are read only registers and write access triggers the hard fault?

K.R.

Luca.

P.S.

BTW, do you have any information on the DWT core or DAP only access or shall I write a new question about that?

Re: MPU Region0

danielmartynek — Thu, 06 Jun 2019 14:46:07 GMT

Hi Luca,

The word 0-2 registers are RW registers, but any write to these registers clears the descriptors's valid bit, and that's the problem.

To Region Descriptor Alternate Access Control 0 registers allows to change the access rights without clearing the VLD bits. Please note that even this RGDAAC0 register can't change the debugger's access rights.

I'm sorry, I haven't had time to look into the DWT issue.

Yes, a new post just for this question is a good idea.

Thanks,

BR, Daniel

Re: MPU Region0

Catosh — Tue, 11 Jun 2019 09:18:12 GMT

I have one more question, based on the behavior I am seeing on my implementation AND the SDK example.

I want to protect a 32bytes RAM area from writing (basically to protect from stack overflow, for example) and some minor execute protection to Flash area.

I understand that since in r0 debugger can't be changed, all other regions will inherit DMA access rights for DMA master access. Let's focus on core access here:

		core	debugger	dma
r0	0x00000000	---	rwx	---
	0xFFFFFFFF
r1	0x00000000	rwx	rwx	---
	0x0000FFFF
r2	0x00010000	rw-	rw(x)	---
	0x0001FFFF
r3	0x20000000	rwx	rwx	---
	0x20002FDF
(r4)	0x20002FE0	w	(rwx)	---
	0x20002FFF
r5	0x20002FFF	rwx	rwx	---
	0xFFFFFFFF

for region 4 I set the valid bit to zero, region r4 is "implicty" defined because it's the only area left empty in the mapping, hence it's like my r4 region is like:

(r4)	0x20002FE0	---	rwx	---
	0x20002FFF

When I try to perform an 8/16/32 bit write access, an Hard fault interrupt is generated and I can see the flags set in:

MPU->CSER[SPERR1]; (ok, expected)

MPU->EDR1[ERW]; (ok, correct)

MPU->EDR1[EACD] = 0x8000;(ok, correct since it's region 0)

But then even if I am clearing the SPERR0 f1 flag I keep being stuck in the hard fault handler.

AM I forgetting some step here?

In the SDK in the hard fault handler I see that

MPU_DRV_EnableRegion(MEMPROTECT1, 3U, true);

enables core permissions.

Is this needed because the bus master tries to complete the write operation and hence we never exit the hard fault handler?

Or shall I clear some other pending bit?

Thanks and best regards,

Luca.

Re: MPU Region0

danielmartynek — Fri, 14 Jun 2019 08:58:00 GMT

Hi Luca,

It leaves the HardFault handler but it triggers again the very same exception.

The return address is the instruction that has caused the exception.

The recovery is through reset as the program flow has been corrupted.

Regards,

Daniel