This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Using MPU to seperate safety sections from normal sections



Hi,

is there any way to seperate the flash and Ram memory into two different sections so we can protect our safety critical funktions from side effects from the non-safety code.

What we need is a way that the safety critical code has permission  to read/write everything thats readable/writable but the non-safety functions may only have read/write permissions to code/ram-sections wich explicitly determined.

I've looked through the ARM Technical Reference Manual (ARM DDI 0363G) and the ARM Architecture Reference Manual (ARM DDI 0406) but the only way i found to make this possible (if i understand everything right) is by handeling all of the safety critical code in privileged mode (FIQ, IRQ) and all non-safety-code strictly in user mode, so we are not able to use any Interrups in the non-safety-code. Please correcct me if i'm wrong.

The safety code does in fact run only in FIQ,IRQ but we also have some non-safety-code running in IRQ (no FIQ) which would not be locked out from the safety sections.

Regards,

Frank

  • Hi Frank,

    You are right.  The ARM architecture stated on table B4-3 that R/W permission is identified based on user/Priv mode.

    So, assigning safety task to priv mode and non-safety task to user mode is the only way we can handle R/W permission.

  • Hi Frank,

    The ARM PMSA definition of MPU is based on the requirements of OSEK operating systems for automotive.  There is an implicit expectation that the RTOS or task switcher is running in privileged state and changes the MPU configuration from task to task as needed.  In this fashion, it is possible to do what you request, though it may require a change to your software architecture.

    If you keep your MPU regions static, then you need to be aware that there is no specific identification per task - the only differentiator which the MPU can apply is state of privilege.

    Regards,

    Karl

  • Hi Frank,

    You probably don't use freeRTOS, but there is a guideline in freeRTOS (and probably the same guideline in other RTOS as well) on how to allow safety critical code having the permission to read/write everything that readable/writeable but the non-safety codes may only have read/write permission to the code/ram sections with explicit determined by running your safety critical task in privilege mode and your non-safety critical task in user mode with appropriate corresponding MPU attribute setting.  

    At the hardware level in Cortex R, only privilege or user mode are used to determine read/write permission in MPU attribute as previously stated.

    http://www.freertos.org/FreeRTOS-MPU-memory-protection-unit.html

    Please look at high level guideline at freeRTOS-MPU features and Restricted (Protected) Task sections.  I had the freeRTOS user manual that had into detail of these Restricted Task creation and TaskAllocateMPURegions that could give some good detail guideline, but it was a paid copy per user (~$25 USD if i remember correctly) so i can not share this with you.

    Hope this helps you further...

  • Hi,

    thats bad. RTOS is not an option, so we have to find an other way to make make our system safe.

    Regards,

    Frank

  • Hi Frank,

    I'm sorry that ARM's memory protection scheme is not what you had in mind.  We have been working with ARM on improvements in the ARM v8 architecture, but what we have today is a v7 PMSA compliant solution.

    Is it possible to implement the MPU region switching in your task switcher, even if you do not have an RTOS?

    Regards,

    Karl

  • Hi,

    the trouble is that we have to separate the safety task from the normal ones. therefor we have to make sure, that there is no possibility that the not-safety task have access to the code and memory of the safety tasks. This is only possible if nothing ever enters privileged mode which ist not-safety. Therefor we may not use any interrupts in the not-safety part.

    Regards,

    Frank