Interrupt Tasks

Contains API prototypes for Interrupt Tasks. More...

Files
file	tasks_interrupts.c
	Implements APIs for Tasks used by the Interrupt Task Managers.
file	tasks_interrupts.h
	Contains API prototypes for Interrupt Tasks.

Functions
void	T_HandleNmiInterrupt (void)
	Handles Non-Maskable Interrupts (NMI) by reporting the Error ID of any detected faults.
void	T_HandleBodInterrupt (void)
	Handles Brown-out Detector (BOD) Voltage Level Monitor (VLM) interrupt by reporting the associated Error ID.
void	T_HandleClockInterrupt (void)
	Handles Clock interrupts by reporting the Error ID of any detected faults and clearing CFM done flags.
void	T_HandlePowerInterrupt (void)
	Handles power related interrupts by reporting the Error ID of any detected faults.
void	T_HandleSwdtInterrupt (void)
	Handles SWDT interrupts by reporting the Error ID of any detected faults.
void	T_HandleNvmInterrupt (void)
	Handles NVM interrupts by reporting the Error ID of any detected faults.
void	T_HandleRamInterrupt (void)
	Handles RAM interrupts by reporting the Error ID of any detected faults.
void	T_HandleCrcInterrupt (void)
	Handles CRC Flash scanning interrupts by clearing the periodic interrupt bit and reporting the Error ID of a detected fault.
void	T_HandleBadInterrupt (void)
	Handles bad interrupt requests that do not have a corresponding ISR for handling it.
void	T_HandleErrorChInterrupt (void)
	Handles Error Channel interrupts by reporting the sources of the first set Error Channel.

Detailed Description

Contains API prototypes for Interrupt Tasks.

The Interrupt Tasks APIs are used by the Interrupts Task Manager to handle safety system, application and unintentional interrupts.

Copyright

© 2026 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 Sequence Diagrams

Function Documentation

T_HandleBadInterrupt()

void T_HandleBadInterrupt

(

void

)

Handles bad interrupt requests that do not have a corresponding ISR for handling it.

This function is intended to be called when an erroneous interrupt request (IRQ) is issued from a source without a dedicated Interrupt Service Routine (ISR) to handle it. This can occur either due to a hardware fault or due to enabling an interrupt source without including the ISR. In such scenarios, the default ISR is automatically called to handle the IRQ. This function is intended to be called in the default handler and always reports ERRID_BAD_IRQ to the Error Handler. The error is handled according to its configured errCrit_t.

Warning

It is recommended to configure the error handling of ERRID_BAD_IRQ to result in a Safe State transition. This is because there is no attempt at determining the origin of the bad interrupt and an unhandled interrupt flag will continue to issue IRQs forever.

The following Error IDs may be reported to the Error Handler by this Task:

• ERRID_BAD_IRQ Interrupt triggered without an ISR

Here is the call graph for this function:

Here is the caller graph for this function:

T_HandleBodInterrupt()

void T_HandleBodInterrupt

(

void

)

Handles Brown-out Detector (BOD) Voltage Level Monitor (VLM) interrupt by reporting the associated Error ID.

This function reads and clears the Voltage Level Monitor (VLM) interrupt flag of the BOD and reports the corresponding Error ID to the Error Handler. The error is handled according to its configured errCrit_t.

Note

This error is triggered when the Power Supply voltage level crosses the configured

INIT_VLM_THRESHOLD depending on the configured INIT_VLM_TRIGGER.

Note

There is no error channel connected to this error source. For this reason there is no redundant handling of this error. However, if the Power Supply voltage drops even below the BOD threshold, the device is automatically transitioned into a Safe State.

The following Error IDs may be reported to the Error Handler by this Task:

• ERRID_BOD_VLM BOD VLM trigger condition detected

Here is the call graph for this function:

Here is the caller graph for this function:

T_HandleClockInterrupt()

void T_HandleClockInterrupt

(

void

)

Handles Clock interrupts by reporting the Error ID of any detected faults and clearing CFM done flags.

