4.2 Diagnostic Mechanisms

Actions needed to ensure that the mechanism, as envisioned, works correctly. Usually this refers to the register or operational mode settings. In case of additional device resources used for the diagnostic mechanism implementation, initialization refers only to these resources.

The initialization of the module used in the application is application-dependent and is a responsibility of the System Integrator. All registers are able to be read during this process. The System Integrator shall determine the number of registers to read and modifications needed after the registers are read.

Describes how the test result is obtained. There are two main options:

Software: The test result is obtained with a software operation executed on an attached SoC.

Hardware: The test result is obtained through an involved hardware item inside the device (for example, internal safety mechanism).

Note that there are also two additional sub-options:

• Software requiring hardware support other than the the device (for example, monitoring the clocks using an asynchronous timer module of the MCU).
• Hardware requiring software support.

This describes when the routine should be executed. In general, some of the routines are “destructive” in the sense that they will corrupt the content of the memory and/or registers; other routines are not. Four possible options are considered in this document:

On start-up: This is the case when running the diagnostics corrupts the content of the memory/registers, or the execution time of the diagnostics is too long to be run during normal operation of the device when executing the application code.

On demand: This is not a destructive mechanism. The diagnostics measure is run when a fault is detected.

Periodic: This is not a destructive mechanism. The diagnostic routine is called at specific instants in time based on the application. This option allows the application to run diagnostics that require relevant execution times at reasonable instants that do not impact the behavior and performance of the application.

Continuous: This is not a destructive mechanism. Some diagnostics, by their nature, can be or are run continuously without impacting the application’s behavior or performance.

Note that the tables provide suggestions only. It is the responsibility of the System Integrator to make the final decision regarding the periodicity.

This identifies a percentage of the coverage that can be achieved using the corresponding measure. It has three possible values:

Low = 60%

Medium = 90%

High = 99%

These values are used in the overall FMEDA computations and for determining the ASIL level.

This highlights if the diagnostic tests operate on ad hoc data or use the data that are normally managed by the application while running. There are two options:

• Dependent: The tests and their results depend on the data being operated upon the device during the application code execution.
• Independent: The tests and their results depend on data that are specified by the tests themselves. This is the usual case for diagnostics run on start-up. (See information in the Periodicity row of this table, above.)

The boot_status::status field indicates boot not started, boot in-progress, boot fail, or boot success.

The boot_status::fallback_boot bit indicates if the upgrade firmware image was requested but was not present or could not be booted and instead the golden firmware image was booted.

The boot_status::recovery_boot bit indicates if the device attempted to boot the golden firmware image but it was not present or could not be booted and instead the recovery firmware was booted.

The boot_status::flash_image_type indicates whether golden or upgrade firmware was booted (only valid when recovery_boot is 0).

The System Integrator determines the appropriate action based on system requirements and capabilities.

An initial check should be done by rebooting the device. This is possible in two ways: (1) power cycling or (2) using one of the reset mechanisms in the reset_ctrl register.

The System Integrator determines the appropriate action based on system requirements and capabilities.

An initial check should be done by rebooting the device. This is possible in two ways: (1) power cycling or (2) using one of the reset mechanisms in the reset_ctrl register.

This test confirms proper SPI or I²C communication by writing to a register and reading back the value.

Process: Test SPI or I²C functionality by enabling or disabling any output by setting the corresponding output_mode::signal_format register field. Compare write value to read value and also check output responds appropriately.

The System Integrator determines the appropriate action based on system requirements and capabilities.

An initial check should be done by writing the value 14 decimal to the page_sel register and then reading the page_sel register and comparing the value read to the value written.

Input Process: The error condition is set up for selected GPIO FuSa fault conditions.

Process: Choose the appropriate GPIO functions for test.

In the ready state, set the failure condition.

Validate that the GPIO flag responds to each condition change.

Remove the condition and reset the GPIO flags.

Example:

The GPIO flag should set if the failure mode is APLL loss of lock, and the clock or crystal is disconnected from the OSCI pin while the device is operating.

A second example would be GPIO controlling the output_squelch::en bit if SoC can monitor the output clock.

For GPIO configured to follow a status bit, if the GPIO pin does not change states then an error has occurred.

For GPIO configured to control a control bit, if the function controlled by the control bit is not affected then an error has occurred. Note that the control bit itself is not affected by the GPIO, only the hardware controlled by the control bit is affected.

The System Integrator determines the appropriate action based on system requirements and capabilities.

An initial check should be done by rebooting the device. This is possible in two ways: (1) power cycling or (2) using one of the reset mechanisms in the reset_ctrl register.

The System Integrator determines the appropriate action based on system requirements and capabilities.

The device can be configured to automatically react to reference clock failure by (a) DPLL automatically selecting the next highest priority valid reference clock signal, or (b) DPLL automatically transitioning to holdover state.

The System Integrator determines the appropriate action based on system requirements and capabilities.

The device can be configured to automatically react to several DPLL conditions including loss-of-lock, lock, phase-slope limit hit and frequency limit hit.