Skip to content
Commit a90a47b1 authored by Michele Sardo's avatar Michele Sardo Committed by Fabio Baltieri
Browse files

arch: arm: cortex_m: Add API for scb save and restore



Add two API to save SCB context and restore it, typically
used in suspend to RAM use case.

The scb_context_t and the backup/restore functions are designed to only
handle SCB registers that are:
- Mutable: Their values can be changed by software.
- Configurable: They control system behavior or features.
- Stateful: Their values represent a specific configuration that an
            application might want to preserve and restore.

Register excluded from backup/restore are:
1.	CPUID (CPUID Base Register)
	Motivation for Exclusion: This is a read-only identification register.
2.	ICSR (Interrupt Control and State Register)
	Motivation for Exclusion (from restoration): While its current value
	can be read, directly restoring a saved	ICSR value is highly
	dangerous and generally unsafe in an RTOS context.
	Contains Read-Only Status Bits: A significant portion of ICSR
	consists of read-only bits (VECTACTIVE, VECTPENDING, ISRPREEMPT,
	TSRUNPEND). These bits reflect the current state of the exception
	system (e.g., which exception is active, which are pending) and are
	managed dynamically by the CPU and the RTOS.
	Forcing a previous state onto these bits would corrupt the live
	system's interrupt handling.
	Contains Write-Only Set/Clear Bits: Some bits are write-only to set
	or clear a pending interrupt (PENDSVSET, PENDSVCLR, SYSTICKSET,
	SYSTICKCLR). If these bits were set in the saved context, restoring
	them might immediately trigger an interrupt or change its pending state
	unexpectedly, outside the RTOS's control.
	RTOS Management: In Zephyr (and other RTOSes), the kernel tightly
	manages the interrupt and exception state.
	Direct manipulation of ICSR's volatile bits could conflict with the
	RTOS's internal state machine, leading to crashes or unpredictable
	behavior.
3.	CFSR (Configurable Fault Status Register)
	Motivation for Exclusion: This is a read-only status register that
	reports the current state of Memory Management, Bus Fault, and Usage
	Faults. It's used by fault handlers to determine the cause of a fault.
4.	HFSR (HardFault Status Register)
	Motivation for Exclusion: Similar to CFSR, this is a read-only status
	register that reports the current state	of HardFaults. It's for
	reporting, not for configuration or restoration.
5.	DFSR (Debug Fault Status Register)
	Motivation for Exclusion: This is a read-only status register that
	reports debug-related faults. It's primarily used by debuggers and
	is not part of the application's runtime context to be saved/restored.
6.	MMFAR (MemManage Fault Address Register)
	Motivation for Exclusion: This is a read-only register that stores the
	address that caused a Memory Management	fault. It's a diagnostic
	register, not a configurable parameter.
7.	BFAR (BusFault Address Register)
	Motivation for Exclusion: Similar to MMFAR, this is a read-only
	register that stores the address that caused a BusFault. It's a
	diagnostic register.
8.	AFSR (Auxiliary Fault Status Register)
	Motivation for Exclusion: This register is implementation-defined and
	read-only.

Signed-off-by: default avatarMichele Sardo <msmttchr@gmail.com>
parent 7c30d7a9
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment