EXCEPTION BEHAVIOR

STG-Captronic 5. 1 Cortex-M3 Exceptions

EXCEPTION BEHAVIOR
Exception Types
Reset : Invoked on power up or on a warm reset

Fault :
Hard fault : Occurs because of an error during exception processing, or because of a fault
escalation (an error in another fault)
Memory management fault : Occurs because of a memory protection related fault
Bus fault : Occurs because of a memory related fault for an instruction or data memory
transaction (might be from an error detected on a bus) in the memory system
Usage fault : Exception that occurs because of a fault related to instruction execution

System Call :
SVCall : A supervisor call is an exception triggered by the SVC instruction (formerly SWI)
PendSV : Interrupt-driven request for system-level service

Interrupt :
NMI : A non maskable interrupt can be signalled by a peripheral or triggered by software
SysTick : The system timer generates an exception when it reaches zero
Interrupt (IRQ) : Exception signalled by a peripheral, or generated by a software request.
All interrupts are asynchronous to instruction execution (used by peripherals to
communicate with the processor) depends on the NVIC implementation

Debug Monitor :
Entered when a debug event occurs while no probe is connected (less intrusive debug
than halting the core)

STG-Captronic 5. 2 Cortex-M3 Exceptions

EXCEPTION BEHAVIOR
Pulse-Triggered IRQ
For the following diagrams, we suppose that the CPU directly takes the exception (The
CPU is not executing another exception handler, so it is not delayed)

Exception assertion will cause the exception to be pended on the next clock edge

All the core exceptions are pulse-triggered

When the exception is taken by the CPU, it is not pending anymore

IRQi

InterruptSetEnable 1

InterruptSetPending 0 1 0

InterruptActive 0 1 0

Entry/ISR/Exit

IRQi Interrupt
requested exit

STG-Captronic 5. 3 Cortex-M3 Exceptions

Level-Triggered IRQ

Usually Interrupts are Level-Triggered and have to be cleared through peripheral

registers
Implementation defined

IRQi

InterruptSetEnable 0 1

InterruptSetPending 0 1 0

InterruptActive 0 1 0

Entry/ISR/Exit

IRQi IRQi IRQi Interrupt

requested enabled cleared by ISR exit

STG-Captronic 5. 4 Cortex-M3 Exceptions

EXCEPTION BEHAVIOR
Exception States
Exception can be pulse or level-triggered
Exception handler has been executed
Exception states: (and exited)
Pending
Note: If an exception is
disabled, it can be in the &
Inactive or Pending state Active
Pending
Exception is Exception pending bit is
generated cleared by software

CPU is taking a
pulse-triggered
exception

Exception pending Another exception

bit is cleared by from the same
Inactive software Active source is
generated

Interrupt is level-
Exception handler has been executed triggered and the
(and exited) interrupt handler didn’t
clear the peripheral
An exception has: interrupt flag
A priority level
An exception number, depending on the exception line number in the vector table
A vector in the vector table

STG-Captronic 5. 5 Cortex-M3 Exceptions

EXCEPTION BEHAVIOR
Exception Configuration

Each exception input can have several registers to control it (especially for the
peripheral interrupts):
Enable bit (RW): Enable or mask the exception
Pending bit (RW): If the pending bit is set, then the exception is pending
An exception can be “pended” by setting the pending bit
Active bit (RO):
Set if the exception is executing or “active-stacked”
Active-stacked means the interrupt was executing, but was pre-empted by another
higher-priority exception
Priority field: 3 to 8 bits of priority for each configurable exception

Interrupt configuration (SoC peripheral exception configuration) is done through the

NVIC registers
Enable, Pending and Active bits can be read and write for each IRQs (Active bit are
Read Only)

Core exception configuration is done through the System Control block (SCB) registers
There are not a kind of Enable, Pending or Active bit for all core Exceptions
Some core exceptions don’t have a configurable priority

STG-Captronic 5. 6 Cortex-M3 Exceptions

 VECTOR TABLE

STG-Captronic 5. 7 Cortex-M3 Exceptions

