GPIO ASIL protection

[mattiasecchiaro]

Dear support,

We use the S32K148 MCU in an automotive application with some ASIL B functionalities.

We want to prevent non safe code (unprivileged code) from changing the GPIO outputs.

Safe code (Highest ASIL level of the application) must still be able to change GPIO Outputs at all times (not only at startup but also at runtime).

It seems that we cannot protect the GPIO controller using MPU: p.281 of S32K-RM.pdf rev 13.

We know that the mux of the GPIOs can be protected, S32K1xx_Memory_Map.xlsx:

However the S32K148 doesn’t seem to allow to configure the access rights of the GPIO controller.

The aliased peripheral does not have any registers allowing privilege control.

We thought we could use the clock gating of the SIM module (which himself can be protected from unprivileged access), but on p.169 of S32K-RM.pdf rev 13, it says that clock gating is not available for our MCU S32K148, only for S32K11x variants.

Is there a way to protect the access to the GPIOs outputs for S32K148?

Thanks.

[aarul]

Hello

In the first snippet you posted, there is a statement that says "Peripheral access protection is supported by AIPS". Can you please evaluate and confirm if the following register can enable protection to GPIO accesses that you are looking for or you are looking for something different?

Regards

-Aarul

[mattiasecchiaro]

Hello Aarul,

thanks for the answer.

We tried, but, as already written, the S32K148 doesn’t allow to configure the access rights of the GPIO controller (the aliased peripheral does not have any registers allowing privilege control).

You can also look at the other snippets posted, taken from file S32K1xx_Memory_Map.xlsx (sheet Peripheral Memory Map).

Regards,

Mattia.

[aarul · Accepted solution]

Hello

You can implement software measure and application-level measures to detect such failures. Few suggestions:

1. You can reduce the probability of this condition by disabling the access to the GPIO software driver (which resides in memory) to non-safe code. 

2. If you have application level measures such as redundant GPIO pins and loop-back implemented (refer to "Section 5.7.2 I/O functions" in Safety Manual), then a corruption by non-safe code can be detected. 

3. You can perform SW tests (read-back) to ensure that the values in the GPIO before execution of non-safe code and after execution of non-safe code are same. 

4. If you very few pins to be used as GPIO, you can even consider using a different peripheral (like TRGMUX). 

Hope this helps,

Regards

-Aarul

[mattiasecchiaro]

Hello,

thanks for the suggestions.

Solution 1 seems not to completely protect GPIOs, since the registers are still accessible.

Solutions 2 and 4 involve changes in hardware that we cannot manage now.

So, we'll go for solution 3 (SW readback of the GPIO registers).

Regards,

Mattia.