ARM Cortex – M3

ARM Cortex-M3 Architecture

Processor
 Brief History of ARM

➢ ARM was developed at Acron Computer Limited

of Cambridge, England between 1983 & 1985
➢ RISC concept introduced in 1980 at
Stanford & Berkley
➢ARM Limited founded in 1990
➢ARM Cores
• Licensed to partners to develop & fabricate
new micro-controllers
• Soft-core

ARM Cortex - M3 2
 ARM Architecture
Based on RISC Architecture with enhancements
to meet requirements of Embedded applications
✓ A Large Uniform Register File
✓ Load-Store Architecture, where data processing
operates on register content only
✓ Uniform & fixed length Instructions
32-bit processor
✓ Instructions are 32-bit long
✓ Good Speed/Power Consumption Ratio
✓ High Code Density

ARM Cortex - M3 3
 Enhancements to Basic RISC
❖ Control over ALU & Shifter for every data
processing operations to maximize their usage
❖ Auto-Increment & Auto-Decrement Addressing
Modes to optimize program loops
❖ Load & Store Multiple Instructions to maximize
data throughput
❖ Conditional Execution of Instructions to maximize
Execution throughput

ARM Cortex - M3 4
 ARM Architecture Versions
Version 1 (1983-1985)
➢ 26 bit Addressing, no Multiply or Coprocessor

Version 2
➢ Includes 32-bit result multiply coprocessor

Version 3
➢ 32-bit Addressing

Version 4
➢ Add Signed , Unsigned Half-word & Signed Byte
Load & Store Instructions

Version 4T
➢ 16-bit Thumb - compressed form of Instructions

ARM Cortex - M3 5
 Architecture Versions

Version 5T
➢ Superset of 4T adding new Instructions

Version 5TE
➢ Add Signal Processing Extension
Examples:
ARM 6 : v3
ARM7 : v3
ARM7TDMI : v4T
StrongArm : v4
ARM 9E-S : v5TE

ARM Cortex - M3 6
 Architecture Versions

ARM Cortex - M3 7
 Overview : Core Data Path
✓ Data Items are placed in Register File
✓ No Data Processing Instructions directly
manipulate Data in memory
✓ Instructions Typically use two Source Registers
& single result or Destination Registers
✓ A Barrel Shifter on the date path can pre-process
data before It enters into ALU
✓ Increment/Decrement Logic can update the
Register Content for Sequential access
independent of ALU
ARM Cortex - M3 8
 Basic ARM Organization

ARM Cortex - M3 9
 Architecture Versions

ARM Cortex - M3 10
 Processor Naming
ARM7TDMI
Thumb Instruction Support
JTAG Debugging
Fast Multiplier
ICE
ARM926EJ-S
“26” or “36” MMU
Enhanced DSP
Jazelle
Synthesizable
ARM946E-S
“46” MPU

ARM Cortex - M3 11
 Processor Naming

ARM Cortex - M3 12
 Instruction Set Enhancement

ARM Cortex - M3 13
 Thumb – 2 Technology

Thumb-2 is a superset of :
Previous 16-bit Thumb instruction set
Additional 16-bit & 32-bit instructions
Ease of use, code size, and performance
No need of ARM – Thumb Switch
Hardware divide and Multiply instruction

ARM Cortex - M3 14
• The Cortex-M3 processor provides excellent performance and comes
with many new features previously available only in high-end
processors.
• Low power consumption: enabling longer battery life,
especially critical in portable products including wireless
networking applications
• Enhanced determinism: guaranteeing that critical tasks and
interrupts are serviced as quickly as possible and in a known
number of cycles
• Improved code density: ensuring that code fits in even
the smallest memory footprints
• Ease of use: providing easier programmability and
debugging for the growing number of 8-bit and 16-bit
users migrating to 32 bits
• Lower cost solutions: reducing 32-bit-based system
costs close to those of legacy 8-bit and 16-bit devices
and enabling low-end, 32-bit microcontrollers to be
priced at less than US$1 for the first time
• Wide choice of development tools: from low-cost or
free compilers to full-featured development suites from
many development tool vendors.
ARM Vs Cortex M3
 Cortex M3 Applications

Low-cost microcontrollers
Automotive
Data communications
Industrial control
Consumer products

ARM Cortex - M3 22
 Fundamentals of Cortex M3

32 Bit Processor
Harvard Architecture
Separate 32 bit Data Bus and Instruction Bus
Performance increases
Data accesses do not affect the instruction pipeline
Big Endian and Little Endian Memory Support
Supports Debugging Components - Breakpoints

ARM Cortex - M3 24
 Simplified Cortex M3 Archi.

ARM Cortex - M3 25
 Registers

Some 16-bit Thumb

instructions can
only access Low Registers

Banked

OS Kernel & Application Code

Exception Handler

Stack Pointer is Word aligned - Lowest 2 bits are always 0

ARM Cortex - M3 26
 Special Registers

ARM Cortex - M3 27
 Operation Modes

The privilege levels (Privilege and user levels) provide a mechanism

Safeguarding memory accesses to critical regions (Sys config Reg).
Providing a basic security model.

Privilege Level
Program has access to all memory ranges
(except when prohibited by MPU to protect OS data and pgm).
Use all supported instructions.

Software in Privileged level can switch to the User level - Control Reg.
A User program cannot switch back to the privileged state – Control Reg.
It has to go through an exception handler.

ARM Cortex - M3 28
 Operation Modes
Privilege Levels/States

Modes

Mode Transitions

ARM Cortex - M3 29
 Nested Vectored Interrupt Controller (NVIC)

Nested interrupt support – Priority.

Vectored interrupt support – Vector Table.
Dynamic priority changes support – Run Time
Interrupts that are being serviced are blocked from further
activation until the ISR is completed.
Reduction of interrupt latency
Automatic Saving & Restoring of some Registers.
Handling of Late Arrival Interrupts.
Interrupt masking – Based on Priority or Complete Mask
BASEPRI, PRIMASK, and FAULTMASK.

ARM Cortex - M3 30
 Memory Map

The Cortex-M3 - predefined memory map.

Access Built-in peripherals (NVIC & Debug Components) -
simple memory access instructions.
Thus access System features using C.
Optimize Speed and Ease of Integration – SoC Designs.

ARM Cortex - M3 31
 Memory Map

ARM Cortex - M3 32
 Bus Interface

Perform Instruction fetches and data accesses at the same

time
Code memory buses – Code M/M (I-Code & D-Code)
System bus – Memory (SRAM, Ex.RAM) & Peripherals
Private peripheral bus – Part of Sys. Level M/M (Debug)

ARM Cortex - M3 33
 Memory Protection Unit (MPU)

Defines Access rules - Privileged Access and User Program Access.

When Violated, a MemManage Fault Exception is generated.
To protect data use by the OS kernel.
To make memory regions read-only,
To prevent accidental erasing of data.
To isolate memory regions between different tasks in a
multitasking system.

ARM Cortex - M3 34
 Instruction Set

Switching between ARM Code and Thumb Code in Traditional ARM Processors

ARM Cortex - M3 35
 Instruction Set (Thumb 2) - Advantages

No state switching overhead - saving both execution time and

instruction space.
No need to separate ARM code and Thumb code source files -
software development and maintenance easier.
Easier - best code density and performance.
Coprocessor Instructions, SIMD, BLX, etc. – Not Supported.

