MPU configuration on Traveo(S6J336x) Family leading to "reading all zeros" from protected region?

[BiPa_4374526]

Hello,

It is my understanding that when the Memory Protection Unit(MPU) is active. You either have access to a memory region in which case you are able to read its contents or you do not have access in which case if you try reading/writing a memory violation is triggered.

But on the S6J336x when we turn on the MPU, certain regions though they do have content are read as zero. There is no memory violation and we do not read the correct content, we just read zeros.

Is this a known issue ? because this is really strange behavior.

Thanks.

--Bilal

[Kavya_B]

Hello Bilal,

Could you please provide below details for further analysis?

1) Please share MPU configuration in your project

2) Is MPU enabled when you observed the above mentioned behavior? Please verify.

3) Which memory region were you trying to access when you observed the above mentioned behavior?

4) Where you trying to access the memory in privileged mode or non-privileged mode?

Regards,

Kavya

[BiPa_4374526]

Hi Kavya,

1) I do not have a memory dump or a screenshot at hand. The MPU is enabled, the background region is enabled as well. We have only Background stack region on slot 13 that goes form 0x02010000 -- 0x02020000 configured at (USER_RW,SUPERVISOR_RW,SHAREABLE,CACHEABLE_WRITEBACK_ALLOCATE). The second region is a moving stack window, that moves over this region on slot 14 configured as (USER_R,SUPERVISOR_RW,SHAREABLE,CACHEABLE_WRITEBACK_ALLOCATE).

2) The MPU is enabled, the problem occurs during MPU reprogramming. When we reconfigure one region to only have read acess, we read zeros instead of the value therein.

3) It was RAM. More specifically the region 0x02010000 -- 0x0x02018000

4) from priviledged mode

On a side note, I could not reproduce this issue on the S6J32xx family of devices. The core and the MPU should be identical.

[Kavya_B]

Hello Bilal,

There are some further info and clarifications we need to comment on this.

1) We would request you to at least give values of MPU Region Access Control Registers for slot 13 and slot 14.

2) Could you please explain in detail the test procedure you followed and your expected behavior?

3) Could you please disable Cache in MPU settings and test again? Please let us know your observations in this condition.

4) There is some conflict on the data you gave and your expectations here. You mentioned that, in the MPU settings supervisor mode has both R/W access permission, i.e. privileged mode has both R/W permission in both the slots. In that case, there is no possibility that there would be memory violations when accessed from privileged mode right? Why are you expecting a memory violation in this scenario?

5) How do you confirm that there is a mismatch in data you read and actual data present in the memory region? I mean, how do you confirm that there are no zeros stored in the memory region which you are trying to read?

Please provide answers to above questions.

Thanks

Kavya

[BiPa_4374526]

Hi Kavya,

We debugged a bit further with the customer and we found out that the problem was with the shareable flag in the Region Access Control register. I am attaching the screenshots where the memory is visible where

Shareable flag is 0 , memory region is visible

Shareable flag is 1, memory region is all zeros

and it is also not just the debugger view, when the controller reads the value form the memory is also reads zeros.

1) They should be visible in the screenshots.

2) The code reads from the memory region, it is a stack region. It expects to have read access but only reads zeros. This isn't a test but a problem that one of our customers had.

3) I am pretty sure the cache was disabled but I can double check that with the customer.

4) I did a poor job explaining that, with the current configuration i did not expect a memory violation. What i meant was that there should only be two scenarios either i get a memory violation when i do not have rights or I am able to read what is inside the memory. I should not read zeros, that does not make sense to me.

5) Because we can see the memory contents before we turn on the MPU region and now with the flag I think we have found the problem.

I could not reproduce this on my S6J332 device, I am not sure what other configuration affects this. If this is known issue or configuration limitation a document that mentions it would be useful.

Best,

--Bilal

.

[Kavya_B]

Hello Bilal,

Thanks for sharing the details.

We suspect that Cache coherency could be a possible reason for your observations.

Please refer to section ‘9.5 Managing the MPU in context switches’ in ARM® Cortex®-R Series, Version: 1.0, Programmer’s Guide. This document is available on ARM official website.

We suspect that change in MPU settings in run-time is causing problem here. To understand this, could you please mention what was the original MPU settings and target MPU settings here?

Thanks,

Kavya

[BiPa_4374526]

Hello Kavya,

Cache coherency could be problem here yes. I will read through the Programmer's Guide.

The MPU settings at run-time were changed for only one MPU region. This region is not the one that had the shareability flag set and was causing the problems.

Original settings(that had a problem):

Background stack region: had the shareability flag set, over the entire stack memory region. Region number 13 in the screenshots. This is a static region and is not reprogrammed at runtime.

Stack window: did not have the shareability flag set, this region is reprogrammed at runtime. Region 16, I see it is not visible from the screenshots.

Target settings(that solved the problem):

Background stack region: did not have the shareability flag set, over the entire stack memory region.Region number 13 in the screenshots. This is a static region and is not reprogrammed at runtime.

Stack window: did not have the shareability flag set, this region was reprogrammed at runtime.Region 16, I see it is not visible from the screenshots.

So as i understand it the region from where we were reading zeros, the attributes for that region were changed from shareability=0 to shareability=1.

Thanks,

--Bilal