I have a question regarding static variables (scope limited to files/modules) and the MPU. I’ve been using the nRF9160, which is an ARM Cortex-M33, with the MPU enabled. The MPU has been a pain. However, I understand the protection it provides.
With this in mind, I’m trying to understand why the MPU allows me to access static variables from within a task. I have defined these variables as static within the same file as my task. However, I have not defined that area of memory as shared during task creation. So, I’m wondering if this is a bug, a loophole, or am I missing something here.
I think I just answered my own question. It seems that if the task is created with the privileged bit set, it can bypass the MPU.
Sorry to have bothered anyone with this.
Yes, only tasks created as “Restricted” are limited by the MPU.
OK, thanks. I now have a new issue. I’m trying to call a function that requires thread-safety (including from interrupts) from an unprivileged task. Is a mutex the way to go in this case? Entering/Exiting critical section causes a hard fault from the MPU.
A Mutex provides good task-to-task thread safety but doesn’t protect from an ISR. Restricted/unprivileged tasks can’t use critical sections as that instruction is privileged since it would allow a restricted task to take over the processor (by blocking the timer that could switch it out)
If you really need critical sections in unprivileged tasks, you can probably add the enter critical section into the list of functions that use the privilege escalation operation to make it usable in unprivileged tasks.
It is tricky to retrofit an application not specifically designed for use with an MPU. You can do simpler things like split the memory space into trusted and untrusted code, rather than use different MPU regions for every task. That enables trusted tasks to share memory more easily while remaining isolated from untrusted code. If that is applicable is completely dependent on the needs of the application of course.