Zephyr API 3.6.99
Loading...
Searching...
No Matches
Fatal error APIs

Topics

 Fatal error base types
 
 

Functions

FUNC_NORETURN void k_fatal_halt (unsigned int reason)
 Halt the system on a fatal error.
 
void k_sys_fatal_error_handler (unsigned int reason, const struct arch_esf *esf)
 Fatal error policy handler.
 

Detailed Description

Function Documentation

◆ k_fatal_halt()

FUNC_NORETURN void k_fatal_halt ( unsigned int reason)

#include <zephyr/fatal.h>

Halt the system on a fatal error.

Invokes architecture-specific code to power off or halt the system in a low power state. Lacking that, lock interrupts and sit in an idle loop.

Parameters
reasonFatal exception reason code

◆ k_sys_fatal_error_handler()

void k_sys_fatal_error_handler ( unsigned int reason,
const struct arch_esf * esf )

#include <zephyr/fatal.h>

Fatal error policy handler.

This function is not invoked by application code, but is declared as a weak symbol so that applications may introduce their own policy.

The default implementation of this function halts the system unconditionally. Depending on architecture support, this may be a simple infinite loop, power off the hardware, or exit an emulator.

If this function returns, then the currently executing thread will be aborted.

A few notes for custom implementations:

  • If the error is determined to be unrecoverable, LOG_PANIC() should be invoked to flush any pending logging buffers.
  • K_ERR_KERNEL_PANIC indicates a severe unrecoverable error in the kernel itself, and should not be considered recoverable. There is an assertion in z_fatal_error() to enforce this.
  • Even outside of a kernel panic, unless the fault occurred in user mode, the kernel itself may be in an inconsistent state, with API calls to kernel objects possibly exhibiting undefined behavior or triggering another exception.
Parameters
reasonThe reason for the fatal error
esfException context, with details and partial or full register state when the error occurred. May in some cases be NULL.