GPIO PADS Safety Mechanisms

[HeebeomPark]

Actually the question is posted in GPIO PADS Safety Mechanisms - NXP Community

So far, there is no answer, I asked again here.

As below, it is captured from FMEDA for GPIO. 

There are two safety mechanisms are placed as below:

• SM4.COMM_SAFEPROT

It was explained in Re: SM4.COMM_SAFEPROT - NXP Community

Thus, in case any communication is used via the GPIO the SM shall be used. Otherwise, it is not necessary.

• SM1.RED_PERI_PHY_SEP : This is rather for 99% DC. In case lower DC, it can be used for the same safety mechanism for the corresponding GPIO PIN? Also to use this safety mechanism, as example with input pins, the two external pins shall be used? Otherwise, without any HW configuration, it can be used?   How shall it be enabled? 

Also, it is used for eDMA_CHMUX. How the SM cover the failure mode (Wrong configuration of eDMA leading to wrong channel request )? Is there any replacement in case the safety mechanism is not enabled?

The question is , if two of the SM are not used, the same mechanism can be applied for GPIO PIN, which the Integrator makes?  

PTA0		0.0002437306	0.0	Inadequate Drive Stength/Slew Rate	17.0			0.0	0.00004143419		• SM4.COMM_SAFEPROT  • SM1.RED_PERI_PHY_SEP
				Incorrect dynamic range	16.0			0.0	0.00003899689		• SM4.COMM_SAFEPROT  • SM1.RED_PERI_PHY_SEP
				Output is floating (i.e. open circuit)	17.0			0.0	0.00004143419		• SM4.COMM_SAFEPROT  • SM1.RED_PERI_PHY_SEP
				Output is stuck (i.e. high or low)	17.0			0.0	0.00004143419		• SM4.COMM_SAFEPROT  • SM1.RED_PERI_PHY_SEP
				Unintended pull-down enabled/disabled	17.0			0.0	0.00004143419		• SM4.COMM_SAFEPROT  • SM1.RED_PERI_PHY_SEP
				Unintended pull-up enabled/disabled	16.0			0.0	0.00003899689		• SM4.COMM_SAFEPROT  • SM1.RED_PERI_PHY_SEP

Add tags

[Yashwant_Singh]

Hello,

As stated for SM4.COM_PROT it is applicable only when the associated GPIOs are used for communication purposes.
SM1.RED_PERI_PHY_SEP claims 99% dc owing to the use of physically separate redundant paths for input and outputs signals and the involved input/output modules which are further compared by the application to detect any single point faults as the concept assumes that all safety related signals are implemented redundantly and compared when end to end check is either not appropriate or feasible.
It proposes to have a physically separate paths for the redundant signals to avoid CCFs and so yes two external pins must be used to acquire the safety related inputs making sure that neighboring pins are not used while at that.
This mechanism also covers the failures of the eDMA Channel as the concept assumes the use of redundant peripherals which are assigned to different channel muxes.
However the feasibility of having the redundant paths depend upon the device/system architecture and the peripherals involved.
Refer Section 6.13.2 Detecting random faults of the safety manual for more details on this.

Thanks!

-Yashwant

[HeebeomPark]

Dear Yashwant,

thank you very much for your kind answer.

So, the safety mechanism "SM1.RED_PERI_PHY_SEP" is used when the physically separation of the two inputs in case redundant input is required for GPIO however, from FMEDA, the following is from eDMA.  In case more than two channels of eDMA are used, the safety mechanism  "SM1.RED_PERI_PHY_SEP" shall be enabled? It looks like it is physical separation of the pins. For example, it is related to ADC or some IO that the data is transferred to DMA. In this case, the failure modes can be covered by this mechanism? However, when it comes to SPI message, the safety mechanism still can cover? 

[Yashwant_Singh]

Hello Heebeom,

SM1.RED_PERI_PHY_SEP is to ensure physical separation of data paths inside the device by choosing the appropriate peripheral instances. It involves the use of separate edma channels (associated with distinct DMA channel mux instances) for the redundantly used peripheral instances(allocated to different peripheral bridges if applicable) which enables the SM1.RED_PERI_PHY_SEP and not the other way around. Therefore this safety mechanism must not be enabled.

From the perspective of GPIOs SM4.REDUNDANT_IO is more appropriate which talks about redundantly acquiring the inputs/outputs on non- adjacent GPIOs.

However we understand that the current description of SM1.RED_PERI_PHY_SEP fails to address this efficiently and so we will update it in the next Safety Manual release. Thank you for bringing it to our attention

Thanks!

-Yashwant

[HeebeomPark]

Thank you very much for your great explain. 

Can you clarify again? 

Thus, to cover the failure modes marked in yellow below, the safety mechanism "SM1.RED_PERI_PHY_SEP" shall be enabled or not? Due to the answer such as  "Therefore this safety mechanism must not be enabled.", we need clarification. Should we enable or not enable?

[Yashwant_Singh]

Hello Heebeom,

By "Therefore this safety mechanism must not be enabled" I meant to say that to enable this mechanism you just have to ensure physical separation of data paths inside the device by choosing the appropriate peripheral, DMA mux/channels etc instances which is unlike enabling/disabling other hardware safety mechanisms for example the SWT which provides a dedicated config register to enable/disable the SWT.

Hoping this clears it.

Thanks!
-Yashwant

[HeebeomPark]

Dear Yashwant,

Thank you very much for your answer.

The following is from chapter 6.13.2 from safety manual and your point is that it shall be used in case redundant inputs are used? 

"Functional safety-relevant peripherals and inputs/outputs may be used redundantly when the device architecture and the safety application permits this. Different approaches can be used~, for example:

* implementing a redundant input path (connecting the same sensor to redundant inputs~, connecting two sensors to redundant inputs, or two sensors to two redundant modules), or
* crosschecking I/O operations (using sensor values of different quantities to check for validity),
* perform a plausibility check on acquired or generated data.

It is recommended to use peripherals on different peripheral bridges in case these are available and replicated inputs are implemented that can be accessed by more than one peripheral. This option may not be available on all devices, some do not employ more than one peripheral bridge, some peripherals are only available once, and not all device pins can be connected to more than one peripheral in a redundant manner. (SM1.RED_PERI_PHY_SEP), (SM4.REDUNDANT_IO), (SM4.REDUNDANT_CMP)"