 |
AVR SD Safety Framework 1.0.0
|
|
AVR SD Safety Framework 1.0.0
|
Contains API prototypes for Scheduler Tasks. More...
Files | |
| file | tasks_scheduler.c |
| Implements APIs for Scheduler Tasks. | |
| file | tasks_scheduler.h |
| Contains API prototypes for Scheduler Tasks. | |
Macros | |
| #define | DIAG_QUEUE_START 0U |
| The index of the first diagnostic function in the diagnostic queue. | |
Functions | |
| void | T_RunNextLatentFaultDiag (void) |
| Runs a different latent fault diagnostic function each time it is called. | |
| void | T_EnterIdleSleep (void) |
| Enters device sleep in Idle mode and optionally enables and handles CRC Scan of Flash. | |
Contains API prototypes for Scheduler Tasks.
The Scheduler Tasks APIs are made available for scheduling in the Scheduler Task Manager.
| #define DIAG_QUEUE_START 0U |
The index of the first diagnostic function in the diagnostic queue.
| void T_EnterIdleSleep | ( | void | ) |
Enters device sleep in Idle mode and optionally enables and handles CRC Scan of Flash.
This function enters Idle sleep by enabling sleep and issuing a sleep instruction. The device remains in sleep until an interrupt configured by the application occurs. Since CRCSCAN can only scan Flash during Idle sleep, this Task can optionally start a CRC scan before sleeping when PERIODIC_CRCSCAN is enabled. If not enabled, the remaining CRC feature descriptions do not apply.
If CRC Scan is enabled, this Task enables scanning of the next enabled Flash section in the queue. When the device enters Idle sleep, CRCSCAN computes the CRC for that section and automatically compares it to the stored checksum. If a mismatch is detected, it is reported to the Error Handler.
If the device wakes up before completing a CRC Scan, the scan continues the next time this Task is called and the device re-enters Idle sleep. A completed scan does not wake the device. However, once the device wakes up for another reason, the result is checked and reported. The next time this Task is called after a completed scan, a new CRC scan is started.
Which sections to scan and the CRC width (16-bit or 32-bit) are configured using CRCSCAN_BOOT_SECTION, CRCSCAN_APPCODE_SECTION, CRCSCAN_APPDATA_SECTION and CRCSCAN_CRC32. If more than one section is enabled, each section is scanned in turn using Round Robin.
Before starting a scan of the next section, the CRCSCAN error injection diagnostic can optionally be executed if DIAG_PERIODIC_CRCSCAN is enabled. See MW_DiagCrcScan for more information. The diagnostic involves briefly entering Idle sleep and automatically waking up to complete the diagnostic. Once completed, a scan of the next section is started before entering normal Idle sleep. If no sections are enabled, no scan is started and the diagnostic runs each time this Task is called.
It is possible to enable periodic wakeup so the device wakes up after the next 32 Flash words have been scanned if PERIODIC_CRCSCAN_PIT is enabled. This effectively changes the behavior of this Task to "scan the next 32 words, then return to the application". By calling this Task repeatedly, each enabled Flash section is eventually fully scanned. Once a scan is completed, the result is reported and a new scan is started as normal.
T_HandleCrcInterrupt to clear the PERIOD flag. If DIAG_PERIODIC_CRCSCAN is enabled, this function also depends on T_HandleCrcInterrupt to handle the CRCSCAN interrupt required to complete the diagnostic.
A suitable wakeup source must be configured and global interrupts must be enabled before calling this Task. If global interrupts are not enabled, the sleep instruction is aborted in hardware and a sleep error hardware flag is set. If no suitable wakeup source is enabled, the device will not wake up.
This function does not re-enter sleep if an unexpected interrupt wakes up the device. The application must handle unexpected wakeups to account for this scenario.
The Synchronous Watchdog (SWDT) stops counting while in Idle sleep. For scheduling of this Task, see DUR_ENTER_IDLE_SLEEP.
This function assumes no CRC Scan of Flash is already in progress from another source. If it is, an ERRID_INIT_CRCSCAN error is reported.
ERRID_INIT_CRCSCAN error is reported and the scan is skipped. See MW_StartCrcManualMode and MW_EndCrcManualMode for more information.
If the CRCSCAN error injection diagnostic is enabled, it aborts and returns an error if either a Flash section scan or a manual mode calculation is in progress.
MW_EnableCrcScan and MW_DiagCrcScan for more details.
When periodic CRC Scan is enabled, this Task assumes no other part of the system enters Idle sleep to continue the scan or aborts an ongoing scan. If it does, the ongoing scan may complete during that sleep cycle. As a consequence, this Task may re-enter sleep without enabling a new scan of the next section. However, once it wakes up, the result is reported as normal and the next section is scanned the next time this Task is called.
If another part of the system completes or aborts a CRC Scan and the application relies on the PERIODIC_CRCSCAN_PIT interrupt to wake up the device, this Task may enter Idle sleep without a wakeup source, since a new CRC Scan is not enabled yet.
The following Error IDs may be reported to the Error Handler by this Task:
| void T_RunNextLatentFaultDiag | ( | void | ) |
Runs a different latent fault diagnostic function each time it is called.
This function runs one diagnostic function from a queue 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. A state machine ensures that a different diagnostic function in a queue is run every time the Task is called. Once every diagnostic function has been run it wraps around to run the first diagnostic function in the queue.
For applications that reset often, it should be sufficient to perform latent fault diagnostics at startup. However, this Task is provided for periodic scheduling in Mission Mode for applications that require periodic Latent Fault detection without resetting. It is assumed that the Latent Fault Detection Time Interval (LFDTI) is much longer than the Fault Detection Time Interval (FDTI) of the application. By running one diagnostic in the queue each time the Task is queued, all diagnostics will eventually have run within LFDTI.
For scheduling of this Task, see DUR_RUN_NEXT_LATENT_FAULT_DIAG.
Diagnostic functions in the order they are queued to be run:
The queue order is selected so that, if all are enabled, the CFM diagnostics are completed before the lengthy CFD0 diagnostic to avoid a situation where both main clock monitors (i.e., CFM0 and CFD0) are disabled simultaneously. The CFD1 and VMON undervoltage diagnostic are separated from the CFD0 and VMON overvoltage diagnostics in the queue to avoid a situation where a new diagnostic is begun before the previous is completed.
Diagnostics temporarily disable the safety mechanisms under test while in Mission Mode, potentially masking true faults during execution. All the diagnostic functions in this queue also disable global interrupts during execution, which may delay the servicing of other error-handling interrupts. However, each diagnostic function execution time is still within the lowest supported device Fault Detection Time Interval (FDTI) and statistically the probability that the error occurs while doing the diagnostic is low.
Each diagnostic requires entering the Error Controller CONFIG state multiple times as part of the diagnostic execution. If enabled, the Error Controller heartbeat signal is temporarily forced low while in the CONFIG state. Any external system receiving this signal needs to account for this. See HEARTBEAT_OUTPUT for more information.
If a CFDn diagnostic is enabled, the CFDn error interrupt will remain disabled until the end diagnostic function is called. If enabled, the application is responsible for ending the diagnostic by calling MW_DiagClockCfd0End or MW_DiagClockCfd1End once the error injection is completed. It is the responsibility of the application to ensure sufficient time separation for the error injection to be completed. See Tips and Tricks on using the CFDn error injection diagnostics.
While not in a Safe State, it is assumed that one CFD and one CFM is continuously monitoring the main clock. To maintain coverage during error injection diagnostics on one CFM/CFD, it is recommended that the application ensures the other CFM/CFD is configured to monitor the main clock. See INIT_REDUNDANT_CFD and INIT_REDUNDANT_CFM for an alternative to performing CFD/CFM error injection diagnostics and Tips and Tricks on using the CFDn and CFMn error injection diagnostics.
Some of the diagnostics can be configured to be excluded from compilation if the hardware safety mechanism is not used by the application, only needs to be run on startup, or leads to unsafe behaviour if used while in Mission Mode.
Optional diagnostic configuration macros:
It is recommended to carefully consult the API documentation for each optional diagnostics as some of them can lead to unexpected behaviour if not used as intended.
The following Error IDs may be reported to the Error Handler by this Task:
1.17.0