Error Handler

Contains API prototypes for the Error Handler. More...

Topics
	Error Handler Config
	Declares configurations for the Error Handler.

Files
file	error_handler.c
	Implements APIs the Error Handler.
file	error_handler_actions.c
	Implements APIs for Error Handler Actions.
file	error_handler_actions.h
	Contains API prototypes for Error Handler Actions.
file	error_handler_callbacks.c
	Implements APIs for Error Handler Callbacks.
file	error_handler_callbacks.h
	Contains API prototypes for Error Handler callback examples.

Functions
void	EH_HandleError (errFlag_t flag, errId_t id)
	Handles error based on configured Error ID criticality if the error flag is set.
void	EH_ProcessNotificationLog (void)
	Processes all Error IDs in the log by calling the configured handler callback.
void	EH_InitiateSafeState (errId_t id)
	Transitions the system into a Safe State and resets the device.
void	EH_PushNotificationLog (errId_t id)
	Pushes Error ID to the Notification Error Log for later handling.
errId_t	EH_PopNotificationLog (void)
	Pops the last Error ID from the Notification Error Log for error handling.
void	EH_NonCriticalErrorExampleCallback (errId_t id)
	Demonstrates an implementation of a 'NON_CRITICAL' Error Handler callback function.
void	EH_NotificationErrorExampleCallback (errId_t id)
	Demonstrates an implementation of a 'NOTIFICATION' Error Handler callback function.

Detailed Description

Contains API prototypes for the Error Handler.

Version

1.0.0-alpha.1

The Error Handler is responsible for providing a configurable and centralized error handling mechanism for both hardware and software error flags. Unique Error IDs are reported by Tasks and handled according to their configured criticality levels.

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

Function Documentation

EH_HandleError()

void EH_HandleError	(	errFlag_t	flag,
		errId_t	id )

Handles error based on configured Error ID criticality if the error flag is set.

This function evaluates the error flag and returns without further action if set to NO_ERROR. For ERROR, the appropriate error handling action is executed based on the configured Error ID criticality in the errorIdCritLut :

CRITICAL errors are immediately handled by calling EH_InitiateSafeState, where the Error ID will be stored to be handled after a system reset.

NON_CRITICAL errors are immediately handled by calling the application specific error handler callback configured in nonCriticalErrorCallback, where the Error ID is passed for handling according to application requirements.

NOTIFICATION errors are handled later by calling EH_PushNotificationLog, where the Error ID is put into a notification error log that is processed when calling EH_ProcessNotificationLog. The number of errId_t in the log is limited by the NOTIFICATION_LOG_SIZE configuration.

IGNORE errors are not handled.

Note

If the error flag is invalid, the error ID is updated to ERRID_ERRFLAG_VAL and handled regardless of the validity of the input Error ID.

If the Error ID is invalid, the ID is updated to ERRID_ERRID_VAL and handled, except if the flag is set to NO_ERROR.

Undefined Error ID criticality defaults to CRITICAL as a safety mechanism.

The errId_t enum and errorIdCritLut are designed to be extendable to accommodate application-specific errors.

Warning

Negative Error IDs will lead to undefined behavior.

Error ID input validity checks rely on ERRID_MAX being the max value and ERRID_NONE being the smallest Error ID value.

An invalid function pointer in nonCriticalErrorCallback leads to undefined behavior.

Parameters

flag	The error flag indicating whether an error requires handling.
id	The Error ID corresponding to the error that occurred.

Definition at line 35 of file error_handler.c.

EH_InitiateSafeState()

void EH_InitiateSafeState

(

errId_t

id

)

Transitions the system into a Safe State and resets the device.

This function immediately enters a Safe State by first disabling global interrupts and force floating all I/O pins. It then stores the reported Error ID in persistent memory so that the reset reason can be handled after the device reset. Finally, it enters an infinite loop where it tries to issue a software reset, disable the Error Controller heartbeat signal and re-attempt to float I/O pins in case it failed. This loop will continue until a successful device reset occurs, either through the software reset, an external reset, Error Controller reset or the Watchdog Timer expiring.

Warning

This Task will never return, as it ends in an infinite loop or successful device reset.

Note

The heartbeat signal will be attempted stopped regardless of whether it is enabled or not if the initial reset attempt fails. If enabled, it is assumed that the configured I/O pin used for the heartbeat signal is configured such that an external system will detect when the heartbeat is stopped (if the force floating of all I/O pins failed).

