MPU region zero attribute update for supervisor mode

[Satyajit_Patil]

Hi, I am facing issue for forcing Memory restrictions while servicing ISR.

Background - 
I am developing an OS as per AUTOSAR sws. The OS handles category 2 ISR (handles means - stores the context of preempted entity and initializes new context for ISR as per configured properties and ISR should run in that context). While handling this operation, OS will manually load the context (R0-R12 GPR, LR, PC, BASEPRI, CONTROL, SP registers) and jump to ISR (PC will be updated with the ISR entry function address). But, using this approach, the ISR runs in supervised mode as core is in handler mode. 
I had to do it because, the peripheral interrupt flag will be cleared in peripheral specific ISR (which will be loaded by OS from a common CAT2 ISR handler). And, if OS is relying on exception exit to automatically load the stack frame (by hw), then core is checking for pending exception/interrupt, and the signal would be still active as flag is not cleared. So, execution gets stuck in the common CAT2 ISR handler and exception exit instruction.

So, I had to run ISR in privilege mode.

Now, I have implemented memory protection. And, ISR should have memory restrictions.
I have configured Region zero with r-w-x access in supervised mode which will be used by OS, as by design OS will remain in supervised mode. And, rest of the regions would be used by tasks/ISR. 
For this example, Region 1 will be stack start and end address of ISR, and region2 would be private data section start and end address. 
But, as ISR is running in supervised mode, I could not differentiate ISR access privileges from OS's access privileges. 

I tried with a different approach, which used PID. I kept region zero and one reserved for OS. Region-0 has r-x access and region-1 has only w access in supervised mode. Both regions are overlapping with start add '0x00' and end add '0xFFFFFFFF'.
I mapped region-1 with a PID '0x10', so that only OS would have access to this region, no other region is enabled with PID check. But, this is causing a bus fault with instruction prefetching problem. Also, device is resetting and not going to bus fault or any fault handler. Also, this fault is not generated by MPU.

So, the question is - 1. Is the handling of ISR in handler and hence in supervised mode approach write or wrong? Is there any other way.
                                    2. If not, then how can I differentiate OS's and ISR's access privileges for MPU. 


Thanks in advance!!!!

[danielmartynek]

Hi @Satyajit_Patil,

The OS design is outside the scope of our complementary online technical support.

I understand that you want to restrict ISR memory access to OS memory. However, since both the OS and ISRs run in privileged mode, the MPU cannot differentiate between them based on privilege level alone.

As you correctly mentioned, using the PID (Process ID) mechanism is the only hardware-supported method to distinguish access rights between the OS and ISRs when both operate in privileged mode.

The MPU supports PID-based access control, allowing different access rights to the same memory region depending on the active PID. To implement this:

• Assign a unique PID to the OS and another to each ISR or ISR group.
• Before jumping to an ISR, switch the MCM_PID register to the ISR’s PID.

Note: MCM_PID can only be written in Supervisor mode.

Regarding the fault exception:
Since you’re observing a reset, it’s likely a core lockup reset (RCM_SRS[LOCKUP]), which typically occurs due to an exception during vector fetch. Please verify the MPU region configuration for the memory area where the vector table and handler code reside.

You also mentioned a bus fault. Could you please dump and share the MPU register values at the time of the exception?

Keep in mind: All MPU violations trigger a Bus Fault exception, not a MemManage exception, because the MPU is implemented on the bus level, not the core.

Regards,

Daniel

[Satyajit_Patil]

Thanks Daniel, for the reply!!!
You are right, fault exception is triggering due to lock up.

Regarding using PID to distinguish access rights between the OS and ISRs, If we consider an example -
Region zero is configure with r-w-x access for complete memory map for OS with PID '0x10' and region one configured for ISR with a unique PID, and the region address would be some small private data section or stack (which will be overlapping on region zero).

So, OS will change the PID to ISR's PID right before switching to ISR. Now, ISR will execute normally, but once its execution is completed OS has to restore back the preempted entity's (task or another isr) context. OS would try to regain its access rights as current PID is different that OS's PID. But OS won't be able to update PID as the MISC_PID register address is not currently in any active MPU region.

So, would u suggest allocating a different MPU region for that register access? That region should not be enabled with PID hit check, right?

Also, this comes with a risk that an ISR can update MISC_PID.

This all troubles are coming because ISR has to be handled in privileged mode. Isn't there any other way?

[danielmartynek]

Hello @Satyajit_Patil,

Are you currently experiencing this issue with MCM_PID writes, or was that just provided as an example?

For the S32M24x series, the MPU does not protect peripheral registers. However, I’m not entirely certain about the MCM, since it resides on the Private Peripheral Bus (PPB). Let me confirm that and get back to you.

[danielmartynek]

Hi @Satyajit_Patil,

Can you please specify the part number?

[Satyajit_Patil]

It is NXPS32M244

[Satyajit_Patil]

A few more inputs on this topic - 
1. I am not changing any debugger privileges in region zero.
2. No other system level operation than clearing the interrupt flag can be done inside ISR.
3. I am not using core MPU but controller's MPU (by nxp)