Scheduler Tasks

Contains API prototypes for Scheduler Tasks. More...

Files
file	tasks_scheduler.c
	Implements APIs 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_InitiateIdleSleep (void)
	Initiates device sleep in Idle mode and optionally enables CRC scan of Flash.

Detailed Description

Contains API prototypes for Scheduler Tasks.

Version

1.0.0-alpha.1

The Scheduler Tasks APIs are made available for scheduling in the Scheduler Task Manager.

Copyright

© 2025 Microchip Technology Inc. and its subsidiaries.

Subject to your compliance with these terms, you may use Microchip software and any derivatives exclusively with Microchip products. It is your responsibility to comply with third party license terms applicable to your use of third party software (including open source software) that may accompany Microchip software.

THIS SOFTWARE IS SUPPLIED BY MICROCHIP "AS IS". NO WARRANTIES, WHETHER EXPRESS, IMPLIED OR STATUTORY, APPLY TO THIS SOFTWARE, INCLUDING ANY IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE.

IN NO EVENT WILL MICROCHIP BE LIABLE FOR ANY INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL OR CONSEQUENTIAL LOSS, DAMAGE, COST OR EXPENSE OF ANY KIND WHATSOEVER RELATED TO THE SOFTWARE, HOWEVER CAUSED, EVEN IF MICROCHIP HAS BEEN ADVISED OF THE POSSIBILITY OR THE DAMAGES ARE FORESEEABLE. TO THE FULLEST EXTENT ALLOWED BY LAW, MICROCHIP'S TOTAL LIABILITY ON ALL CLAIMS IN ANY WAY RELATED TO THIS SOFTWARE WILL NOT EXCEED THE AMOUNT OF FEES, IF ANY, THAT YOU HAVE PAID DIRECTLY TO MICROCHIP FOR THIS SOFTWARE.

UML Class Diagrams

UML Activity Diagrams

UML State Machine Diagrams

Function Documentation

T_InitiateIdleSleep()

void T_InitiateIdleSleep

(

void

)

Initiates device sleep in Idle mode and optionally enables CRC scan of Flash.

Todo

The T_InitiateIdleSleep function has not yet been implemented. Instead, a function prototype is provided to give an indication of how it will function.

SUBJECT TO CHANGE: This function sets the device in the Idle sleep mode, enables sleep and issues a sleep instruction. Since the CRCSCAN is only able to scan the Flash in Idle sleep, this Task can optionally start a scan of a Flash section before entering sleep using a macro config.

Warning

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 automatically aborted in hardware and a ERRID_VREGWARN_SERR is reported.

Note

The Synchronous Watchdog (SWDT) stops counting while in Idle sleep. For scheduling of this Task, see DUR_INITIATE_IDLE_SLEEP.

Definition at line 146 of file tasks_scheduler.c.

T_RunNextLatentFaultDiag()

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.

Note

For scheduling of this Task, see DUR_RUN_NEXT_LATENT_FAULT_DIAG.

Diagnostic functions in the order they are queued to be run:

• MW_DiagRamParity
• MW_DiagNvmParity
• MW_DiagRamEcc
• MW_DiagNvmFlashEcc
• MW_DiagClockCfm0
• MW_DiagClockCfm1
• MW_DiagClockCfd0Begin
• MW_DiagVmonOverBegin
• MW_DiagNvmEepromEcc
• MW_DiagSwdtExpire
• MW_DiagErrorChannelSplim
• MW_DiagErrorChannelCfd0
• MW_DiagErrorChannelCfd1
• MW_DiagErrorChannelCfm0
• MW_DiagErrorChannelCfm1
• MW_DiagErrorChannelEeprom
• MW_DiagErrorChannelEvsys0
• MW_DiagErrorChannelEvsys1
• MW_DiagClockCfd1Begin
• MW_DiagVmonUnderBegin

Note

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.

Warning

Diagnostics temporarily disable the safety mechanisms under test while in Mission Mode, potentially masking true faults during execution. All the diagnostic functions 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 require 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 is assumed that one CFD and one CFM is continously 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 must 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.

Note

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 at on startup, or leads to unsafe behaviour if used while in Mission Mode.

Optional diagnostic configuration macros:

• DIAG_PERIODIC_CFM0
• DIAG_PERIODIC_CFM1
• DIAG_PERIODIC_CFD0
• DIAG_PERIODIC_CFD1
• DIAG_PERIODIC_VMON
• DIAG_PERIODIC_SWDT_EXPIRE
• DIAG_PERIODIC_ECC_EEPROM
• DIAG_PERIODIC_ERRCH_SPLIM
• DIAG_PERIODIC_ERRCH_CFD0
• DIAG_PERIODIC_ERRCH_CFD1
• DIAG_PERIODIC_ERRCH_CFM0
• DIAG_PERIODIC_ERRCH_CFM1
• DIAG_PERIODIC_ERRCH_EEPROM
• DIAG_PERIODIC_ERRCH_EVSYS0
• DIAG_PERIODIC_ERRCH_EVSYS1

Warning

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.

MISRA C:2012 Deviation

Advisory: misra-c2012- 8.9
Justification: This function uses an array containing a function pointer and an Error ID for up to 20 diagnostics to implement the diagnostic queue under conditional compilation. To keep the implementation more readable, the array is defined at file scope rather than block scope, even though it is only used by this single function. Since this design is thoroughly tested and does not introduce unexpected behavior, the deviation is deemed safe.

Definition at line 128 of file tasks_scheduler.c.