EXCEPTION BEHAVIOR
Vector Table
Address Vector
0x000 Initial Main SP The vector table contains handler
0x004 Reset addresses (addresses of the
0x008 NMI exception routine codes)
0x00c Hard Fault But not branch instructions)
0x010 Memory Manage
0x014 Bus Fault
0x018 Usage Fault
0x01C Reserved
16 Core exception vectors
0x020 Reserved
0x024 Reserved
Exception Handler can be written in C language
0x028 Reserved The return instruction is the same as a
0x02C SVCall function return instruction
0x030 Debug Monitor
The vector table has to be located
0x034 Reserved
at the address 0x0
0x038 PendSV
(probably at the beginning of the
0x03c SysTick
flash located at 0x0)
0x040 IRQ0
… … 1-240 Exception vectors
0x3BC IRQ239 (Peripheral Interrupts)

STG-Captronic 5. 8 Cortex-M3 Exceptions

VECTOR TABLE

Unlike traditional ARM vector table, the Cortex-M vector table contains the address of
exception handlers (not instructons)
The first vector will be loaded into Main_SP when the processor leaves the reset state
For the other vectors, the address must be odd, because it is loaded into the PC when
the corresponding exception is taken (so the bit T in the xPSR register remains set)

Upon reset, Vector table starts at address 0

Processor uses the ICode bus to load vectors

Vector table size (Implementation defined, depends on the number of peripheral IRQ)

1 IRQ 17*4 = 68 Bytes

2 IRQs 18*4 = 72 Bytes
… …
496 IRQs (16+496)*4 = 2048 Bytes

The VTOR register in the SCB can be used to relocate the Vector table
The base address must be multiple of 128

STG-Captronic 5. 9 Cortex-M3 Exceptions

EXCEPTION BEHAVIOR
Vector Table

STG-Captronic 5. 10 Cortex-M3 Exceptions

 EXCEPTION ENTRY AND EXIT

STG-Captronic 5. 11 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT

The interrupt controller has been designed for low latency

A hardware sequencer is in charge of saving / restoring the state of the processor
On exception entry, it automatically saves specific core registers in the main stack and
jump to the corresponding exception handler
On exception exit, the context is popped from the main stack and the Thread Code restart
where it was interrupted

A pending exception can only be taken if it is enabled and it has sufficient priority to run

An exception can be active but pre-empted

An exception handler can interrupt the execution of another exception handler (depends
on exception priorities)
Many exceptions can be in active state at the same time (preemption)

Benefits of this hardware assistance :

Late determination of interrupt wich is pending, enabled, and having the highest priority
Tail-chaining
Interrupts can be processed back-to-back, minimizing the inter-ISR gap
Automatic nesting
The priority mechanism will enable the nesting of interrupt having a higher priority than the current one
No software overhead

STG-Captronic 5. 12 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT

Core Exceptions and Peripheral Interrupts are handled similarly

The priority of interrupts and software exceptions are software defined
It is thus possible for each of them to define the threshold between exceptions that
remain enabled and exceptions that are masked

The NVIC controls Exception prioritization and masking

The exception mechanism is based on
Memory-mapped registers for exception management
Located in the System Control Block for core exceptions
Located in the NVIC for peripheral interrupts
Special registers for exception masking

INTNMI

NVIC Cortex-M3
IRQ[N-1:0] core
N < 496

STG-Captronic 5. 13 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT

Exception entry

The processor always runs an exception handler in Handler mode

If the exception preempts software running in Thread mode, the processor changes to
Handler mode as part of the exception entry
Register saving is performed in the current stack
Do not forget about it for sizing your stacks (especially for a task stack using the
Process Stack Pointer in an application using a RTOS)
If the exception preempts software running in Handler mode (another exception), register
saving is done in the main stack

In the next timing diagram, the following assumptions are done :

Vector table at default address = 0x0000_0000
The stack is located in a SRAM accessed through the System Bus
The exception handler is located at the address 0x100
No long latency not interruptible instruction in the pipeline when the IRQ is requested

STG-Captronic 5. 14 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT
Exception entry
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

FCLK

IRQ[2]

HADDRS[31:0] SP+18 SP+1C SP+0 SP+4 SP+8 SP+C SP+10 SP+14

System
PC xPSR R0 R1 R2 R3 R12 LR bus
HWDATAS[31:0]

HADDRI[31:0] 0x48 0x100 0x104 0x108

Icode
0x101 Word0 Word1 Word2 bus
HRDATAI[31:0]
ISR fetch
PC ← 0x100
EPSR[T] ← 1

Current Priority 2
First ISR instr
in execute
stage

Exception Status No status Vector fetch and stack push Entry No Stat

Exception number 18
of the current
execution context
12-clock entry latency

