MPU configuration not effect on CYT3DL

[StefanoToselli]

Hello,

I'm asking support for the configuration shown on Lauterbach debugger for MPU. 

On  Region 3 address 0x28018000 I allocate a variable in RAM as shown on watch window called:  “VF_Safe_u8DebugCnt”.

Region 3 overlaps Region 0 considered as background but I'm using logic of priority based on Region ID higher wins  so I expect that Region 3 setting are the actual applied for this section where my variable is.

Region 3 for the instant I set the breakpoint is Disabled but it is still visible and modifiable by an increment operation done by my task.

I expected on exception or at least the impossibility to modify it.

As suggested on other forum, Region 3 has no cache.

[Ashish · Accepted solution]

Hi StefanoToselli,

Two observations based on the screenshot you attached- 

a) Region 3 is disabled, so MPU settings for region 3 settings are not applicable. Since Region 0 overlaps this, and is Enabled- this will be applicable for your memory, irrespective of your priority logic.

b) The AP access value is '3', i.e. full RW access (in both region 0, region 3 settings)- so I don't see why you should not be able to modify the value, or why it should throw exception upon accessing the variable you mentioned.

Thanks,

Ashish

PREVIEW

[StefanoToselli]

Thanks Ashish,

having an operating system with creation of a TRUSTED application and a TRUSTED WITH PROTECTION that notifies with a callback every time what is running, the intention was to configure MPU with a region, the 3 in our case, considered to be protected when TRUSTED WITH PROTECTION runs.

So in the OS callback I am enabling and disabling region 3, thinking that in this way, if disabled, the application TRUSTED WITH PROTECTION could not access it. I think at this point I have confused the concept expressed in the AN219843

Region 0 is used as the background region. If no attributes are specified by another region, the background region will be applied.

I thought it meant that ONLY if the region was not fully defined then it uses the background setting, actually if a region is defined but disabled is equivalent to not defining it and then falling into the background is accessible.

Maybe in the operating system callback I can alternate the two attributes of region 3: CY_MPU_ACCESS_P_NO_ACCESS and CY_MPU_ACCESS_P_FULL_ACCESS keeping to OS the sync events to control them.

Or, completely changing approach is more correct to use the attribute CY_MPU_ACCESS_P_PRIV_RW but I am not clear how I can communicate to MPU when I am privileged or not: Is it maybe the example functions:

void SetUserMode(void)

{

__ASM("MRS r0, CONTROL"); // Read CONTROL register into R0

__ASM("ORR r0, r0, #1"); // nPRIV -> 1

__ASM("MSR CONTROL, r0"); // Write R0 into CONTROL register

}

void SVC_SetPrivilegedMode(void)

{

__ASM("SVC 0x02"); // SVC index = 2: Get privileged mode

}

[Ashish]

Hi StefanoToselli,

Yes, the "disable" attribute is for MPU disable, so it's equivalent to not applying that attribute as said earlier. So if you want to restrict R/W access to the region, you have to restrict it using the AP attribute (access permission). Now, you mentioned the approach to alternate the two attributes of region 3: CY_MPU_ACCESS_P_NO_ACCESS and CY_MPU_ACCESS_P_FULL_ACCESS keeping to OS the sync events to control them. We think this should be okay- you can try this.

Thanks,

Ashish