ARM Cortex - M3 36
 Interrupts and Exceptions

More system exceptions & external Interrupt Request (IRQs).

NO fast interrupt (FIQ).
Interrupt Priority handling & Nested Interrupt support – like FIQ.

ARM Cortex - M3 37
 Cortex – M3 Exception Types

ARM Cortex - M3 38
 Low Power & High Energy Efficiency

Sleep & Deep Sleep Mode.

Low Gate Count
High Code Density – Lesser Pgm M/M Size
Wakeup Interrupt Controller,
Ultra Low Power.
Whole Processor Core - Powered Down.
Processor States are retained.

ARM Cortex - M3 39
 Debugging Support
Program Execution Controls,
Halting and Stepping.
Instruction Breakpoints & Trace.
Data Watchpoints.
Registers and memory accesses.

Debugging Hardware - CoreSight™ Architecture,

CPU core - does not have (JTAG) interface.
Debug Interface Module is decoupled from the core.
Bus Interface - Debug Access Port (DAP) - core level.
Control of DAP - Debug Port (DP) device.
Types of DPs,
Serial-Wire JTAG Debug Port (SWJ-DP) – JTAG & SW.
Serial-Wire Debug Port (SW-DP) – Serial Wire Only.
Embedded Trace Macrocell (ETM) – Instruction Trace (Optional).
Trace information is output via Trace Port Interface Unit (TPIU).
Debug Host (PC) - collect the executed instruction
information from TPIU via external Trace-Capturing Hardware.
ARM Cortex - M3 40
 Debugging Support
Many events - trigger debug actions.
Breakpoints/Watchpoints/Fault Conditions/
External Debugging Request input signals.
When debug event occurs - processor can either enter Halt Mode or execute
the Debug Monitor Exception Handler.
Data Watchpoint - Data Watchpoint and Trace (DWT) Unit
Stop the processor or,
Trigger the Debug Monitor Exception Routine,
Generate Data Trace Information.
Traced data can be output via the TPIU.
Flash Patch & Breakpoint (FPB) unit
Simple Breakpoint Function or
Remap - instruction access from Flash to different SRAM
location.
Instrumentation Trace Macrocell (ITM) - output data to a debugger.
By writing data to register memory in the ITM, a debugger can collect
the data via a trace interface and display or process them.
Easy to use and faster than JTAG output.
All Debugging components are controlled via the DAP interface bus on the
Cortex-M3 or by a program running on the processor core, and all trace
information is accessible from the TPIU.
ARM Cortex - M3 41
 Stack Pointer (R13)

Main Stack Pointer

Default SP
Used by OS kernel, exception handlers, and all application
codes privileged access.
Process Stack Pointer
Application code (when not running an exception handler).

ARM Cortex - M3 42
 Full Descending Stack

The base register – r9

Updated Register - r9'.

PUSH {R0} ; R13=R13-4, then Memory[R13] = R0

POP {R0} ; R0 = Memory[R13], then R13 = R13 + 4

PUSH or POP multiple registers

subroutine_1
PUSH {R0-R7, R12, R14} ; Save registers
... ; Do your processing
POP {R0-R7, R12, R14} ; Restore registers
BX R14 ; Return to calling function
PUSH and POP - word aligned (their addresses must be 0x0, 0x4, 0x8, ...)
R13 bit 0 and bit 1 are hardwired to 0 and always read as zero (RAZ).

ARM Cortex - M3 43
 Link Register (R14)
main ; Main program
...
BL function1 ; Call function1 using Branch with Link instruction.
; PC = function1 and
; LR = the next instruction in main
...

function1
... ; Program code for function 1
BX LR ; Return

• Bit 0 of the PC is always 0 (because instructions are word aligned or half word
aligned) but LR bit 0 is readable and writable.
• Bit 0 of LR indicate ARM/Thumb states.
• In Thumb 2 ISA Bit 0 of LR should be ‘1’ to indicate Thumb Mode.
• While branching, either by writing to PC or using branch instructions,
LSB of target address should be set to 1 to indicate Thumb.
• If Bit 0 is ‘0’ then UsageFault Exception.

ARM Cortex - M3 44
 Program Status Register

• Application Program Status register (APSR)

• Interrupt Program Status register (IPSR)
• Execution Program Status register (EPSR)

ARM Cortex - M3 45
 Program Status Register

ARM Cortex - M3 46
 Program Status Register

ARM Cortex - M3 47
 Interrupt Mask Registers

ARM Cortex - M3 48
 Control Register
The control register is used to define the privilege level and the SP selection

ARM Cortex - M3 49
ARM Cortex - M3 50
ARM Cortex - M3 51
 Interrupts & Exceptions

ARM Cortex - M3 52
 Vector Table
Relocatable – relocate register in NVIC
Address Cal – Type No X 4
LSB Vector Addr – Exeception/ntrpt executed in the Thumb/ARMstate
In Cortex M3 LSB should be set to 1.

ARM Cortex - M3 53
 Stack Memory Operations
The POP order - reverse of PUSH in single register stack operation.

ARM Cortex - M3 54
 Stack Memory Operations
In multiple register stack operations ordering of a register POP is
automatically reversed by the processor

ARM Cortex - M3 55
 Stack Memory Operations

Combine RETURN with a POP operation.

Pushing LR to the stack & popping it back to PC at end of the subroutine

ARM Cortex - M3 56
 Cortex M3 Stack Implementation
Full-descending stack.

PUSH
SP points to the last data pushed to the stack memory.
SP decrements before a new PUSH operation.

ARM Cortex - M3 57
 Cortex M3 Stack Implementation

POP
Data is read from m/m location pointed by SP.
SP is incremented.
Contents in the memory location are unchanged but will be overwritten
when the next PUSH operation takes place.

PUSH and POP – automatically, entering or exiting an exception/interrupt handler.

ARM Cortex - M3 58
 Two-Stack Model in Cortex M3
CONTROL[1]=0: Both Thread Level and Handler Use Main Stack.

ARM Cortex - M3 59
 Two-Stack Model in Cortex M3
CONTROL[1]=1: Thread Level Uses Process Stack and Handler Uses Main Stack.

Automatic stacking and unstacking mechanism will use PSP, whereas

stack operations inside the handler will use MSP.

Eg. Stack Operations. MRS R0,MSP ; MSP to R0

MSR PSP,R0 ; R0 to PSP
ARM Cortex - M3 60
 Reset Sequence
After the processor exits reset, it will read two words from memory.
Address 0x00000000: Starting value of R13 (the SP)
Address 0x00000004: Reset vector (the starting address of program execution;
LSB should be set to 1 to indicate Thumb state)

ARM Cortex - M3 61
 Reset Sequence
Initial Stack Pointer Value and Initial Program Counter Value Example.

SP initialized first,
because some of the
exceptions (such as
NMI) can happen right
after reset

Cortex-M3, vector addresses in the vector table - LSB set to 1 for Thumb code.
So 0x101 in the reset vector, whereas the boot code starts at address 0x100
ARM Cortex - M3 62
 Memory Map
Cortex-M3 have fixed Memory Map.
4 GB address space.

ARM Cortex - M3 63
 Memory Map

S/S
Level
M/M
Region

ARM Cortex - M3 64
 Memory Map
Program code can be in
Code region, SRAM or External RAM region.
Best in Code region as the instruction fetches and data accesses
are carried out simultaneously on two separate bus interfaces.
SRAM for connecting internal SRAM.
Access to this region - System Bus interface.
32-MB range is defined as a bit-band alias.
In 32-bit-band alias memory range, each word address
represents a single bit in the 1-MB bit-band region.
A data write access to this bit-band alias m/m range is converted
to an atomic READ- MODIFY-WRITE operation to bit-band region.
The bit-band - applies only to data accesses not instruction fetches.
BB - Pack multiple Boolean data in a single word while still allowing them to
be accessible individually via bit-band alias, thus saving memory space
without the need for handling READ-MODIFY-WRITE in software.

ARM Cortex - M3 65
 Memory Map
0.5 GB for On-chip Peripherals.
Program execution not allowed.
The bit-band support – makes it easy to access or change
control and status bits of peripherals, making it easier to
program peripheral control.
1GB each for External RAM and External Devices.
Program execution is not allowed in External Devices region.
0.5 GB for System-level components, internal peripheral buses,
external peripheral bus, and vendor-specific system peripherals.
Two segments of the private peripheral bus (PPB).
Advanced High-Performance Bus (AHB) PPB, - Cortex-M3
internal AHB peripherals only (NVIC, FPB, DWT, and ITM).
Advanced Peripheral Bus (APB) PPB, - Cortex-M3 internal
APB devices as well as external peripherals (external to
the Cortex-M3 processor connected using APB interface)
Unused vendor-specific - accessed via the System Bus interface.
Instruction execution in this region is not allowed.

ARM Cortex - M3 66
 Memory Access Attributes

Bufferable: Write to memory can be carried out by a write buffer

while the processor continues on next instruction execution.
Cacheable: Data obtained from memory read can be copied to a
memory cache so that next time it is accessed the value
is obtained from the cache to speed up the program execution.
Executable: The processor can fetch and execute program code
from this memory region.
Sharable: Data in this memory region could be shared by multiple bus
masters.

Memory Access Attributes are predefined for each Memory Region in

Cortex-M3.

ARM Cortex - M3 67
 Default Memory Access Permissions

ARM Cortex - M3 68
• Typically a CPU core cannot write to individual bits of a register.
Instead, it must write entire bytes or even words at a time.
• If a CPU needs to change the value of a bit and can only write a
byte at a time, it must first read the current value into a temporary
register, modify that value with a logic operation, and then write
the final result.
• This three-step process is aptly named Read-Modify-Write.
• Using Read-Modify-Write operations to set bits works fine when
you’re doing one thing at a time, but problems can arise when an
application is doing multiple things concurrently.
• For example, what happens if an interrupt occurs between the read
and modify operations that change the value in the register? The
new value will get overwritten.
• This race condition could lead to undesired behavior.

ARM Cortex - M3 69
 Bit Banding
• Bit-banding is a term that ARM uses to describe a feature that is
available on the Cortex M3 and M4 CPU cores. Basically, the
device takes a region of memory (the Bit-band region) and maps
each bit in that region to an entire word in a second memory region
(the Bit-band Alias Region).
• The benefit of Bit-banding is that a write to a word in the alias
region performs a write to the corresponding bit in the Bit-band
region. Also, reading a word in the alias region will return the value
of the corresponding bit in the Bit-band region.
• These operations take a single machine instruction thus eliminating
race conditions. This is especially useful for interacting with
peripheral registers where it is often necessary to set and clear
individual bits.
 Bit-band Operations

Bit-band operation allows a single load/store (atomic Read-Modify-Write)

Operation to access (R/W) to a single data bit.
BB - in two predefined memory regions called bit-band regions.
First 1 MB of the SRAM region
First 1 MB of the peripheral region.
These two memory regions can be accessed like normal memory.
Also accessed via a separate memory region called the bit-band alias.
When the bit-band alias address is used, each individual bit can be
accessed separately in the least significant bit (LSB) of each
word-aligned address.

ARM Cortex - M3 71
 Bit-banding – An Elegant Approach to Setting &
Clearing Bits

ARM Cortex - M3 72
ARM Cortex-M3 features a 1 MB area in SRAM memory called bit-band region. In this region
each bit can be accessed individually.
To access to bit-band region bits you need to do so via an aliased region, where each word
in this region is an alias to one bit in the bit-band region.
ARM Cortex-M3 Memory Map: The bit-band region starts with 0x20000000 address and the
alias starts with 0x22000000. Adapted from: Cortex-M3 Technical Reference Manual. To map
each bit in bit-band region you need 1 word in the alias region. Apparently, the size of bit-
band alias will be 32-MB.

ARM Cortex - M3 73
ARM Cortex - M3 74
 Bit-band Operations

1 MB (BB) x 32 Bits
= 32 MB (BB Alias)

LSBs

ARM Cortex - M3 75
 Bit-band Operations
For example, to set (write) bit 2 in word data in address 0x20000000

ARM Cortex - M3 76
 Bit-band Operations
For example, to read bit 2 of address 0x20000000

ARM Cortex - M3 77
 Advantages of Bit-Band Operations
1) Bit-band operation can also be used to simplify branch decisions.

For example, if a branch should be carried out based on 1 single bit in a

status register in a peripheral, instead of
Reading the whole register
Masking the unwanted bits
Comparing and branching
can simplify the operations to
Reading the status bit via the bit-band alias (get 0 or 1)
Comparing and branching

ARM Cortex - M3 78
 Advantages of Bit-Band Operations
2) Essential for situations in which resources are being shared by
more than one process.

ARM Cortex - M3 79
 Advantages of Bit-Band Operations

ARM Cortex - M3 80
 Advantages of Bit-Band Operations

ARM Cortex - M3 81
 Advantages of Bit-Band Operations

ARM Cortex - M3 82
 Advantages of Bit-Band Operations
3) Bit-band feature can be used for storing and handling Boolean data in the
SRAM region.

For example, multiple Boolean variables can be packed into one

single memory location to save memory space, whereas the access
to each bit is still completely separated when the access is
carried out via the bit-band alias address range.

4) Implement serial data transfers in general-purpose input/output (GPIO)

ports to serial devices.

Bit-Bang commonly refers to driving I/O pins under software control to provide
Serial communication functions. The Bit-Band feature in the Cortex-M3 can
be used for Bit-Banging implementations.

ARM Cortex - M3 83
 Bit-Band Operation of Different Data sizes
Bit-band operation is not limited to word transfers.
It can be carried out as byte transfers or half word transfers as well.

For example, when a byte access instruction (LDRB/STRB) is used

to access a bit-band alias address range, the accesses generated
to the bit-band region will be in byte size.
The same applies to half word transfers (LDRH/STRH).

When you use nonword transfers to bit-band alias addresses, the address
value should still be word aligned.

ARM Cortex - M3 84
 Unaligned Transfers

ARM Cortex - M3 85
 Pipeline

Three Stage

ARM Cortex - M3 86
 Pipeline
Instruction Buffer

ARM Cortex - M3 87
 Cortex M3 Detailed Block Diagram

DAP

ARM Cortex - M3 88
 Cortex M3 Detailed Block Diagram

ARM Cortex - M3 89
 Bus Interfaces
I-Code Bus (AHB Lite Protocol)
Instruction fetches - 0x00000000 to 0x1FFFFFFF.

The D-Code Bus (AHB Lite Protocol)

Data access - 0x00000000 to 0x1FFFFFFF.
Bus interface on the processor core converts the unaligned
transfers into aligned transfers.

The system Bus (AHB Lite Protocol)

Instruction fetch and data access from
0x20000000 to 0xDFFFFFFF and 0xE0100000 to 0xFFFFFFFF.

The external PPB (APB bus protocol)

Private peripheral accesses - 0xE0040000 to 0xE00FFFFF.
Some part - already used for TPIU, ETM, and the ROM table,
0xE0042000 to 0xE00FF000 - used by external peripherals .

The DAP Bus (Enhanced APB bus protocol)

ARM Cortex - M3 90
 Sys Bus

APB Ext PP Bus

Int PP Bus
AHB

Sys Bus

I & D Bus

ARM Cortex - M3 91
 Other Interfaces

ARM Cortex - M3 92
 Reset Types and Reset Signals

ARM Cortex - M3 93
 Reset Types and Reset Signals

ARM Cortex - M3 94
 Exception Types
Exceptions
1–15 for System Exceptions.
16 and above (Max 240) for External Interrupt inputs.

The value of the current running exception - IPSR, or NVICs Interrupt

Control State register (the VECTACTIVE field).

When an enabled exception occurs but cannot be carried out immediately

(for instance, if a higher-priority ISR is running or if the interrupt mask
register is set), it will be pended (except for some fault exceptions).
This means that a register (pending status) will hold the exception request
until the exception can be carried out.
This is different from traditional ARM processors. Previously, the
devices that generate interrupts, such as interrupt request (IRQ)/fast
interrupt request (FIQ), must hold the request until they are served.
Now, with the pending registers in the NVIC, an occurred interrupt will
be handled even if the source requesting the interrupt deasserts its
request signal.
ARM Cortex - M3 95
 Exception Types

ARM Cortex - M3 96
 Exception Types

ARM Cortex - M3 97
 Definitions of Priority
The Cortex-M3 –
Three fixed highest-priority levels (-3 to -1)
up to 256 levels of programmable priority (Max 128 Levels Preemption)

But Cortex-M3 chips have fewer supported Preemption Levels -

For example, 8, 16, 32, etc. This reduction of levels - by cutting out LSB of
Priority Configuration registers or Priority Level registers.

For example, A Priority Level Register with 3 Bits Implemented.

Bit 4 to bit 0 (LSB) are not implemented, always read as zero,

and writes to these bits will be ignored.
Priority levels of 0x00, 0x20, 0x40, 0x60, 0x80, 0xA0, 0xC0, and 0xE0.

ARM Cortex - M3 98
 Definitions of Priority

Available Priority Levels with 3-Bit or 4-Bit Priority Width

ARM Cortex - M3 99
 Definitions of Priority
More priority bits - increase gate counts and hence the power consumption.
M3, Minimum No. of implemented priority register widths is 3 bits (eight levels).

ARM Cortex - M3 100

 Reason for removing LSB instead of MSB bit
The reason for removing the LSB instead of MSB bit
- Portable software b/w Cortex-M3 devices.

Eg: In a controller with 3 bits implemented if an application uses

Priority Level 0x05 for IRQ #0 and Priority Level 0x03 for IRQ #1,
IRQ #1 should have higher priority.
00000 101 – 0x05 - 5 MSB bits are not implemented

Not Implemented

If the same application is ported to another controller with

2 bits implemented. Then Bit 2 (MSB) will also be removed.
000000 01 – 0x01 - 6 MSB bits are not implemented

Not Implemented

IRQ #0 will become level 0x01 and have a higher priority than IRQ #1.
ie. Priority of IRQ #0 is inverted from Low Priority to High Priority.
ARM Cortex - M3 101
 Preempt Priority and Subpriority.
Priority Group bits - Priority-level configuration registers for each exception
with programmable priority levels is divided into two halves.
The upper half (left bits) is the Preempt Priority and the lower half (right bits)
is the Subpriority.

ARM Cortex - M3 102

 Preempt Priority and Subpriority.
The Preempt Priority level defines whether an interrupt can take place
when the processor is already running another interrupt handler.
The Subpriority level value is used only when two exceptions with the
same Preempt Priority level occurred at the same time.
In this case, the exception with higher Subpriority (lower value) handled first.
As a result of the priority grouping, the maximum width of preempt
priority is 7 so there can be 128 levels instead of 256.

128 Preempt Levels

0 Preempt Levels

ARM Cortex - M3 103

 Preempt Priority and Subpriority.
Factors deciding the effective Preempt Priority level and Subpriority level,
• Implemented Bits in Priority-Level configuration registers
• Priority Group setting

For example, if the width of the configuration registers is 3 (bit 7 to bit 5)

ie. only 3 bits implemented and priority group is set to 5, have four levels
of preempt priority levels (bit 7 to bit 6), and inside each preempt level
there are two levels of subpriority (bit 5).

ARM Cortex - M3 104

 Preempt Priority and Subpriority.

Preempt Su Not Implemented

Priority b

0 0 0 0 0 0 0 0
0 0 1 0 0 0 0 0
0 1 0 0 0 0 0 0
0 1 1 0 0 0 0 0
1 0 0 0 0 0 0 0
1 0 1 0 0 0 0 0
1 1 0 0 0 0 0 0
1 1 1 0 0 0 0 0

Available Priority Levels with 3-Bit Priority Width and Priority Group Set to 5.

ARM Cortex - M3 105

 Preempt Priority and Subpriority.
For the same design, if 3 bits implemented and the priority group is
set to 0x1, there can be only eight Preempt Priority levels and
NO further Subpriority levels inside each preempt level. (Bit [1:0] of
Subpriority is always 0.)

ARM Cortex - M3 106

 Preempt Priority and Subpriority.

If M3 device has implemented all 8 bits in the priority-level

configuration registers, the Maximum No. of preemption levels it
can have is only 128, using a Priority Group setting of 0.

ARM Cortex - M3 107

 Interrupt Inputs and Pending Behavior

Interrupt Pending

Interrupt Pending Cleared Before Processor Takes Action

ARM Cortex - M3 108

 Interrupt Inputs and Pending Behavior
When the processor starts to execute an interrupt, the interrupt becomes
active and the pending bit will be cleared automatically.
Then the active status is cleared on exception exit.
Exception Entry - Pending Status Cleared & Interrupt Active Status is Set
Exception Exit - Active Status Cleared

Interrupt Active Status Set as Processor Enters Handler

ARM Cortex - M3 109

 Interrupt Inputs and Pending Behavior
If an interrupt source (Same Interrupt) continues to hold the
interrupt request signal active, the interrupt will be pended again
at the end of the interrupt service routine.
This is just like the traditional ARM7TDMI.

Continuous Interrupt Request Pends Again After Interrupt Exit

ARM Cortex - M3 110

 Interrupt Inputs and Pending Behavior
If an interrupt is pulsed several times before the processor starts
processing it, it will be treated as one single interrupt request.

Interrupt Pending Only Once, Even with Multiple Pulses Before the Handler

ARM Cortex - M3 111

 Interrupt Inputs and Pending Behavior

If an interrupt is deasserted and then pulsed again during the

interrupt service routine, it will be pended again.

Interrupt Pending Occurs Again during the Handler

ARM Cortex - M3 112

 Fault Exceptions

• Bus faults
• Memory management faults
• Usage faults
• Hard faults

ARM Cortex - M3 113

 Bus Faults
Bus faults are produced when an Error Response is received during
a transfer on the AHB interfaces.

It can happen at these stages:

Instruction fetch - Prefetch Abort
Data read/write - Data Abort
In the Cortex-M3, bus faults can also occur during the following:
• Stack PUSH in the beginning of interrupt processing - stacking error.
• Stack POP at the end of interrupt processing - unstacking error.
• Reading of an interrupt vector address (vector fetch) when
the processor starts the interrupt handling sequence (a special case
classified as a hard fault) – Vector Fetch Error
Bus faults (except vector fetches) occurs and if the bus fault handler is
enabled and no other exceptions with the same or higher priority are running,
the bus fault handler will be executed. If the bus fault handler is not enabled
or when the bus fault happens in an exception handler that has the same or
higher priority than the bus fault handler, the hard fault handler is executed.
ARM Cortex - M3 114
 Bus Faults
If another bus fault takes place when running the hard fault
handler, the core will enter a lockup state.
What can cause AHB Error Responses?
Bus faults occur when an error response is received on the AHB bus.

The common causes are as follows:

• Attempts to access an invalid memory region (for example, a memory
location with no memory attached).
• The device is not ready to accept a transfer (for example, trying to
access SDRAM without initializing the SDRAM controller).
• Attempts to carry out a transfer with a transfer size not supported
by the target device (for example, doing a byte access to a
peripheral register that must be accessed as a word).
• The device does not accept the transfer for various reasons
(for example, a peripheral that can only be programmed at the
privileged access level)

ARM Cortex - M3 115

 Bus Faults
To enable bus fault handler - set BUSFAULTENA bit in the System Handler
Control and State register in the NVIC.
Before enabling handler, ensure that the bus fault handler starting address
is set up in the vector table if the vector table has been relocated to RAM.

If the BFARVALID bit in BFSR is set, it is also possible to determine memory

location that caused the bus fault (for precise Bus Fault). This is done by
reading another NVIC register called the Bus Fault Address register (BFAR).
ARM Cortex - M3 116
 Bus Faults
Precise and Imprecise Bus Faults
Bus faults caused by data accesses can be further classified as
precise or imprecise.

In imprecise bus faults, the fault is caused by an already completed

Operation (such as a buffered write) that might have occurred a number
of clock cycles ago.

Precise bus faults are caused by the last completed operation.

For example, a memory read is precise on the Cortex-M3 because the
instruction cannot be completed until it receives the data.

ARM Cortex - M3 117

 Memory Management Faults
Memory management faults can be caused by memory accesses
that violate the setup in the MPU or by certain illegal accesses
(for example, trying to execute code from nonexecutable memory regions),
which can trigger the fault, even if no MPU is present.

Some of the common MPU faults include the following:

• Access to memory regions not defined in MPU setup.
• Writing to read-only regions.
• An access in the user state to a region defined as privileged access only.

If the processor is already running an exception handler with the same

or higher priority or if the memory management fault handler is
not enabled, the hard fault handler will be executed instead.

If a memory management fault takes place inside the hard fault handler
or the NMI handler, the processor will enter the lockup state.

ARM Cortex - M3 118

 Memory Management Faults
MEMFAULTENA bit in the System Handler Control and State register
in the NVIC is set to enable Memory Fault Handler.
If the vector table has been relocated to RAM, the Memory Management
Fault handler starting address should be set up in the vector table first.

If the MMARVALID bit in the MFSR is set, it is also possible to determine

the memory address location that caused the fault from the Memory
Management Address register (MMAR) in the NVIC.

ARM Cortex - M3 119

 Usage Faults
Usage faults can be caused by a number of reasons:
• Undefined instructions
• Coprocessor instructions (Coprocessor emulation)
• Trying to switch to the ARM state
• Invalid interrupt return (link register contains invalid/incorrect values)
• Unaligned memory accesses using multiple load or store instructions

It is also possible, by setting up certain control bits in the NVIC, to

generate usage faults for the following:
• Divide by zero
• Any unaligned memory accesses

If the processor is already running an exception handler with the same

or higher priority or if the usage fault handler is not enabled, the
hard fault handler will be executed instead.

If a usage fault takes place inside the hard fault handler or the NMI handler,
the processor will enter the lockup state.
ARM Cortex - M3 120
 Usage Faults
Usage fault handler is enabled by setting the USGFAULTENA bit in
System Handler Control and State register in the NVIC.
If the vector table has been relocated to RAM, the usage fault handler
starting address should be set up in the vector table first.

ARM Cortex - M3 121

 Hard Faults
The hard fault handler can be caused by usage faults, bus faults,
and memory management faults if their handler cannot be executed.
In addition, it can also be caused by a bus fault during vector fetch
(reading of a vector table during exception handling).

If none of these status register bits are set one should check the other
FSRs (Fault Status Register) to determine the cause of the hard fault.

All fault status bits for all FSRs can be cleared by writing 1 to the bit.
ARM Cortex - M3 122
 Dealing with Faults

Fault-handling methods :
Reset: SYSRESETREQ control bit in the Application Interrupt
and Reset Control register in the NVIC – Reset most of the System
except Debug Logic. VECTRESET bit – Reset Processor alone.

Recovery: Resolve the problem that caused the fault exception.

Eg. Coprocessor instructions, the problem can be resolved using
coprocessor emulation software.

Task termination: For systems with OS, terminate task and restart.

The FSRs retain their status until they are cleared manually.
Fault handlers should clear the fault status bit they have dealt with.

ARM Cortex - M3 123

 PendSV
• PendSV stands for Pendable Service Exception. It's a feature found
in ARM Cortex-M microcontrollers, which are commonly used in
embedded systems.
• PendSV is a special exception that can be triggered by software to
request a context switch in a preemptive multitasking operating
system.
• In systems using an operating system like FreeRTOS, for example,
PendSV can be used to request a context switch from within an
interrupt service routine (ISR).
• This allows for efficient task scheduling and management in real-
time embedded applications.

ARM Cortex - M3 124

 PendSV
• When the PendSV interrupt is triggered, it is usually handled
by the operating system's scheduler, which decides which
task should run next based on its priority and other factors.
• This context switch can happen immediately if the newly
selected task has a higher priority than the currently running
task, or it can be deferred to a later time if necessary.
• Overall, PendSV is a critical feature for managing task
scheduling and preemptive multitasking in ARM Cortex-M
based embedded systems.

ARM Cortex - M3 125

 SVC
• It's an instruction used in ARM processors to request a service
from the operating system's supervisor mode, often used in
operating systems to invoke system calls.
• When an application running in user mode needs to perform
privileged operations or access resources that are restricted
to the operating system, it executes an "svc" instruction.
• This triggers a switch to supervisor mode, where the
operating system can handle the request. The operating
system then typically looks at the value passed in the "svc"
instruction (usually a numeric identifier), which corresponds
to a particular service or system call.

ARM Cortex - M3 126

 • Based on this identifier, the operating system
executes the appropriate handler routine to fulfill
the requested service.
• For example, in ARM Cortex-M microcontrollers, SVC
instructions are used in conjunction with the
operating system to implement various system
services such as task scheduling, memory
management, and I/O operations.

ARM Cortex - M3 127

 Supervisor Call And Pendable Service Call
Supervisor Call (SVC) and Pendable Service Call (PendSV) are two
exceptions targeted at software and operating systems.
SVC is for generating system function calls.

For example, instead of allowing user programs to directly access

hardware, an operating system may provide access to hardware through
an SVC.

SVC makes software more portable because the user application does
not need to know the programming details of the hardware.
The user program will only need to know (API) ; the actual hardware-level
programming is handled by device drivers.

ARM Cortex - M3 128

 Supervisor Call And Pendable Service Call

SVC cannot be pended but PendSV can be pended.

PendSV (Pendable Service Call) works with SVC in the OS. Although SVC (by
SVC instruction) cannot be pended (an application calling SVC will expect the
required task to be done immediately), PendSV can be pended and is useful for
an OS to pend an exception so that an action can be performed after other
important tasks are completed.

PendSV is generated by writing 1 to the PENDSVSET bit in the NVIC Interrupt

Control State register.

A typical use of PendSV is context switching (switching between tasks).

For example, a system might have two active tasks, and context switching can
be triggered by the following:

• Calling an SVC function

• The system timer (SYSTICK)

ARM Cortex - M3 129

 Example: SVC

Eg : A System with two tasks, and a context switch is triggered by SYSTICK

exceptions

ARM Cortex - M3 130

 Problem: SVC
If an interrupt request takes place before the SYSTICK exception, the
SYSTICK exception (higher Priority) will preempt the IRQ handler.

Since SysTick is of Higher Priority, OS carry out Context Switching, So

• IRQ handler process will be delayed
• Usage fault - OS tries to switch to thread mode with an active interrupt.

Problem with Context Switching at the IRQ

ARM Cortex - M3 131

 Solution : Pendable Service Call
The PendSV Exception solves the problem of delaying IRQ by delaying the
context-switching request until all other IRQ handlers have completed.

To do this, the PendSV is programmed as the lowest priority exception.

If the OS detects that an IRQ is currently active (IRQ handler running and
preempted by SYSTICK), it defers the context switching by pending the PendSV
exception.

Example Context Switching with PendSV

ARM Cortex - M3 132

 Example: Context Switching with PendSV
1) Task A calls SVC (OS) for task switching (for example, waiting for some
work to complete).

ARM Cortex - M3 133

 Example: Context Switching with PendSV
2) The OS receives the request, prepares for context switching, and pends
the PendSV exception.

ARM Cortex - M3 134

 Example: Context Switching with PendSV
3) When the CPU exits SVC, it enters PendSV immediately and does the
context switch.

ARM Cortex - M3 135

 Example: Context Switching with PendSV
4) When PendSV finishes and returns to the thread level, it executes Task B.

ARM Cortex - M3 136

 Example: Context Switching with PendSV
5) An interrupt occurs and the interrupt handler is entered.

ARM Cortex - M3 137

 Example: Context Switching with PendSV
6) While running the interrupt handler routine, a SYSTICK exception (for
OS tick) takes place.

ARM Cortex - M3 138

 Example: Context Switching with PendSV
7) The OS carries out the essential operation, then pends the PendSV
exception for Context Switching (OS won’t perform Context
Switching directly) and gets ready for the context switch.
PendSV is the lowest priority Exception

ARM Cortex - M3 139

 Example: Context Switching with PendSV
8) When the SYSTICK exception exits, it returns to the interrupt service
routine (Without performing Context Switching by PendSV as it is
having Lowest Exception Priority).

ARM Cortex - M3 140

 Example: Context Switching with PendSV
9) When the interrupt service routine completes, the PendSV starts
and does the actual context switch operations.

ARM Cortex - M3 141

 Example: Context Switching with PendSV
10) When PendSV is complete, the program returns to the thread level;
this time it returns to Task A and continues the processing.

ARM Cortex - M3 142

 Example: Context Switching with PendSV
1) Task A calls SVC for task switching (for example, waiting for some work
to complete).
2) The OS receives the request, prepares for context switching, and
pends the PendSV exception.
3) When the CPU exits SVC, it enters PendSV immediately and does the
context switch.
4) When PendSV finishes and returns to the thread level, it executes Task
B.
5) An interrupt occurs and the interrupt handler is entered.
6) While running the interrupt handler routine, a SYSTICK exception (for
OS tick) takes place.
7) The OS carries out the essential operation, then pends the PendSV
exception and gets ready for the context switch.
8) When the SYSTICK exception exits, it returns to the interrupt service
routine.
9) When the interrupt service routine completes, the PendSV starts
and does the actual context switch operations.
10)When PendSV is complete, the program returns to the thread level; this
time it returns to Task A and continues the processing.

ARM Cortex - M3 143

 The SYSTICK Timer
SYSTICK timer is a 24-bit down counter
Once it reaches zero, the counter loads the reload value from the RELOAD
register.
It does not stop until the enable bit in the SYSTICK Control and Status
register is cleared.

Two different clock sources - SYSTICK counter

• Core free-running clock (not from the system clock HCLK, so
it does not stop when the system clock is stopped).
• External reference clock (atleast two times slower than the
free-running clock because this signal is sampled by the free-
running clock.)

To determine availability of external clock source - check bit 31

of the SYSTICK Calibration register.

ARM Cortex - M3 144

 The SYSTICK Timer

ARM Cortex - M3 145

 The SYSTICK Timer
When the SYSTICK timer changes from 1 to 0 (roll over), it will
set the COUNTFLAG bit in the SYSTICK Control and Status register.
COUNTFLAG can be cleared by
• Read - SYSTICK Control and Status register by the processor.
• Clear the SYSTICK counter value by writing any value to the
SYSTICK Current Value register.

SYSTICK counter - generate SYSTICK exceptions at regular intervals.

Used by OS, for task and resources management.
Enable SYSTICK exception generation - Set TICKINT.

The Calibration Value register provides a solution for applications

to generate the same SYSTICK interrupt interval when running on
various Cortex-M3 products.
Write the 24 bit value (Chip manuf.) in TENMS to the Reload value register.
This will give an interrupt interval of about 10 ms.

ARM Cortex - M3 146

 The SYSTICK Timer

ARM Cortex - M3 147

 Steps to Configure SYSTICK Timer
Timer stops counting when the processor is halted during debugging.

To set up the SYSTICK Timer, - programming sequence is as follows:

• Disable SYSTICK by writing 0 to the SYSTICK Control and Status register.

• Write new reload value to the SYSTICK Reload Value register.
• Write to the SYSTICK Current Value register to clear the current value to 0.
• Write to the SYSTICK Control and Status register to start the SYSTICK timer.

For users of Cortex Microcontroller Software Interface Standard (CMSIS)

compliant device driver,

ARM Cortex - M3 148

 Steps to Configure SYSTICK Timer
For example, to generate SYSTICK exception every 1024 processor
clock cycle, you can use the following C code:

The SYSTICK counter can also be used as an alarm timer that starts
a certain task after a number of clock cycles.

For example, if a task has to be started to execute after 300 clock

cycles, we could set up the task at the SYSTICK exception handler
and program the SYSTICK timer so that the task will be executed
when the 300 cycle count is reached:

ARM Cortex - M3 149

 The SYSTICK Timer

Interrupt
Handler

ARM Cortex - M3 150

 Power Management
Sleep Modes
Sleep Modes - Power Management feature.
During sleep mode, the system clock can be stopped, but the
free-running clock input could still be running to allow the processor to
be woken by an interrupt.