Note:
0x48 = 18 x 4 = IRQ2
STG-Captronic 5. 15 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT

Exception Exit
The exception handler return instruction possibilities are exactly the same as for a
function return (for example: BX LR)
The unique difference is the value in LR
The value contained in LR is magic
It is called Exception Return Link
This is set up by exception entry
That is why the LR is automatically saved to the stack
When the processor runs in Handler mode, this is the way for it to distinguish
exception return from function return (and the stack used)
LR value Consequence of BX LR
0xFFFF_FFF1 Return to Handler mode
0xFFFF_FFF9 Return to Thread mode using Main stack
0xFFFF_FFFD Return to Thread mode using Process stack

Note that the address range 0xA000_0000-0xFFFF_FFFF is guaranteed to be Execute

Never
Therefore the magic value used to record the return context cannot be confused with a
regular function return

STG-Captronic 5. 16 Cortex-M3 Exceptions

 EXCEPTION ENTRY AND EXIT
Return from interrupt

Instead of using BX LR, the following instructions can be used

LDR PC,…
LDM, POP with PC in the register list

If no other interrupts are pending, a microcoded sequencer is in charge of restoring

the register values from the stack
Consequently it reloads both the xPSR and PC value
In parallel, the fetcher loads the 3 first words at the return address to be ready to
start the execution of the related instructions at the end of the restore sequence

THE RESTORE MICROCODED SEQUENCE CAN BE INTERRUPTED IN ORDER TO

SERVICE A PENDING INTERRUPT IMMEDIATELY
Register values in stack are not deallocated
The sequencer only needs to fetch the vector and the 3 first words of the ISR

STG-Captronic 5. 17 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT

Return from Exception
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

FCLK

HADDRS[31:0] SP+18 SP+1C SP+0 SP+4 SP+8 SP+C SP+10 SP+14

System
PC xPSR R0 R1 R2 R3 R12 LR bus
HRDATAS[31:0]

HADDRI[31:0] &BX LR PC PC+4 PC+8

Icode
BX LR Word0 Word1 Word2 bus
HRDATAI[31:0]
Fetch of instructions at return address (PC get in the stack)

Current Priority 9 0xFF

Exception Exception
exit return

Exception Status No Status Exit Vector fetch and stack pop Return 0b000

Exception number 34 0
of the current
execution context

STG-Captronic 5. 18 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT
Tail chaining

While an Exception handler is executed, another exception can be set pending

If the new pending exception has not a higher priority than the current exception, it waits
until the end of the current exception execution
The context saving is done only one time on the first exception entry
t

IRQ[1]

IRQ[2]

Exceptions is Exception is
cleared cleared

µcode µcode
Tail
Exception ISR IRQ1 ISR IRQ2 Exception
chaining
entry return

12 clocks 6 clocks 12 clocks

Priority of IRQ[1] is assumed to be programmed higher than priority of IRQ[2]

Otherwise a nesting would have occurred
The exception handler of IRQ[1] would have been preempted and finished after
the end of the IRQ[2] exception execution

STG-Captronic 5. 19 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT

Tail chaining

1 2 3 4 5 6 7 8 9 10 11

FCLK

IRQ[2]

HADDRI[31:0] &BX LR 0x48 0x100 0x104 0x108

HRDATAI[31:0] BX LR 0x101 Word0 Word1 Word2

Current Priority 0x01 0x02

Exception Status No status Exit Vector fetch and stack pop Return

Exception number 17 18

of the current
execution context

Exception Exception
exit entry

IRQ[2] was programmed with a priority level lower than the current IRQ
Otherwise a nesting would have occurred

STG-Captronic 5. 20 Cortex-M3 Exceptions

 EXCEPTION ENTRY AND EXIT
Late Arriving

The restore microcoded sequence can be interrupted in order to service a pending

Exception immediately
Register values in stack are not deallocated and the stack pointer is not updated
The sequencer only needs to fetch the vector and the 3 first words of the ISR
t

IRQ[1]

IRQ[2]

Exception is Exception is
cleared cleared

µcode µcode µcode

Tail
Exception ISR IRQ1 int ISR IRQ2 Exception
chaining
entry return return

1-12
12 clocks clocks 6 clocks 12 clocks

The pop operation is abandoned early

It is a tail-chaining following a restore cancellation

STG-Captronic 5. 21 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT

Late Preemption
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

FCLK
Increasing
priority