Parameters

id	The reported Error ID indicating the reset reason to store in persistent memory.

Note

The reported Error ID is stored in persistent memory using the PVAL_ERRID_REASON so that it can be handled after a device reset (in T_HandleResetReason).

Warning

It is assumed that the caller reports a valid Error ID with a value less than 8 bits.

The Error ID and any persistent data stored between device resets is cleared upon Power-On Reset (POR) and Brown-out Reset (BOR).

Definition at line 39 of file error_handler_actions.c.

EH_NonCriticalErrorExampleCallback()

void EH_NonCriticalErrorExampleCallback

(

errId_t

id

)

Demonstrates an implementation of a 'NON_CRITICAL' Error Handler callback function.

Parameters

id	Error ID for cause of NON_CRITICAL error.

Todo

This example callback has not been implemented and simply returns without further action.

Warning

An application specific error handling callback must be implemented for proper error handling.

Definition at line 26 of file error_handler_callbacks.c.

EH_NotificationErrorExampleCallback()

void EH_NotificationErrorExampleCallback

(

errId_t

id

)

Demonstrates an implementation of a 'NOTIFICATION' Error Handler callback function.

Parameters

id	Error ID for cause of NOTIFICATION error.

Todo

This example callback has not been implemented and simply returns without further action.

Warning

An application specific error handling callback must be implemented for proper error handling.

Definition at line 32 of file error_handler_callbacks.c.

EH_PopNotificationLog()

errId_t EH_PopNotificationLog

(

void

)

Pops the last Error ID from the Notification Error Log for error handling.

The function returns the Error ID from the Notification Error Log unless it is empty, then ERRID_NONE is returned. The Notification Error Log is implemented as a stack using the Last-In-First-Out (LIFO) principle. This means that the error that is popped from the log is the last error that was pushed to the log when calling EH_PushNotificationLog. Once the error is popped from the log it is removed from the stack.

Note

If the Notification Error Log is empty, ERRID_NONE is returned.

If the Error ID from the log is invalid, the return ID is updated to ERRID_ERRID_VAL.

Returns

id The Error ID to handle from the Notification Error Log.

Return values

ERRID_NONE	The Error ID that indicates an empty Notification Error Log.
ERRID_ERRID_VAL	The Error ID returned when an invalid ID is popped from the log.

Definition at line 68 of file error_handler_actions.c.

EH_ProcessNotificationLog()

void EH_ProcessNotificationLog

(

void

)

Processes all Error IDs in the log by calling the configured handler callback.

The Notification Error Log is populated by EH_HandleError for later processing when handling errId_t with criticality NOTIFICATION. This Task needs to be called to do the handling of the errors at a later time.

The Error IDs in the Notification Error Log are processed by calling EH_PopNotificationLog to retrieve the logged errId_t and issuing the configured notificationErrorCallback. The last Error ID added to the log is the first to be processed (LIFO). Error IDs are removed from the log when they are processed and the processing ends when there are no more IDs in the log.

Note

The Notification Error Log has a limited size as defined by NOTIFICATION_LOG_SIZE in error_handler_config.h. Error IDs will be ignored if pushed to the log when it is full, so it is recommended to process the log often depending on the configured log size.

If new errors occur during callback handling, their errId_t may be directly added to the log in the callback, and will thus be the next to be handled. If so, the handling of these errors need to be be accounted for in the configuration of the notificationErrorCallback.

Warning

An invalid function pointer in notificationErrorCallback leads to undefined behavior.

Definition at line 101 of file error_handler.c.

EH_PushNotificationLog()

void EH_PushNotificationLog

(

errId_t

id

)

Pushes Error ID to the Notification Error Log for later handling.

This function adds an Error ID to the Notification Error Log unless it is full. If the log is full, the Error ID is discarded. The Notification Error Log is implemented as a stack using the Last-In-First-Out (LIFO) principle. This means that the last error that is pushed to the log is the first error that is popped from the log when calling EH_PopNotificationLog.

Note

If the Error ID ERRID_NONE is pushed, it will be ignored.

Warning

The Notification Error Log is limited by NOTIFICATION_LOG_SIZE, if the log is full the reported Error ID will be ignored.

Parameters

id	The Error ID to report to the Notification Error Log.

Definition at line 58 of file error_handler_actions.c.