13.3.3.  Angel debugger functions

This section gives a summary of how Angel performs the basic debugger functions:

Reporting processor and memory status

Angel reports the contents of memory and the processor registers as follows:


The memory address being examined is passed to a function that copies the memory as a byte stream to the transmit buffer. The data is transmitted to the host as an ADP packet.


Processor registers are saved into a data block when Angel takes control of the target (usually at an exception entry point). When processor status is requested, a subset of the data block is placed in an ADP packet and transmitted to the host.

When Angel receives a request to change the contents of a register, it changes the value in the data block. The data block is stored back to the processor registers when Angel releases control of the target and execution returns to the target application.


When downloading a program image to your board, the debugger sends a sequence of ADP memory write messages to Angel. Angel writes the image to the specified memory location.

Memory write messages are special because they can be longer than other ADP messages. If you are porting Angel to your own hardware your device driver must be able to handle messages that are longer than 256 bytes. The actual length of memory write messages is determined by your Angel port. Message length is defined in devconf.h with:


Setting breakpoints

Angel uses three undefined instructions to set breakpoints. The instruction used depends on:

  • the endianness of the target system

  • the processor state (ARM or Thumb).

ARM state

In ARM state, Angel recognizes the following words as breakpoints:


for little-endian systems.


for big-endian systems.

Thumb state

In Thumb state, Angel recognizes 0xDEFE as a breakpoint.


These are not the same as the breakpoint instructions used by Multi-ICE or EmbeddedICE.

These instructions are used for normal, user interrupt, and vector hit breakpoints. In all cases, no arguments are passed in registers. The breakpoint address itself is where the breakpoint occurs.

When you set a breakpoint, Angel:

  • stores the original instruction to ensure that it is returned if the area containing it is examined

  • replaces the instruction with the appropriate undefined instruction.

The original instruction is restored when the breakpoint is removed, or when a request to read the memory that contains the instruction is made in the debugger. When you step through a breakpoint, Angel replaces the saved instruction and executes it.


Angel can set breakpoints only on RAM locations.

When Angel detects an undefined instruction it:

  1. Examines the instruction by executing an:

    • LDR instruction from lr – 4, if in ARM state

    • LDR instruction from lr – 2, if in Thumb state.

  2. If the instruction is the predefined breakpoint word for the current processor state and endianness, Angel:

    1. halts execution of the application

    2. transmits a message to the host to indicate the breakpoint status

    3. executes a tight poll loop and waits for a reply from the host.

    If the instruction is not the predefined breakpoint word, Angel:

    1. reports it to the debugger as an undefined instruction

    2. executes a tight poll loop and waits for a reply from the host.

ARM breakpoints are detected in Thumb state. When an ARM breakpoint is executed in Thumb state, the undefined instruction vector is taken whether executing the instruction in the top or bottom half of the word. In both cases these correspond to a Thumb undefined instruction and result in a branch to the Thumb undefined instruction handler.


Thumb breakpoints are not detected in ARM state.

Copyright © 1997, 1998 ARM Limited. All rights reserved.ARM DUI 0040D