IRQ[2]

IRQ[8]

IRQ[9]

HADDRS[31:0] SP+18 SP+1C SP+0 SP+4 SP+8 SP+C SP+10 SP+14

HWDATAS[31:0] PC xPSR R0 R1 R2 R3 R12 LR

HADDRI[31:0] 0x48 0x100 0x104 0x108 0x60 0x500 0x504 0x64 0x600 0x604 0x608

HRDATAI[31:0] 0x101 Word0 Word1 Word2 0x501 Word0 Word1 0x501 Word0 Word1 Word2

ISR2 fetch ISR8 fetch ISR9 fetch

Current Priority 0xFF 2

Exception Status
No Status Vector fetch and stack push Entry No Sta

Exception 18 24 25
number of the
current
execution
context

STG-Captronic 5. 22 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT
Late Preemption

During the entry microcoded sequence, another exception can be set pending

Late arriving Exception does not imply processor state saving

The internal sequencer only needs to perform a second vector / ISR fetch

In the next timing diagram, 1 stack push operation is performed

3 vector reads are done

When the Exception handler execution has begun, it is no longer possible to achieve a
late preemption
If a new Exception is requested, there are 2 cases
It has a higher priority than the current one
A nesting occurs
It has a lower or equal priority
A tail chaing will occur at the end of the current ISR

STG-Captronic 5. 23 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT

Asynchronous Vs Synchronous Exception
Exceptions can be
Synchronous to the instruction stream
Faults (a fault can be imprecise on write access because of the Store buffer)
SVC
Asynchronous to the instruction stream (unrelated to the instruction stream)
Reset
NMI
PendSV (this exception is set pending by software)
Systick Timer Interrupt
External Interrupts

Synchronous exceptions are serviced after the instruction causing the exception and
before the following instruction (except if the fault is imprecise)
An imprecise bus fault could occur many cycles after the store instruction which
caused it for example
When a synchronous exception occurred, it has to be executed immediately
If it has not a priority higher than the current exception (if the core is already in
Handler Mode) or if it is masked by one of the core exception masks, a HardFault
exception occurs

STG-Captronic 5. 24 Cortex-M3 Exceptions

EXCEPTION ENTRY AND EXIT
Interrupt entry
What would be the interrupt entry latency time if the ISR code is fetched from System
Bus ?

Note that only scratch registers are automatically saved

Register saving is done in the current stack, not necessarily the Main Stack

0x0000_0000

SPi+1 > IC
R0
R1
R2
R3
DC
R12 Flash
LR
PC
xPSR SRAM
SPi > SYS

0xFFFF_FFFF

STG-Captronic 5. 25 Cortex-M3 Exceptions

PRIORITY MANAGEMENT

STG-Captronic 5. 26 Cortex-M3 Exceptions

PRIORITY MANAGEMENT

The priority mechanism is based on a level that the user asigns to each interrupt
source
This level is determined by
A hardware setting : the number of bits to encode the priority level
From 3 to 8 bits
A software setting : the boundary between group priority and sub-group priority

Number of bits to encode

priority level Prioritization logic

(control of nesting)
AIRCR[PRIGROUP]

LOWER NUMBER ARE HIGHER PRIORITY

Reset has priority –3
Only priority level larger or equal than 0 are programmable

WHEN 2 IRQS ARE PROGRAMMED WITH THE SAME GROUP AND SUB-GROUP, THEIR
HARDWIRED NUMBER IS USED A THIRD PRIORITY INDICATION
IRQ3 has a higher priority than IRQ26

STG-Captronic 5. 27 Cortex-M3 Exceptions

PRIORITY MANAGEMENT

Exception IRQ Exception Priority

number number type
1 - Reset -3 (Highest)
2 -14 NMI -2
3 -13 Hard Fault -1
4 -12 Memory Management Fault Configurable
5 -11 Bus Fault Configurable
6 -10 Usage Fault Configurable
7-10 - - -
11 -5 SVCall Configurable
12-13 - - -
14 -2 PendSV Configurable
15 -1 Systick Configurable
16 and above 0 and above Interrupt (IRQ) Configurable

STG-Captronic 5. 28 Cortex-M3 Exceptions

PRIORITY MANAGEMENT
Group priority and Sub-group priority

We assume that priority is encoded by using 8 bits

PRIGROUP Binary point

