We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I see from about 12 months ago some interest in Memory Protection Unit (MPU) integration with RTX5 and how it doesn't seem to have gone forward.
I too was thinking of where I could enhance the RTX5 code with MPU features, but just realized you can get SOME support from the MPU with NO changes to RTX.
In osThreadNew ,if I pass an osThreadAttr_t* as 3rd param, in that struct I can define the stack for the new thread. Now, if I want say a 1K stack, I can define the actual size as 1024 + 32. I can then set a 32-byte MPU region (the smallest possible) at offset 0 of that stack. With stack watermarking and the 'magic number' that RTX places into the stack, I might have to postpone the MPU_Enable until in the thread itself, or i can set the region perms to 'priv write only' which would allow RTX write access (in svcThreadNew), running in handler mode.
OK, so this only gives STACK protection, but in my experience stack overflow is a major source of errors in this domain. Yes, the 'stack overflow check on thread context switch' is OK,but if the errant thread has high priority and doesn't voluntary block (on a mutex, signal, etc), there is an arbitrary number of instructions executed between the stack corruption and the discovery of that corruption. With the 'electric fence' protection of the MPU, the FIRST stack push past what stack space the thread was allocated would be flagged.
I had originally thought that an MPU_Disable / Enable pair might be needed on any context switch, but if you set all your thread stacks like this, the MPU at least buys you something w/out the need to alter RTX.
Stuart