Interrupt Tasks

Contains API prototypes for Interrupt Tasks. More...

Files
file	tasks_interrupts.c
	Implements APIs for Tasks used by the Interrupt Task Managers.

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.

Version

1.0.0-alpha.1

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

Copyright

© 2024 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.

Definition at line 274 of file tasks_interrupts.c.

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.

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.

Definition at line 102 of file tasks_interrupts.c.

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.

For error sources with Error IDs 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.

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.

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 was not cleared in interrupt handlers for redundancy.

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.

Definition at line 109 of file tasks_interrupts.c.

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.

Note

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

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 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.

There is no error channel connected to the Flash CRC scan error source. For this reason there is no redundant handling of this error (except if NMI is enabled).

Definition at line 264 of file tasks_interrupts.c.

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 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.

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.

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 was not cleared in interrupt handlers for redundancy.

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.

MISRA C:2012 Deviation

Required: misra-c2012- 10.1
Justification: This function iterates through the errCh_t enum using the ++ operator to determine which channel is set. The errCh_t enum is continuous and the first member is initialized to an unsigned integer value of zero and a designated max value is used to ensure correct range. This is verified by unit tests and static asserts. Alternative implementations either lead to a greatly increased complexity and probability of erroneous implementation or violations of other MISRA 10.x rules. The enum value is passed to MW_GetErrorChannel, which will return 'ERROR' if an invalid channel is used, breaking the loop and preventing infinite iteration. Thus, the risk of unexpected behavior is mitigated and the deviation is deemed safe.

Definition at line 280 of file tasks_interrupts.c.

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)

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.

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.

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.

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.

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.

Definition at line 65 of file tasks_interrupts.c.

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.

For error sources with Error IDs 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.

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.

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 was not cleared in interrupt handlers for redundancy.

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.

Definition at line 203 of file tasks_interrupts.c.

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.

For error sources with Error IDs 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.

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.

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 was not cleared in interrupt handlers for redundancy.

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.

MISRA C:2012 Deviation

Advisory: misra-c2012- 15.5
Justification: This function explicitly returns early if a diagnostic has been completed to avoid spending unnecessary time in the interrupt handler checking flags that are most likely not set if a diagnostic was found to be ongoing. In the case that another fault also has set a SLPCTRL interrupt flag not related to the diagnostic, it will be handled by a redundant interrupt handler. This deviation is justified as it optimizes the interrupt handling process by reducing the time spent in the interrupt context, which is critical for system performance and responsiveness. Using a standard if/else construct instead of an early return is not feasible when using conditional compilation directives for optional inclusion of the diagnostic handling code.

Definition at line 141 of file tasks_interrupts.c.

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.

For error sources with Error IDs 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.

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.

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 was not cleared in interrupt handlers for redundancy.

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.

Definition at line 237 of file tasks_interrupts.c.

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 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.

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.

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 was not cleared in interrupt handlers for redundancy.

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.

Definition at line 174 of file tasks_interrupts.c.