0b000 ggggggg.s
0b001 gggggg.ss
0b010 ggggg.sss The number of bits that determines
the number of groups is equal to
0b011 gggg.ssss
(7-PRIGROUP)
0b100 ggg.sssss
0b101 gg.ssssss
0b110 g.sssssss
0b111 ssssssss

Nesting occurs when a interrupt is requested with a higher group priority level
than the current IRQ (lower value)

STG-Captronic 5. 29 Cortex-M3 Exceptions

PRIORITY MANAGEMENT
Group priority and Sub-group priority
Nesting occurs on the condition that IRQ_B has a higher group priority than IRQ_A

ISR B

ISR A Push Pop ISR A

User process Push Pop User process

The number of Priority Groups will determine the size that must be allocated in Main
stack

If it is not the case, tail chaining occurs

Tail
ISR A ISR B
chain

User process Push Pop User process

STG-Captronic 5. 30 Cortex-M3 Exceptions

PRIORITY MANAGEMENT
Group priority and Sub-group priority

IRQ 14 IRQ 24 IRQ 25

Priority = 011.00101 Priority = 010.00001 Priority = 010.00110

GroupPriority=3 GroupPriority=2 GroupPriority=2 PRIGROUP=4

SubGroupPriority=5 SubGroupPriority=1 SubGroupPriority=6

IRQ active IRQ requested Nesting ?

IRQ14 IRQ24 Y
IRQ14 IRQ25 Y
IRQ24 IRQ14 N
IRQ24 IRQ25 N
IRQ25 IRQ14 N
IRQ25 IRQ24 N

Within a group, only tail-chaining can occur

STG-Captronic 5. 31 Cortex-M3 Exceptions

PRIORITY MANAGEMENT
Execution priority

The execution priority is defined to be the maximum priority of all active exceptions
This definition of execution priority prevents priority inversion

When an exception becomes active because its priority is sufficiently higher than the
execution priority
Its exception handler preempts the currently running instruction stream
Its priority becomes the execution priority

Priority Boosting increases the current execution priority

An exception must now have higher priority to preempt the current instruction stream

STG-Captronic 5. 32 Cortex-M3 Exceptions

PRIORITY MANAGEMENT
Special Purpose Registers

The V7-M describes 3 special registers related to exception masking :

PRIMASK
Set the mask level to 0
FAULTMASK
Set the mask level to -1
BASEPRI
Set the mask to a user-defined value in range 0-255

To set / clear PRIMASK and FAULTMASK registers, atomic instructions are supported

Instruction Effect Execution priority

CPSIE i PRIMASK[I] ← 0 -1 if FAULTMASK[F]==1 else defined by
BASEPRI[Pri]
CPSID i PRIMASK[I] ← 1 -1 if FAULTMASK[F]==1 else 0
CPSIE f FAULMASK[F] ← 0 0 if PRIMASK[I]==1 else defined by BASEPRI[Pri]
CPSID f FAULMASK[F] ← 1 -1

STG-Captronic 5. 33 Cortex-M3 Exceptions

PRIORITY MANAGEMENT
Special Purpose Registers

InterruptEnable[31]
&
IRQ31

PRIMASK[I]
INT &
Priority
resolver

InterruptEnable[0]
&
IRQ0

NVIC CORE

Accessing Special Purpose Registers :

MRS R7,PRIMASK Move to General Purpose Register from Special Register
MSR PRIMASK,R7 Move to Special Register from General Purpose Register

STG-Captronic 5. 34 Cortex-M3 Exceptions

 PRIORITY MANAGEMENT
Priority boosting

The priority can be boosted by the following mechanisms :

PRIMASK: setting this mask bit raises the execution priority to 0

This prevents all exceptions with configurable priority from activating, other than
through the HardFault fault escalation mechanism
Note special impact on WFI instruction

FAULTMASK: setting this mask bit raises the execution priority to -1

Can only be set when the execution priority is lower than -1 to allow escalating the
priority of a fault handler
Cleared automatically on all exception returns (except NMI)

BASEPRI: can be written with a value from N (lowest configurable priority) to 1

A non-zero value will act as a priority mask, affecting the execution priority when the
priority defined by BASEPRI is the same or higher than the current executing priority

STG-Captronic 5. 35 Cortex-M3 Exceptions

PRIORITY MANAGEMENT
BASEPRI
A maskable exception is taken when its preemption priority is strictly lower than the
execution priority
ExecutionPriority

IRQA_PendingBit 0 1 0

