Fatal error APIs

Enumerations
enum	k_fatal_error_reason {   K_ERR_CPU_EXCEPTION , K_ERR_SPURIOUS_IRQ , K_ERR_STACK_CHK_FAIL , K_ERR_KERNEL_OOPS ,   K_ERR_KERNEL_PANIC }

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

Detailed Description

Enumeration Type Documentation

k_fatal_error_reason

enum k_fatal_error_reason

#include <include/zephyr/fatal.h>

Enumerator
K_ERR_CPU_EXCEPTION	Generic CPU exception, not covered by other codes
K_ERR_SPURIOUS_IRQ	Unhandled hardware interrupt
K_ERR_STACK_CHK_FAIL	Faulting context overflowed its stack buffer
K_ERR_KERNEL_OOPS	Moderate severity software error
K_ERR_KERNEL_PANIC	High severity software error

Function Documentation

k_fatal_halt()

FUNC_NORETURN void k_fatal_halt

(

unsigned int

reason

)

#include <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

reason

Fatal exception reason code

k_sys_fatal_error_handler()

void k_sys_fatal_error_handler	(	unsigned int	reason,
		const z_arch_esf_t *	esf
	)

#include <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

reason	The reason for the fatal error
esf	Exception context, with details and partial or full register state when the error occurred. May in some cases be NULL.

Fatal error policy handler.

Test Objective:

• To verify architecture layer provides a mechanism to issue an interprocessor interrupt to all other CPUs in the system that calls the scheduler IPI. We simply add a hook in z_sched_ipi(), in order to check if it has been called once in another CPU except the caller, when arch_sched_ipi() is called.

Testing techniques:

• Interface testing, function and block box testing, dynamic analysis and testing

Prerequisite Conditions:

• CONFIG_SMP=y, and the HW platform must support SMP.
• CONFIG_TRACE_SCHED_IPI=y was set.

Input Specifications:

• N/A

Test Procedure:

1. In main thread, given a global variable sched_ipi_has_called equaled zero.
2. Call arch_sched_ipi() then sleep for 100ms.
3. In z_sched_ipi() handler, increment the sched_ipi_has_called.
4. In main thread, check the sched_ipi_has_called is not equaled to zero.
5. Repeat step 1 to 4 for 3 times.

Expected Test Result:

• The pointer of current cpu data that we got from function call is correct.

Pass/Fail Criteria:

• Successful if the check of step 4 are all passed.
• Failure if one of the check of step 4 is failed.

Assumptions and Constraints:

• This test using for the platform that support SMP, in our current scenario , only x86_64 and arc supported.

See also

arch_sched_ipi()