Zephyr API Documentation  3.7.0-rc3
A Scalable Open Source RTOS
No Matches
Fatal error APIs


 Fatal error base types


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.

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