This function reads and clears all interrupt error sources related to the safety mechanisms of the device clock and reports their corresponding Error IDs to the Error Handler. Once all sources are cleared, it also attempts to clear the associated error channels, avoiding double-reporting of errors.

Sources (connected error channel name):

• Clock Failure Detection 0 error (CFD0)
• Clock Failure Detection 1 error (CFD1)
• Clock Frequency Measurement 0 error (CFM0)
• Clock Frequency Measurement 1 error (CFM1)

Note

There are two CFM Done interrupt flags that do not correspond to an actual error that are disabled by default. These flags are cleared in this interrupt without any further action.

Note

For error sources with Error IDs connected to an error channel that is set to CRITICAL criticality, this handler normally does not execute because the Error Controller resets the device. However, if that reset fails, this handler can redundantly attempt to handle the error.

Note

For error sources with Error IDs set to NON_CRITICAL criticality, the redundant

T_HandleErrorChInterrupt Task is also responsible for clearing and handling the error sources and channels. Whichever runs first will normally prevent the other from executing when the interrupt sources are successfully cleared.

Note

For error sources with Error IDs set to NOTIFICATION criticality, the errors are cleared and reported here and handled later in the T_HandleNotificationErrors Task, which also checks and reports any errors that were not cleared in interrupt handlers for redundancy.

Note

This function does not verify whether clearing the error channels was successful. If clearing a channel fails, it is assumed that either the T_HandleErrorChInterrupt or

T_HandleNotificationErrors task will report the error.

The following Error IDs may be reported to the Error Handler by this Task:

• ERRID_CFD0_CH CFD0 detected an error on the monitored clock
• ERRID_CFD1_CH CFD1 detected an error on the monitored clock
• ERRID_CFM0_CH CFM0 detected an error on the monitored clock
• ERRID_CFM1_CH CFM1 detected an error on the monitored clock

Here is the call graph for this function:

Here is the caller graph for this function:

T_HandleCrcInterrupt()

void T_HandleCrcInterrupt

(

void

)

Handles CRC Flash scanning interrupts by clearing the periodic interrupt bit and reporting the Error ID of a detected fault.

This function reads and clears all interrupt sources in the CRCSCAN. If the interrupt indicates that a CRC scan of Flash is completed and an error is detected, it reports the corresponding Error ID to the Error Handler. The error is handled according to its configured errCrit_t.

This function is optionally responsible for reporting completion of the interrupt-based CRCSCAN Error Injection diagnostic if either DIAG_PERIODIC_CRCSCAN or DIAG_SHUTDOWN_CRCSCAN is ENABLED. When MW_DiagCrcScan is called, it enables an error injection CRC Scan and the DONE interrupt before setting the device into Idle sleep. Once the scan is complete, the DONE interrupt wakes up the device. In this case, the diagnostic function relies on the DONE interrupt handler to always call MW_ReportDiagCrcDone if MW_IsDiagCrcOngoing returns true, to clear the DONE flag and avoid reporting the error injection as an actual fault.

Note

If the CRC periodic interrupt during Flash scan feature is enabled, the flag is only cleared without further action.

Note

If the feature to issue a Non-Maskable Interrupt (NMI) request when a CRC error is detected is enabled, this task can still clear the interrupt flags when there is no error. In that case, the check for whether the error flag is set after a completed scan is redundant.

Note

There is no error channel connected to the Flash CRC scan error source. For this reason there is no redundant handling of this error.

The following Error IDs may be reported to the Error Handler by this Task:

• ERRID_CRC_FLASH CRC Scan complete with error or previously unhandled scan result

Here is the call graph for this function:

Here is the caller graph for this function:

T_HandleErrorChInterrupt()

void T_HandleErrorChInterrupt

(

void

)

Handles Error Channel interrupts by reporting the sources of the first set Error Channel.

This function finds the first set error channel, reads and clears all error sources that could trigger that error channel, and reports their corresponding Error IDs to the Error Handler. Once all sources are cleared, it also attempts to clear that error channel, check the status after clearing, and reports any failure to clear.

Note

For error sources with Error IDs connected to an error channel that is set to CRITICAL criticality, this handler normally does not execute because the Error Controller resets the device. However, if that reset fails, this handler can redundantly attempt to handle the error.

