FuSa 8-Bit Libraries Safety Framework
Loading...
Searching...
No Matches
Startup Tasks

Contains API prototypes for Startup Tasks. More...

Files

file  tasks_startup.c
 Implements APIs for Startup Tasks.
file  tasks_startup_callbacks.c
 Implements API for Startup Tasks callback example.
file  tasks_startup_callbacks.h
 Contains API prototype for Startup Tasks callback example.
file  tasks_startup_private.c
 Implements private function APIs for tasks_startup.h.
file  tasks_startup_private.h
 Contains private function prototypes for tasks_startup.h.

Functions

void T_HandlePreStartupErrors (void)
 Retrieves and validates stored Pre-startup error flags from persistent memory and reports them to the Error Handler.
void T_InitSafetySystem (void)
 Initializes the Safety System according to Assumptions of Use and user configurations.
void T_RunStartupDiagnostics (void)
 Runs all enabled startup diagnostics and reports any detected faults to the Error Handler.
void T_StartMissionMode (void)
 Transitions the device from Safe State into Mission Mode.
void T_HandleResetReason (void)
 Retrieves and validates stored reset info from persistent memory and issues configurable callback for handling.
void T_ResetReasonExampleCallback (resetInfo_t resetInfo)
 Demonstrates an implementation of a Handle Reset Reason callback function.

Detailed Description

Contains API prototypes for Startup Tasks.

Version
1.0.0-alpha.1

The Startup Tasks APIs are used by the Startup Task Manager to initialize the Safety System.

UML Class Diagrams

UML Activity Diagrams

UML Sequence Diagrams

Function Documentation

◆ T_HandlePreStartupErrors()

void T_HandlePreStartupErrors ( void )

Retrieves and validates stored Pre-startup error flags from persistent memory and reports them to the Error Handler.

This function is responsible for retrieving and validating error flags stored in persistent memory. If the flags are reliable, all stored flags are evaluated and handled using EH_HandleError.

The error flags are stored in persistent memory by T_EnsureSafeState for safe I/O faults and by T_RunResetDiagnosticFsm when it comes to Pre-Startup diagnostics. If the error flags in persistent memory is determined to be unreliable, it is reported to the Error Handler with the ERRID_GPR_FLAGS Error ID without reporting the stored errors.

Note
This stored error flags can be unreliable by either being corrupted, i.e. the read data is not equal to the data being stored due to bit flips, or if the stored data was unreliable to begin with. The latter can occur if the pre-startup sequence did not execute normally, leading to potential false positives or negatives as T_RunResetDiagnosticFsm aborts. An example of this is if T_RunResetDiagnosticFsm reads corrupted flags or if a combination of uncorrupted values makes no sense for the FSM.
If the flags is not corrupt but not reliable due to T_RunResetDiagnosticFsm aborting the safe I/O fault flag is also not handled. This is done since it is stored in the same persistent memory as the diagnostic fault flags.
If the flags are deemed unreliable due to T_RunResetDiagnosticFsm aborting, the safe I/O fault flag is ignored and not reported. This is done despite the safe I/O fault flag being set by T_EnsureSafeState, because it shares the same persistent memory as the diagnostic fault flags.
Warning
This function only clears flags and not values from persistent memory since the optional T_HandleResetReason require access to the stored reset reason. If a call to EH_HandleError due to unreliable values causes a device reset, the T_RunResetDiagnosticFsm might abort causing the same unreliable values to be propagated back to the Handle Pre-Startup Errors function. To avoid this, the Error Handler callback handling the ERRID_GPR_FLAGS Error ID should clear the persistent values. If the Handle Reset Reason task is omitted, a task to clear the persistent values should be added as a separate application task in the startup schedule.

Definition at line 51 of file tasks_startup.c.

◆ T_HandleResetReason()

void T_HandleResetReason ( void )

Retrieves and validates stored reset info from persistent memory and issues configurable callback for handling.

This function is responsible for retrieving and validating the reset reason stored in persistent memory. If the reset reason is valid, it then issues a configurable resetReasonCallback to handle the reset reason. If the reset is due to a software reset it will also handle the stored Error ID and pass it to the callback.

The reset reason is stored in persistent memory by T_DetermineResetReason. If the reset reason value in persistent memory is determined to be unreliable, it is reported to the Error Handler with the ERRID_GPR_VALS Error ID without calling the callback function. If the stored value itself is not in the valid range of the reset reason type, it will default to RSTRSN_UNKNOWN.

Note
This stored reset information can be unreliable by either being corrupted, i.e. the read data is not equal to the data being stored due to bit flips, or if the stored data was incorrect to begin with. The latter can occur if the pre-startup sequence did not execute normally, leading to potentially overwriting the true reset reason with an error injection reset reason. An example of this is if T_RunResetDiagnosticFsm reads corrupted flags or if a combination of uncorrupted values makes no sense for the FSM.

