About some safety mechanisms

Hello Arriy,

You are correct that, in most cases, these mechanisms are always enabled since they are built into the hardware although there are some caveats that need to be mentioned in some cases. Also, in most cases the "proof" test is by using a test of function test at boot time or periodically dependent on application requirements.

Glitch Filtering on nRST and nPORRST --> This is a HW feature where glitches are filtered out by hardware. There will be variation in the width of the glitch that will be filtered where the variation is due to silicon manufacturing process/material, supply voltage, and ambient temperature. The values provided in the DS as the limits of the filtering mechanism take the maximum variation into account. Testing of this faulat avoidance mechanism in the application would be very difficult. In effect, you would need to introduce a glitch that is at or below the width specified as the minimum width and evaluate if a reset occurs. The trick would be what would create the glitch within your application/system. Since this isn't practical and isnt detectable for nPORRST, the safety manual does not identify any possible test for diagnostics.

IOMM Master ID Filtering --> In reality, inclusion of this diagnostic should be redacted from the document. IOMM Master ID filtering is not included on the TMS570LS31x/21x devices. There should be no impact on FIT rate metrics, overall safety metrics, or diagnostic coverage as result of the removal of this mechanism. It can be disabled via the safety mechanism customization tab in the FMEDA tool.

Non-Priveleged Bus Master Access --> Again, this is a hardware configuration within the silicon. Some bus masters are considered non-priveledged and, therefore, cannot access registers that are indicated as privileged mode access only. This prevents these but masters from inadvertantly changing registers they are not supposed to in case of errant operation of the non-privilege bus master. This mechanism could be checked by means of a test of function meaning to deliberately program the module/bus master (for example DMA) to access a privilege mode register and recognize that an error occurs. Since no test for diagnostic is indicated by the safety manual and the FMEDA, you would need to add any test of function methods used to the FMEDA as a custom diagnostic.

Privileged Mode Access and Multi-Bit Enable Keys for Control Registers --> Many operationally critical functions are configure or enabled through registers that are accessible in privilege mode only preventing inadvertent access during normal operation by either non-privilege bus masters as indicated above or by use of the operating mode configuration (user vs. privilege mode operation). In addition, we often use multi-bit enable/disable keys for critical functions (for example, ECC enable/disable) so that transient faults/bit flips are less likely to cause unintended operation. Again, test of function can be used to test access privileges (user vs privilege mode) by deliberately accessing privilege mode content while in user mode. Multi-bit keys are more tricky in that there is usually only one combination of the bits within the key that works. Theoretically, you could write all other combinations and assure that only the one is effective. Since this diagnostic is considered as fault avoidance only and not a true diagnostic measure, test for this mechanism is not generally required by the safety standards and doesn't contribute to the overall diagnostic coverage.

Shadow Registers --> These were discussed in a previous post. Shadow registers are any register that maintains its content after a warm reset. This includes the ESM shadow registers, SYSESR, uncorrectable error status registers, uncorrectable addres registers, parity error address register etc. Again, this is listed as a fault avoidance mechanism and has no impact on the overall DC. However, you could force a soft reset and check the content to insure the content is retained for critical registers such as ESM shadow resgister. This could be combined with other test of error path or test of function tests that set the ESM flags.

Bit Multiplexing in xxx memory array --> Again, a hardware mechanism that has to do with how the bits are arranged and accessed within the internal RAM blocks. Also, as with the others in this list, this is a fault avoidance and has no contribution to the overall DC but is critical in the performance of the device in regard to transients resulting from radiation under normal use. There is no way to check for this mechanism other than performing your own radiation testing.

 

Hopefully, these additional explanations are helpful. Let me know if you need additional information.

 

Birkett

Hi Chuck

I appreciate your kindness answer.

I understood several mechanism caveats.

I have an additional question.

If above fault avoidance mechanisms are failure,I can know failure ?

In other words, is there something that clearly indicate an error?(e.g.error flag)

I am glad if you answer each above mechanisms.

Arriy,

The indication methods (or lack of) are listed in the safety manual in appendix A for each item you have listed above. I would urge to have a look there and if you still have questions, come back and I will address them.

Hello Chuck.
I read list of "Action on Detected Fault" of safety manual in Appendix A

I want to add question.
"PMM2:Privileged Mode Access and Multi-Bit Enable Keys for Control Registers" described action when failure is detected "Control registers will not be updated".
Are there actions other than "Control registers will not be updated" when a fault is detected by"PMM2:Privileged Mode Access and Multi-Bit Enable Keys for Control Registers" ?
Do I need to do a FaultInjection test or error monitoring ?

Hello Arriy,

Arriy said:

Are there actions other than "Control registers will not be updated" when a fault is detected by"PMM2:Privileged Mode Access and Multi-Bit Enable Keys for Control Registers" ?

This has really two parts to the answer and is slightly misleading.

For the first part "Privileged Mode Access", if a register is written in a non-privilege mode the register is not changed as the description states. This would be discovered by using the Software read back of written configuration safety mechanism. Testing of this would be a straight forward write to the register in non-privelge mode and the associated readback to insure nothing changes. For longer term monitoring, the Periodic Read back of static configuration registers comes into play to insure the register stays static or, in the case of power management, using the modules in specific power domains that should be enabled to prove they are powered up.

For the second part, if the register is not protected as privilege mode write only and it contains a multi-bit enable key, you could write non-valid values verify the intended operation is not interrupted. In general, though, you would only need to implement the periodic read back of the enable key to insure it doesn't get inadvertently switched to a state you don't want. Alternatively, you could also run a software test of function for the feature that is being enabled/disabled to insure it is still active and functioning properly. The latter method would be more effective since it accomplishes two tasks at once by checking that it is enabled and that it is functioning correctly/as intended.