Note

For error sources with Error IDs set to NON_CRITICAL criticality, the redundant handlers for interrupt vectors connected to the sources are also responsible for clearing and handling the error sources and channels. Whichever runs first will normally prevent the other from executing when the interrupt sources are successfully cleared.

Note

For error sources with Error IDs set to NOTIFICATION criticality, the errors are cleared and reported here and handled later in the T_HandleNotificationErrors Task, which also checks and reports any errors that were not cleared in interrupt handlers for redundancy.

Note

To keep execution time short, this function only handles one set error channel per call and then returns. The order in which channels are checked starts from the lowest number in the errCh_t enum. This order is not influenced by the errorIdCritLut configuration. As a result, a set NOTIFICATION channel might be cleared before the set NON_CRITICAL channel that actually triggered the interrupt. However, as the sources of all error channels except EVSYS are also connected to other ISRs, those sources would have been handled by different interrupts before being picked up accidentally by the Error Controller triggering by an unrelated NON_CRITICAL channel being set. For this reason, it is assumed that having multiple error channels set simultaneously is highly unlikely. However, if this does occur, a new interrupt request (IRQ) will be issued, ensuring that this task is called again to handle the remaining set channels.

The following Error IDs may be reported to the Error Handler by this Task and correspond to error channel hardware flags or their sources:

• ERRID_VREGFAIL_VOV, ERRID_VREGFAIL_VUV, ERRID_VREGFAIL_CH, ERRID_BUSERR_BUSERR, ERRID_RAM_PARITY, ERRID_NVM_PARITY, ERRID_BUSERR_PARITYD,

ERRID_BUSERR_CH, ERRID_RAM2_ECC2, ERRID_RAM2_COMP, ERRID_RAM2_CH, ERRID_FLASH2_ECC2, ERRID_FLASH2_COMP, ERRID_FLASH2_CH, ERRID_OPC_OPC, ERRID_OPC_PARITYI, ERRID_OPC_CH, ERRID_SPLIM_CH, ERRID_RAM1_CH, ERRID_FLASH1_CH, ERRID_VREGWARN_VDENTER, ERRID_VREGWARN_VDEXIT, ERRID_VREGWARN_VERR, ERRID_VREGWARN_VSLP, ERRID_VREGWARN_VDIS, ERRID_VREGWARN_SERR, ERRID_VREGWARN_CH, ERRID_CFD0_CH, ERRID_CFD1_CH, ERRID_CFM0_CH, ERRID_CFM1_CH, ERRID_SWDT_BADPC, ERRID_SWDT_BADC, ERRID_SWDT_UC, ERRID_SWDT_EXP, ERRID_SWDT_CH, ERRID_EEPROM_ECC1, ERRID_EEPROM_ECC2, ERRID_EEPROM_CH, ERRID_EVSYS0_CH, ERRID_EVSYS0_CLEAR, ERRID_EVSYS1_CH, ERRID_EVSYS1_CLEAR

Here is the call graph for this function:

Here is the caller graph for this function:

T_HandleNmiInterrupt()

void T_HandleNmiInterrupt

(

void

)

Handles Non-Maskable Interrupts (NMI) by reporting the Error ID of any detected faults.

This function reads and clears all non-optional NMI error sources and reports their corresponding Error IDs to the Error Handler. In the case that none of these sources are set, ERRID_NMI_UNKNOWN is reported. It is assumed that NMIs will transition the device into Safe State, as they are linked to critical hardware errors. For this reason, this function will redundantly try to trigger a reset by reporting ERRID_NMI. In the case that none of the aforementioned reports reset the device, the function will enter an infinite while loop, waiting for a timing mechanism to time out and reset the device.

Sources (interrupt flag bit-name):

• Bus error (BUSERR)
• Stack pointer limit error (SPLIM)
• Illegal opcode error (OPC)
• Parity error on instruction bus (PARITYI)
• Parity error on data bus (PARITYD)

Optional sources that are not supported as they are assumed to not be enabled:

• CRCSCAN errors
• Error Channels configured with NON_CRITICAL criticality If any of these sources trigger an NMI, the function will report ERRID_NMI_UNKNOWN as the Error ID.