The Error ID is stored in persistent memory by EH_InitiateSafeState. If the Error ID is valid and is a software reset then the function will retrieve the Error ID. If the stored value itself is not in the valid range of the Error ID type, it will default to ERRID_NONE.

Note
For any reset reason other than a software reset, the Error ID is not read and ERRID_NONE is reported. If no Error ID is stored or the stored value is out of range when the reason is a Software Reset, ERRID_NONE is reported.
For scheduling of this Task see DUR_HANDLE_RESET_REASON.

Definition at line 176 of file tasks_startup.c.

◆ T_InitSafetySystem()

void T_InitSafetySystem ( void )

Initializes the Safety System according to Assumptions of Use and user configurations.

This function initializes device safety mechanisms and safety related features according to safety requirements derived from the Assumptions of Use (AoUs) for the device Technical Safety Concept and Safety Element out of Context (SEooC) definition. This ensures that the Safety System is initialized during the Startup sequence. Some settings are application dependent and can be configured using macros at compile-time. However, some settings require broader application context or is not strictly safety related. These settings should be configured later by the application. Any configuration errors detected are reported to the Error Handler.

Watchdogs: The Watchdog Timer (WDT) is enabled in Normal mode with an initial duration configured by INIT_WDT_DURATION for the duration of the Startup sequence. The Synchronous Watchdog Timer (SWDT) is enabled in clock mode with a fixed open window configured by SWDT_OPEN_WINDOW and an initial closed window configured by INIT_SWDT_DURATION. The register protection feature is enabled to avoid accidental modification, but is not locked since the open window is intended to be updated later.

Clocks: The main clock is set to use the internal high frequency oscillator as the source and to run at a frequency configured by INIT_CLOCK_FRQ and INIT_CLOCK_DIV. The Clock Failure Detect 0 (CFD0) is enabled to monitor the main clock with the internal 32K oscillator as reference. The Clock Frequency Monitor 0 (CFM0) is enabled to monitor the main clock in continuous mode with the internal 32K oscillator as reference, using a tolerance window configured by INIT_CFM0_WIN_LOW, INIT_CFM0_WIN_REF and INIT_CFM0_WIN_HIGH.

Note
CFD1 and CFM1 are only initialized if INIT_REDUNDANT_CFD or INIT_REDUNDANT_CFM is set to ENABLED. If enabled, CFD1 and CFM1 is set to mirror the CFD0 and CFM0 configuration. See tips_and_tricks for how CFD1 and CFM1 can be used if redundant CFD/CFM is disabled.
The CFM0 is initialized with a fixed configuration using the internal 32K oscillator as reference, since this is the only reference with an independent clock source available. However, for more accurate measurements, it is recommended to switch to an independent external oscillator after being initialized by the application. See tips_and_tricks for how to switch to an external oscillator or clock source.

Error Controller: The error controller ALARM state timeout (time until promoting a NONCRITICAL error to CRITICAL) is configured by INIT_ERRCTRL_TIMEOUT. The error controller heartbeat feature is configured by HEARTBEAT_OUTPUT. The criticality configured for each Error ID corresponding to a specific error controller channel (ending with _CH) in errorIdCritLut is translated to a severity for each error channel. The I/O float setting for each channel is configured by INIT_FLOAT_NONCRITICAL and INIT_FLOAT_NOTIFICATION depending on the channel severity.

Warning
If an Error ID channel is set to IGNORE criticality, it will be automatically set to ERRCH_SEVERITY_NONCRITICAL, since this is the default severity of all channels.

Interrupts: The interrupt scheduling and priority is configured by INIT_INT_ROUND_ROBIN, INIT_INT_LVL0_START and INIT_INT_LVL1. All device error interrupt sources are enabled, regardless of the configured criticality of their corresponding Error IDs since:

  • CRITICAL: If the ERRCTRL fails to reset the device, the redundant ISR can do a software reset.
  • NONCRITICAL: If the Error Controller ISR does not trigger, the redundant ISR can handle it.
  • NOTIFICATION: The hardware flag is immediately put into the log for later handling
  • IGNORE: The flag can be immediately cleared without further action.

All sources in the following interrupt vectors are enabled:

  • Brown-out Detector (BOD) error interrupts
  • Error Controller (ERRCTRL) error interrupts
  • Clock Controller (CLKCTRL) error interrupts
  • Sleep Controller (SLPCTRL) error interrupts
  • Synchronous Watchdog (SWDT) error interrupts
  • NVM Controller (NVMCTRL) error interrupts
  • RAM Controller (RAMCTRL) error interrupts
Note
The Error Controller interrupt type is configured to not use NMI, since this is not supported in the Interrupts Task Manager.
CRC Scan (CRCSCAN) interrupts are not enabled here since usage is application dependent. When enabled, the interrupt type is assumed to be configured to not use NMI, since this is not supported in the Interrupts Task Manager.