IRQB_PendingBit 0 1 0

Thread mode Hdlr mode Thread mode Hdlr mode Thread mode

t
IRQA asserted IRQB asserted BASEPRI ← 7
Priority=6 Priority=1
(not taken) (taken)

STG-Captronic 5. 36 Cortex-M3 Exceptions

 FAULT MANAGEMENT

STG-Captronic 5. 37 Cortex-M3 Exceptions

EXCEPTION BEHAVIOR
Fault Management

If a fault occurs but its handler is not enabled or it does not have enough priority to run,
the HardFault handler will be invoked instead
This is called “Fault Escalation”

Hard Fault is normally the first choice for a fault handler

Fault exceptions have to be enabled
A simple system would only use the Hard Fault handler (no other fault handlers enabled)
A more complex system would have separate fault handlers for some of the fault types
The fault reason can be found from specific registers of the SCB (like CFS Register)

Another cause of Hard Fault:

The SVC instruction is executed but the SVC exception doesn’t have enough priority to run

A fault inside a Hard Fault handler will lock up the core

The core stops its execution
The LOCKUP output (a Cortex-M3 pin) is asserted
Perhaps used to inform a watchdog to trigger reset

STG-Captronic 5. 38 Cortex-M3 Exceptions

FAULT MANAGEMENT

Some Fault Escalation examples:

An undefined instruction is decoded
The Cortex-M3 tries to signal a usage fault, but the UsageFault is not enabled
Therefore, the Cortex-M3 starts the HardFault handler

While running a high priority interrupt, an undefined instruction is decoded

The Cortex-M3 tries to signal a usage fault, but the priority of the usage fault is
lower than the priority of the running high priority interrupt
Therefore, the Cortex-M3 starts the HardFault handler

An UNDEFINED instruction is encountered in a UsageFault handler

A configurable fault handler causes the same kind of fault as is being serviced

A fault inside a Hard Fault handler will lock up the core

LOCKUP output asserted, perhaps used to inform watchdog to trigger reset

STG-Captronic 5. 39 Cortex-M3 Exceptions

FAULT MANAGEMENT

Application

LDR R4,=0x20000000
; even pointer
BX R4
Usage Fault Handler

LDR R4,=0x20000000
; even pointer
BX R4
Hard Fault Handler

LDR R4,=0x20000000
; even pointer
BX R4

Lockup

1. The application causes a fault by branching to an even pointer

2. The UsageFault handler causes a fault by branching to an even pointer
3. The HardFault handler causes a fault by branching to an even pointer

STG-Captronic 5. 40 Cortex-M3 Exceptions

 OS SERVICE CALLS AND TASK
SWITCHING

STG-Captronic 5. 41 Cortex-M3 Exceptions

EXCEPTION BEHAVIOR
Exception Types: OS Service calls and task switching
SVCall is a synchronous exception
As far as the calling thread is concerned, the SVCall handler will run after the SVC instruction and before
the instruction immediately following it

SVCall can be used from Thread mode to request system services from the OS

SVCall and PendSV are designed to work together to allow OS context switching without masking
interrupts
In many operating systems, context switches form the largest critical region where interrupt are masked
This directly affects the system maximum interrupt latency
Problem is that a context switch could be interrupted by another interrupt or exception requiring a context
switch
OS probably cannot nest context switches

In conclusion, all context switching happens in either PendSV or SVCall

SVCall called by Thread mode processes requiring services
PendSV called by any exception handlers requiring a context switch
Perhaps a process switch timer interrupt (based on the Systick Timer)
SVCall and PendSV would be set to the same priority
To be sure PendSV and SVCall will not pre-empt each other
Normally the lowest priority
No interrupt masking during context switches required

STG-Captronic 5. 42 Cortex-M3 Exceptions

OS SERVICE CALLS AND TASK SWITCHING
SVCall/PendSV
SVC priority = 0b01.000000
BASEPRI = 0b11.000000

ISR entry SVC ISR ISR exit

t
SVC #0xN

SVC priority = 0b10.000000

BASEPRI = 0b01.000000

Hard fault

t
SVC #0xN

PendSV priority = 0b10.000000

BASEPRI = 0b01.000000

ISR entry PendSV ISR ISR exit

t
InterruptControlState[PendsvSet] ← 1 BASEPRI ← 0b11.000000

STG-Captronic 5. 43 Cortex-M3 Exceptions