Warning

This function will never return as it expects a device reset either through the Error Handler or by a watchdog/ALARM-state timeout while in an infinite while loop.

Warning

It is assumed that ERRID_NMI is set to CRITICAL criticality in the errorIdCritLut, to ensure that the device is reset because of an NMI triggering, in case none of the other error reports did not result in a device reset.

Warning

It is advisable that any Error ID linked to NMI are set to CRITICAL criticality or

NON_CRITICAL if the error handling callback results in a device reset. As that is the intended result of an NMI. If set to NOTIFICATION criticality, this interrupt will still trigger and reset the device, even if the Error Controller doesn't go into ALARM state. NMI connected Error IDs:

• ERRID_BUSERR_CH
• ERRID_BUSERR_BUSERR
• ERRID_OPC_CH
• ERRID_OPC_OPC
• ERRID_SPLIM_CH
• ERRID_NMI
• ERRID_NMI_UNKNOWN

Note

For error sources with Error IDs connected to an error channel that is set to CRITICAL criticality, this handler normally does not execute because the Error Controller resets the device. However, if that reset fails, this handler can redundantly attempt to handle the error.

Note

For error sources with Error IDs set to NON_CRITICAL criticality, NMI has higher priority than any other interrupt. This means that if an NMI interrupt is triggered, it will always run first or interrupt an ongoing interrupt. The latter behavior is one of the reasons that this interrupt must reset the device, as an interrupted interrupt can lead to data hazards. If for some reason this interrupt fails to run, the redundant T_HandleErrorChInterrupt Task will redundantly clear any set error channels and their sources.

Note

This function does not clear any error channels, as them being set will redundantly ensure that the device resets by the Error Controller going into an ALARM state and starting its timeout mechanism.

The following Error IDs may be reported to the Error Handler by this Task:

• ERRID_BUSERR_BUSERR NMI caused by bus error
• ERRID_SPLIM_CH NMI caused by stack pointer limit error
• ERRID_OPC_OPC NMI caused by illegal opcode error
• ERRID_NMI_UNKNOWN NMI cause not known (none of the errors listed above)
• ERRID_NMI NMI interrupt handling completed without a device reset

Here is the call graph for this function:

Here is the caller graph for this function:

T_HandleNvmInterrupt()

void T_HandleNvmInterrupt

(

void

)

Handles NVM interrupts by reporting the Error ID of any detected faults.

This function reads and clears all interrupt error sources in NVM and reports their corresponding Error IDs to the Error Handler. Once all sources are cleared, it also attempts to clear the associated error channels, avoiding double-reporting of errors.

Sources (connected error channel name):

• Flash ECC single-bit error (FLASH1)
• Flash ECC multi-bit error (FLASH2)
• EEPROM ECC Single-bit error (EEPROM)
• EEPROM ECC multi-bit error (EEPROM)
• NVM ECC comparator error (FLASH2)
• NVM parity Error (none)

Note

The NVM parity error flag will normally trigger a bus error and set the bus error flag in the CPU. This will in turn trigger the connected error channel called BUSERR and issue a Non-Maskable Interrupt (NMI). In other words, the NVM parity error flag is only connected indirectly to the BUSERR channel, and thus the channel is not attempted cleared. The NVM parity error flag is cleared and reported in this handler as a redundant measure.

Note

For error sources with Error IDs connected to an error channel that is set to CRITICAL criticality, this handler normally does not execute because the Error Controller resets the device. However, if that reset fails, this handler can redundantly attempt to handle the error.

Note

For error sources with Error IDs set to NON_CRITICAL criticality, the redundant

T_HandleErrorChInterrupt Task is also responsible for clearing and handling the error sources and channels. Whichever runs first will normally prevent the other from executing when the interrupt sources are successfully cleared.

Note

For error sources with Error IDs set to NOTIFICATION criticality, the errors are cleared and reported here and handled later in the T_HandleNotificationErrors Task, which also checks and reports any errors that were not cleared in interrupt handlers for redundancy.

Note

This function does not verify whether clearing the error channels was successful. If clearing a channel fails, it is assumed that either the T_HandleErrorChInterrupt or

T_HandleNotificationErrors task will report the error.

The following Error IDs may be reported to the Error Handler by this Task:

• ERRID_FLASH1_CH Single-bit ECC error in Flash
• ERRID_FLASH2_ECC2 Multi-bit ECC error in Flash
• ERRID_EEPROM_ECC1 Single-bit ECC error in EEPROM
• ERRID_EEPROM_ECC2 Multi-bit ECC error in EEPROM
• ERRID_FLASH2_COMP ECC Comparator error in Flash
• ERRID_NVM_PARITY NVM parity error

Here is the call graph for this function:

Here is the caller graph for this function:

T_HandlePowerInterrupt()

void T_HandlePowerInterrupt

(

void

)

Handles power related interrupts by reporting the Error ID of any detected faults.

This function reads and clears all interrupt error sources in SLPCTRL and reports their corresponding Error IDs to the Error Handler. Once all sources are cleared, it also attempts to clear the associated error channels, avoiding double-reporting of errors.

Sources (connected error channel name):

• VMON overvoltage detected (VREGFAIL)
• VMON undervoltage detected (VREGFAIL)
• VMON diagnostic mode entered (VREGWARN)
• VMON diagnostic mode exited (VREGWARN)
• VMON internal error (VREGWARN)
• VMON is in sleep mode (VREGWARN)
• VMON is disabled (VREGWARN)
• Sleep instruction error (VREGWARN)

This function is optionally responsible for handling completion of the interrupt based periodic VMON overvoltage and undervoltage diagnostics by calling MW_DiagVmonOverEnd and MW_DiagVmonUnderEnd if DIAG_PERIODIC_VMON is ENABLED. Due to the long and varied execution time, it is not feasible to busy-wait until the diagnostic is completed in Mission Mode and thus it must be completed in an interrupt. When completing a diagnostic, the function returns early to reduce execution time. If any other error flags are set, it is assumed that the task is called again in the ISR.

Note

If VDENTER or VDEXIT is the source of the interrupt trigger, it indicates that diagnostic mode was entered unintentionally and should be considered an error. When diagnostics function as intended, they will handle these flags internally, preventing those flags from being reported as an error.

Note

For error sources with Error IDs connected to an error channel that is set to CRITICAL criticality, this handler normally does not execute because the Error Controller resets the device. However, if that reset fails, this handler can redundantly attempt to handle the error.

Note

For error sources with Error IDs set to NON_CRITICAL criticality, the redundant

T_HandleErrorChInterrupt Task is also responsible for clearing and handling the error sources and channels. Whichever runs first will normally prevent the other from executing when the interrupt sources are successfully cleared.

Note

For error sources with Error IDs set to NOTIFICATION criticality, the errors are cleared and reported here and handled later in the T_HandleNotificationErrors Task, which also checks and reports any errors that were not cleared in interrupt handlers for redundancy.

Note

This function does not verify whether clearing the error channels was successful. If clearing a channel fails, it is assumed that either the T_HandleErrorChInterrupt or

T_HandleNotificationErrors task will report the error.

The following Error IDs may be reported to the Error Handler by this Task:

• ERRID_DIAG_VMON_OVER The MW_DiagVmonOverEnd diagnostic reported an error
• ERRID_DIAG_VMON_UNDER The MW_DiagVmonUnderEnd diagnostic reported an error
• ERRID_VREGFAIL_VOV VMON detected overvoltage
• ERRID_VREGFAIL_VUV VMON detected undervoltage
• ERRID_VREGWARN_VDENTER VMON unexpectedly entered diagnostic mode
• ERRID_VREGWARN_VDEXIT VMON unexpectedly exited diagnostic mode
• ERRID_VREGWARN_VERR VMON internal error
• ERRID_VREGWARN_VSLP VMON unexpectedly entered a sleep state
• ERRID_VREGWARN_VDIS VMON unexpectedly disabled
• ERRID_VREGWARN_SERR Sleep error due to illegal condition

Here is the call graph for this function:

Here is the caller graph for this function:

T_HandleRamInterrupt()

