RTD 4.0 safety application with a multi-core setup (esp. Port module)

[AndreasStolze]

Hi all,

I've a couple of questions regarding the use of the RTD 4.0 Port module in a safety context and a multi-core setup.
We are targeting ASIL C. We're using the S32K358, the functional safety core (master core) is M7_0 with M7_1 in lockstep configuration. A QM only core is realised with the M7_2 core.

Used references:
- My NXP post about general multi-core use: https://community.nxp.com/t5/S32K/Usage-of-RTD-4-0-MCAL-drivers-in-a-multi-core-application/td-p/183...
- Application Note "Multi-Core Implementation in RTD of S32K3" (Rev. 1, 07/2022)
- RTD Software Safety Manual for S32K3_S32M27X (Rev. 13.1 — 4 December 2023)
- S32K3xx Functional Safety Application Note (Rev. 0.2 Preliminary Version 06 Feb 2023)

1) Port module with XRDC

As stated in the integration manual of the Port module, it's a Type III multi-core module. According to the multi-core app note, that means that initialisation is done only on one core, the master core. Thus, the master core must access all pad control registers to initialise each pin.

However, with XRDC, I assign a pad to one PDAC, which is then assigned to one core. But then the master core does not have access to these registers?

What approach did NXP think of for this setup?

2) Type III modules and Fully Trusted Environment (FTE)

For RTD as SEooC, assumptions for the integration are stated, the so called FTE.

How can this be achieved with a Type III module? Especially with EA_RTD_00057 and EA_RTD_00058?
As far as I understand, "The codes/constants and variables have GLOBAL scope" would mean that the Port module uses shared RAM. And the QM core will call in QM context the module and access memory.

So how can these assumptions be met in a multi-core setup with different ASIL levels?

Thank you
Andreas

[lukaszadrapa]

Hi @AndreasStolze 

Please notice that S32K358 is still in pre-production status and that mentioned application note has not been officially published yet. Please contact your FAE for further support.
Thanks for understanding.

Regards,
Lukas

[AndreasStolze]

Hi,

after internal discussion, another solution comes to mind:

Can the Port module used in a "single core" configuration in combination with XRDC protection?

This would mean that each core has its own Port module code, its own Port configuration and will call Port_Init itself. XRDC (via the virtual wrapper) will allow only access to the pad control etc. assigned to the core.
You would just need to take care that in each configuration, every port is configured, either as used or untouched, so that no unused pins are default configured and thus triggering an acces protection.

Would this in general be a (better?) approach for Freedom from Interference also for Type II RTD modules?

The same could be done for Type II modules like ADC. Just don't use the multi-core functionality, have each core has its own copy of RTD code and guarantee FFI just by using XRDC?

(Basically the advantage of multi-core functionality is being able to save flash memory size?)

Thanks
Andreas