Power: Sets the device sleep mode to SLP_MODE_IDLE since deeper sleep modes requires special consideration. See TM_Shutdown. The Voltage Regulator Monitor (VMON) mode and sleep mode is configured by INIT_VMON_FULL_POWER_MODE and INIT_VMON_ALWAYS_ON. The Voltage Level Monitor (VLM) level threshold (percentage relative to Brown-out Detector level) and trigger is configured by INIT_VLM_THRESHOLD and INIT_VLM_TRIGGER.

Warning
It is assumed that the BOD is already enabled through User Fuses (BODCFG) for the VLM config to take effect. If not enabled, an error is reported.

Memories: Enables the Stack Pointer Limit (SPLIM) feature by setting a RAM address limit configured by INIT_STACK_LIMIT and optionally locking that value depending on INIT_STACK_LIMIT_LOCK configuration. The NVM ECC behaviour when reading all ones from an address is configured by INIT_NVM_ECC_ALL_ONES.

Definition at line 74 of file tasks_startup.c.

◆ T_ResetReasonExampleCallback()

void T_ResetReasonExampleCallback ( resetInfo_t resetInfo)

Demonstrates an implementation of a Handle Reset Reason callback function.

Parameters
resetInfoA structure containing the Reset Reason as determined in T_DetermineResetReason and the software reset Error ID as determined in EH_InitiateSafeState. The values are validated in T_HandleResetReason before the callback is called.
Todo
This example callback has not been implemented and simply returns without further action.
Warning
An application specific Reset Reason handling callback must be implemented for proper reset handling.

Definition at line 26 of file tasks_startup_callbacks.c.

◆ T_RunStartupDiagnostics()

void T_RunStartupDiagnostics ( void )

Runs all enabled startup diagnostics and reports any detected faults to the Error Handler.

This function runs a series of startup diagnostics to detect any latent faults in the system by performing error injections in the hardware safety mechanisms on the device. Any faults detected are reported to the Error Handler.

Note
Some of the diagnostics can be configured to be excluded from compilation if the hardware safety mechanism is not used by the application or if alternative diagnostics are implemented and called elsewhere with higher fault coverage. See each configuration macro documentation for more information on effects and consequences.

Configuration Macros:

Note
The MW_DiagClockCfm0 and MW_DiagClockCfm1 diagnostics are invoked at the beginning of Run Startup Diagnostics if enabled by DIAG_STARTUP_CFM0 and DIAG_STARTUP_CFM1. This is done to detect any faults in the CFM (Clock Frequency Measurement) safety mechanism, making sure that the main clock has one active monitor, before initiating the more time-consuming CFD (Clock Failure Detection) diagnostics.
Warning
The MW_DiagClockCfd0Begin and MW_DiagClockCfd1Begin diagnostics only initiate the diagnostics, while MW_DiagClockCfd0End and MW_DiagClockCfd1End complete them. The end diagnostics are not called as part of the Run Startup Diagnostics function and must be scheduled as part of the TM_Startup schedule if the begin diagnostics are enabled by DIAG_STARTUP_CFD0 and DIAG_STARTUP_CFD1. It is the user's responsibility to determine when to call the end diagnostic to avoid calling it before the diagnostic is complete. See tips_and_tricks for more information on using the CFD diagnostics.
If both CFD0 and CFD1 diagnostics are enabled during startup, both diagnostics run concurrently. This is might be acceptable depending on the application since the device is in a safe state during startup.

Definition at line 103 of file tasks_startup.c.

◆ T_StartMissionMode()

void T_StartMissionMode ( void )

Transitions the device from Safe State into Mission Mode.

This function is responsible for transitioning the system from the Safe State used while running the Startup sequence to the Mission Mode state required when running the application. The Watchdog is configured to run in Window mode (WWDT) with a timeout configured by WWDT_OPEN_WINDOW and WWDT_CLOSED_WINDOW to ensure the device meets the Fault Detection Time Interval (FDTI). Global interrupts are enabled to ensure that any detected hardware errors are reported and handled. If STRICT_SAFE_STATE is enabled, this function also disables force floating (tri-stating) of all I/O pins simultaneously, ensuring a strict transition between the Safe State and Mission Mode even if peripherals and PORT pins have been initialized. Any detected configuration errors are reported to the Error Handler.

Note
The Watchdog Window mode configuration does not take effect until the first clear (WDR instruction) is executed.
The settings for WWDT_OPEN_WINDOW and WWDT_CLOSED_WINDOW are intended to configure a total timeout equal to or smaller than the FDTI of the device. See the watchdog sections in tips_and_tricks for methods to increase the effective granularity and length of the WWDT timeout to better match the FDTI requirements of the application.

Definition at line 151 of file tasks_startup.c.