The two sleep modes.

• Sleep
• Deep sleep

ARM Cortex - M3 151

The sleep modes are invoked by
• Wait-For-Interrupt (WFI) or
• Wait-For-Event (WFE) instructions.
Events can be any one of these,
• Interrupts
• Previously triggered interrupt,
•External event signal pulse via the Receive Event (RXEV) signal.

Inside the processor, there is a latch for events, so a past event can wake
up a processor from WFE.

ARM Cortex - M3 152

 To wake the processor from WFI sleep, the interrupt will have to be
higher priority than the current priority level (if it is an executing interrupt)
and higher than the level set by the BASEPRI register or mask registers
(PRIMASK and FAULTMASK).

If an interrupt is not going to be accepted due to priority level,

it will not wake up a sleep caused by WFI.

ARM Cortex - M3 153

 Sleep On Exit
Another feature of sleep mode is that it can be programmed to go
back to sleep automatically after the interrupt routine exit.
In this way, we can make the core sleep all the time unless an
interrupt needs to be served.
To use this feature, we need to set the SLEEPONEXIT bit in
the System Control register

ARM Cortex - M3 154

 Sleep On Exit

ARM Cortex - M3 155

 Wakeup Interrupt Controller (Optional)
• There are no programmable registers in the WIC, as it gets interrupt
information via the interface between WIC and NVIC.
• The clock signals to the processor core can be completely stopped.
• When an interrupt request arrives, the WIC can send a wakeup request
to the system controller or Power Management Unit (PMU) in the chip
to restore the processor clock.
• Most of Cortex-M3 processor – sleep in Deep Sleep mode, leaving a
small portion of the logic gates to retain the current state of the logic.
This technology is called State Retention Power Gating (SRPG).
• The maximum interrupt latency - the time required to power up the system
(20 to 30 clock cycles).
• WIC Stops the SYSTICK timer during Deep Sleep.
• Power down feature is disabled when a debugger is attached
(access the debug registers - status of the processor).

ARM Cortex - M3 156

 Wakeup Interrupt Controller

ARM Cortex - M3 157

 Multiprocessor Communication

The processor has two signals,

• output signal, called Transmit Event (TXEV), for sending out events
• Input signal, called RXEV, for receiving events

The processor can enter sleep - WFE instruction is executed and

can continue the instruction execution when an External Event is received.
If we use an instruction called Send Event (SEV),
one processor can wake up another processor that is in sleep mode and
make sure both processors start executing a task at the same time.

ARM Cortex - M3 158

 Multiprocessor Communication

SEV Instruction
One processor
can wake up
TXEV another processor
RXEV that is in sleep mode

• The processor could also be woken by other events, such as

interrupt and debugging events.
• Therefore, before starting the required synchronized task, it is
necessary to check whether the wakeup was caused by task
synchronization.
ARM Cortex - M3 159
 Multiprocessor Communication

(SEV – Local Event

Latch is Set)

Local Event Latch is

Cleared

ARM Cortex - M3 160

 Self-Reset Control
System Reset
• SYSRESETREQ bit in the NVIC register.
• Assert reset request signal to the system’s reset generator.
• The system reset generator is not part of Cortex-M3 design,
so check the chip’s specification to determine which part of
the chip is reset by SYSRESETREQ.

Vector Reset
• VECTRESET control bit in the NVIC Application Interrupt and
Reset Control register (bit [0]).
• Writing 1 to this bit will reset the Cortex-M3 processor,
excluding the debug logic.
• This does not reset any circuit outside the Cortex-M3
processor.

• Software reset - SYSRESETREQ instead of VECTRESET. So

most parts of the system will be reset at the same time.

ARM Cortex - M3 161

Debug Architecture - CoreSight Architecture
Debug host
Interface Processor Debugging
Interface

• SWJ or SW-DP - converts the external signals into a generic 32-bit

debug bus (DAP Bus)
• Address of DAP bus is 32-bit, upper 8 bits - to select which device is
being accessed.
• Up to 256 devices can be attached to the DAP bus.
• In Cortex-M3 processor, only one device address is used, so 255 more AP
devices can be attached to the DAP bus.
• AHB-AP - Bus bridge to convert commands into AHB transfers, which are
inserted into the internal bus network inside the Cortex-M3. This allows access
to M3 Memory Map and Debug control registers in the NVIC.
ARM Cortex - M3 162
 CoreSight Architecture

Trace Interface
• Instruction trace: Generated by the Embedded Trace Macrocell (ETM)
• Data trace: Generated by the DWT unit
• Debug message: Generated by ITM, provides message output such as
printf in the debugger graphical user interface

• Trace results - data packets, are output from the trace sources
like ETM, using Advanced Trace Bus (ATB) Interface.
• In CoreSight, if an SoC contains multiple trace sources (e.g.,
multiprocessors), the ATB data stream can be merged using
ATB merger hardware called ATB funnel.
• The final data stream on the chip sent to Trace Port Interface
Unit (TPIU) and exported to external trace hardware.
• Once the data reach the debug host (for example, a PC), the
data stream can then be converted back into multiple data
streams.

ARM Cortex - M3 163

 Standard CoreSight Characteristics
• The memory content and peripheral registers can be examined
even when the processor is running.
• Multiple processor debug interfaces can be controlled with a single
piece of debugger hardware.
For example, if JTAG is used, only one Test Access Port (TAP)
controller is required, even when there are multiple processors on
the chip.
• Internal debugging interfaces are based on simple bus design,
making it scalable and easy to develop additional test logic for
other parts of the chip or SoC.
• It allows multiple trace data streams to be collected in one trace
capture device and separated back into multiple streams on the
debug host.

ARM Cortex - M3 164

 Modified CoreSight in Cortex M3

• Trace components are specially designed in the Cortex-M3. Some

of the ATB interface is 8 bits wide in the Cortex-M3, whereas in
CoreSight the width is 32 bits.
• The debug implementation in the Cortex-M3 does not support
TrustZone. TrustZone is an ARM technology that provides security
features to embedded products.
• The debug components are part of the system memory map,
whereas in standard CoreSight systems, a separate bus (with a
separate memory map) is used for controlling debug components.

Although the Debug components in Cortex-M3 are build differently

from normal CoreSight systems, the communication interface and
protocols in the Cortex-M3 are compliant to CoreSight
architecture and can be directly attached to other CoreSight
systems.

ARM Cortex - M3 165

 Standard Vs Modified CoreSight in M3

Design Concept of
CoreSight System

The Debug System in

Cortex-M3 (Modified CoreSight)

The debug components are part of the

system memory map in M3, but in
standard CoreSight systems, a separate
bus (with a separate memory map) is used
for controlling debug components.
ARM Cortex - M3 166
 Debug Modes

Halt Mode
• Processor stops program execution completely.
Debug Monitor Mode
• Processor executes an exception handler to carry
out the debugging tasks.

ARM Cortex - M3 167

 Debug Modes
Halt mode:
• Instruction execution is stopped.
• The System Tick Timer (SYSTICK) counter is stopped.
• Supports single-step operations.
• Interrupts can be pended and can be invoked during single stepping or
be masked so that external interrupts are ignored during stepping.
Debug monitor mode:
• Processor executes exception handler type 12 (debug monitor).
• SYSTICK counter continues to run.
• New arrive interrupts may or may not preempt, depending on the priority of
the debug monitor and the priority of the new interrupt.
• If the debug event takes place when a higher-priority interrupt is running,
the debug event will be missed.
• Supports single-step operations.
• Memory contents (for example, stack memory) could be changed by the
debug monitor handler during stacking and handler execution.
• Invoked by means of Debug Events, as well as by manually setting the pending bit.
ARM Cortex - M3 168
 Debug Modes – Halt Mode
• To Enable Halt mode, the C_DEBUGEN bit in the NVIC Debug
Halting Control and Status register (DHCSR) must be set.
• This bit can only be programmed through the DAP, so you
cannot halt the Cortex-M3 processor without a debugger.
• After C_DEBUGEN is set, the core can be halted by setting the
C_HALT bit in DHCSR.
• This bit (C_HALT) can be set by either the debugger or by the
software running on the processor itself.
• The bit field definition of DHCSR differs between read operations
and write operations.
• For write operations, a debug key value must be used on bit
31 to bit 16.
• For read operations, there is no debug key and the return
value of the upper half word contains the status bits.

ARM Cortex - M3 169

 Debug Modes – Halt Mode

Status
Bits

Reset by
Power On
Reset

ARM Cortex - M3 170

 Debug Modes – Debug Monitor Mode

• NVIC’s Debug Exception and Monitor Control register, is used to control the
debug activities.
• MON_EN used to enable Debug Monitor Exception.
• TRCENA is used to enable Trace System (DWT, ETM, etc.)

Vector Catch (VC)

• This can be used only with halt mode debugging.
• When a fault (or core reset) takes place and the corresponding VC
control bit is Set,
• Halt request will be set
• Core will halt as soon as the current instruction completes

• The TRCENA control bit and VC control bits in (DEMCR) are reset by power-
on reset, not by System reset.
• The control bits for Monitor Mode Debug, however, are reset by power-on
reset and system reset.

ARM Cortex - M3 171

 Debug Modes – Debug Monitor Mode

Reset
by
POR
&
System
Reset

Reset
by
Power
On
Reset

ARM Cortex - M3 172

 Debugging Events – Halt Mode
Manual Halt
The Cortex-M3 can enter debug mode
(both halt or debug monitor exception)
for a number of possible reasons.

EDBGREQ

MON_EN =1 (in DEMCR)

MON_EN = 0

ARM Cortex - M3 173

 Debugging Events – Halt Mode

• The External Debug Request is from a signal called EDBGREQ

on the Cortex-M3 processor.
• EDBGREQ can be connected to accept debug events from
additional debug components or for a multiprocessor system,
it due to debug events from another processor.

• After debugging is completed, the program execution can be

returned to normal by clearing the C_HALT bit.

ARM Cortex - M3 174

 Debugging Events – Debug Monitor Mode

Manual Debug
Monitor Exception
Request

EDBGREQ

ARM Cortex - M3 175

 Debugging Events – Debug Monitor Mode

• Debug Monitor Exception is just one type of exception and

can be affected by the current priority of the processor if it is
running another exception handler.

• After debugging is completed, the program execution can be

returned to normal by carrying out an exception return.

ARM Cortex - M3 176

 Breakpoint in the Cortex-M3

Types of Breakpoint
• Breakpoint instruction
• Breakpoint using address comparators in the FPB

ARM Cortex - M3 177

 Breakpoint in the Cortex-M3
Breakpoint Instruction
• The breakpoint instruction (BKPT #immed8) is a 16-bit Thumb
instruction with encoding 0xBExx.
• The lower 8 bits depend on the immediate data given following the
instruction.

• When this instruction is executed, it generates a debug event and can

halt the processor core if C_DBGEN is set, or it can trigger debug
monitor exception if the MON_EN is enabled.

• When Debug Monitor exception returns, it is returned to the address of

the BKPT instruction, not the address after the BKPT instruction.
• This is because in normal use of breakpoint instructions, the BKPT is
used to replace a normal instruction.
• When the breakpoint is hit and the debug action is carried out, the
instruction memory is restored to the original instruction, and the rest
of the instruction memory is unaffected.

ARM Cortex - M3 178

 Breakpoint in the Cortex-M3

If the BKPT instruction with C_DEBUGEN = 0 and MON_EN = 0,

it will cause hard fault exception,
• DEBUGEVT = 1 in the Hard Fault Status register (HFSR)
• BKPT = 1 in the Debug Fault Status register (DFSR)

Breakpoint using address comparators in the FPB

• The FPB unit can be programmed to generate breakpoint
events even if the program memory cannot be altered.
• However, it is limited to six instruction addresses and two literal
addresses.

ARM Cortex - M3 179

 Accessing Register Content in Debug
The Debug Core Register Selector register (DCRSR) and the Debug Core Register
Data register (DCRDR) allow the debugger to access registers of the processors.
The register transfer - only when the processor is halted (Only in Halt Mode).

ARM Cortex - M3 180

 Accessing Register Content in Debug
Steps to read register contents,
1) Make sure the processor is halted.
2) Write to the REGWnR = 0 (DCRSR), indicating it is a read
operation. REGSEL = Corresponding Reg. No.
3) Poll until the S_REGRDY bit in DHCSR is 1.
4) Read the DCRDR to get the register content.

ARM Cortex - M3 181

 Accessing Register Content in Debug
Steps to write to register,
1) Make sure the processor is halted.
2) Write data value to the DCRDR. REGSEL = Corresponding Reg. No.
3) Write to the REGWnR = 1 (DCRSR), to indicate write operation.
4) Poll until the S_REGRDY bit in DHCSR is 1.

ARM Cortex - M3 182

 Other Core Debugging Features
External debug request signal:
• Allows the Cortex-M3 processor to enter debug mode through an
external event such as debug status of other processors in a
multiprocessor system.
• This feature is very useful for debugging a multiprocessor system.
• In simple microcontrollers, this signal is likely to be tied low.

Debug Fault Status Register (DFSR):

• Available for the debugger to determine the debug event that has
taken place.

Reset control:
• During debugging, the processor core can be restarted using the
VECTRESET control bit or SYSRESETREQ control bit in the NVIC
Application Interrupt and Reset Control register.
• Using this reset control register, the processor can be reset without
affecting the debug components in the system.

ARM Cortex - M3 183

 Other Core Debugging Features
Interrupt masking:
• This feature is very useful during stepping.
• For example, if you need to debug an application but do not want to
execute the interrupt service routine during the stepping, the
interrupt request can be masked. This is done by setting the
C_MASKINTS bit in the DHCSR.

Stalled bus transfer termination:

• If a bus transfer is stalled for a very long time, it is possible to
terminate the stalled transfer by an NVIC control register.
• This is done by setting the C_SNAPSTALL bit in the DHCSR.
• This feature can be used only by a debugger during halt.

ARM Cortex - M3 184

 Trace System in Cortex M3
• Cortex-M3 Trace System based on CoreSight architecture.
• Trace results are generated in the form of packets, which can
be of various lengths (in terms of number of bytes).
• Trace components transfer the packets using Advanced Trace
Bus (ATB) to the Trace Port Interface Unit (TPIU) which
formats the packets into Trace Interface Protocol.
• The data is then captured by an external trace capture device
such as a Trace Port Analyzer (TPA).

ARM Cortex - M3 185

 Thank
You
ARM Cortex - M3 186