void T_HandleRamInterrupt

(

void

)

Handles RAM interrupts by reporting the Error ID of any detected faults.

This function reads and clears all interrupt error sources in RAM and reports their corresponding Error IDs to the Error Handler. Once all sources are cleared, it also attempts to clear the associated error channels, avoiding double-reporting of errors.

Sources (connected error channel name):

• RAM ECC single-bit error (RAM1)
• RAM ECC multi-bit error (RAM2)
• RAM ECC comparator error (RAM2)
• RAM parity error (none)

Note

The RAM parity error flag will normally trigger a bus error and set the bus error flag in the CPU. This will in turn trigger the connected error channel called BUSERR and issue a Non-Maskable Interrupt (NMI). In other words, the RAM parity error flag is only connected indirectly to the BUSERR channel, and thus the channel is not attempted cleared. The RAM parity error flag is cleared and reported in this handler as a redundant measure.

Note

For error sources with Error IDs connected to an error channel that is set to CRITICAL criticality, this handler normally does not execute because the Error Controller resets the device. However, if that reset fails, this handler can redundantly attempt to handle the error.

Note

For error sources with Error IDs set to NON_CRITICAL criticality, the redundant

T_HandleErrorChInterrupt Task is also responsible for clearing and handling the error sources and channels. Whichever runs first will normally prevent the other from executing when the interrupt sources are successfully cleared.

Note

For error sources with Error IDs set to NOTIFICATION criticality, the errors are cleared and reported here and handled later in the T_HandleNotificationErrors Task, which also checks and reports any errors that were not cleared in interrupt handlers for redundancy.

Note

This function does not verify whether clearing the error channels was successful. If clearing a channel fails, it is assumed that either the T_HandleErrorChInterrupt or

T_HandleNotificationErrors task will report the error.

The following Error IDs may be reported to the Error Handler by this Task:

• ERRID_RAM1_CH Single-bit ECC error in RAM
• ERRID_RAM2_ECC2 Multi-bit ECC error in RAM
• ERRID_RAM2_COMP ECC Comparator error in RAM
• ERRID_RAM_PARITY RAM parity error

Here is the call graph for this function:

Here is the caller graph for this function:

T_HandleSwdtInterrupt()

void T_HandleSwdtInterrupt

(

void

)

Handles SWDT interrupts by reporting the Error ID of any detected faults.

This function reads and clears all interrupt error sources in the SWDT and reports their corresponding Error IDs to the Error Handler. Once all sources are cleared, it also attempts to clear the associated error channel, avoiding double-reporting of errors.

Sources (connected error channel name):

• Bad Preclear Command Sequence (SWDT)
• Bad Clear Command Sequence (SWDT)
• Unexpected Command (SWDT)
• Watchdog Counter Expired (SWDT)

Note

For error sources with Error IDs connected to an error channel that is set to CRITICAL criticality, this handler normally does not execute because the Error Controller resets the device. However, if that reset fails, this handler can redundantly attempt to handle the error.

Note

For error sources with Error IDs set to NON_CRITICAL criticality, the redundant

T_HandleErrorChInterrupt Task is also responsible for clearing and handling the error sources and channels. Whichever runs first will normally prevent the other from executing when the interrupt sources are successfully cleared.

Note

For error sources with Error IDs set to NOTIFICATION criticality, the errors are cleared and reported here and handled later in the T_HandleNotificationErrors Task, which also checks and reports any errors that were not cleared in interrupt handlers for redundancy.

Note

This function does not verify whether clearing the error channel was successful. If clearing a channel fails, it is assumed that either the T_HandleErrorChInterrupt or

T_HandleNotificationErrors task will report the error.

The following Error IDs may be reported to the Error Handler by this Task:

• ERRID_SWDT_BADPC Non-PRECLEAR SWDT command received when expecting PRECLEAR
• ERRID_SWDT_BADC Non-CLEAR SWDT command received when expecting CLEAR
• ERRID_SWDT_UC Unexpected SWDT command received
• ERRID_SWDT_EXP Expired SWDT counter

Here is the call graph for this function:

Here is the caller graph for this function: