4.5.3. Exceptions

For processors that support vector table relocation, the vector table resides at:

Note

HIVECS is an input signal to the processor, that is tied HIGH to indicate the High-vectors configurations. On some processors this signal is called VINITHI.

In ARMv6 and later, interrupts might be relocatable to any address, and in processors implementing the Security Extensions all exceptions are relocatable. These processors are only supported by ETMv3.

In ETMv1 and ETMv2, detection of exceptions is only possible if the value of HIVECS remains constant during the trace run, and this value is known to the decompressor. In ETMv3 and later, knowledge of HIVECS is not required because exceptions are explicitly flagged in the trace.

The possible exception types and the corresponding trace behavior are:

Processor reset

This causes the current instruction to be abandoned. When the processor reset is deasserted a branch occurs to the reset vector.

Interrupts (IRQ and FIQ)

These cause the interrupted instruction to become a branch to the appropriate exception vector.

Prefetch abort

When the aborted instruction is executed, it becomes a branch to the Prefetch abort vector.

Data abort

The instruction on which the data abort is signaled becomes a branch to the Data abort vector. This instruction might have data traced, that must be ignored.

In ETMv1 and ETMv2, all branches to these exception vectors must be treated as an exception.

In ETMv3, these exceptions are explicitly flagged in the protocol at the time of the branch. A branch to these exception vectors that is not flagged must be treated as a normal branch.

Undefined Instruction

When the undefined instruction is encountered, it becomes a branch to the Undefined Instruction vector.

SVC

When the SVC instruction is executed, it becomes a branch to the SVC vector.

SMC

When the SMC instruction is executed, it becomes a branch to the SMC vector.

Note

In each of these cases, the next instruction traced is the instruction at the exception vector.

The trace decompressor can treat exceptions as belonging to one of two categories:

Processor reset, IRQ, FIQ, prefetch abort

In ETMv1 and ETMv2, all branches to these exception vectors must be treated as an exception. The instruction on which the branch occurred was canceled and must not be marked as executed.

In ETMv3, these exceptions are explicitly flagged in the protocol at the time of the branch. A branch to these exception vectors that is not flagged must be treated as a normal branch.

Data abort, Undefined Instruction, SVC, SMC

In ETMv1 and ETMv2, all branches to these exception vectors must be treated as an exception. The instruction on which the branch occurred was not canceled and must be marked as executed.

In ETMv3, these exceptions are explicitly flagged in the protocol at the time of the branch. A branch to these exception vectors that is not flagged must be treated as a normal branch.

For some ARM7 and ARM9 processors, tracking the pipeline is not always possible under some exception sequences. This might result in tracing an exception by changing the pipeline status for the last instruction executed to a Branch Executed (BE) or Branch Executed with Data (BD) to the exception vector. See the relevant ETM Technical Reference Manual for more information.

Instruction execute means that the instruction at that address has reached the Execute stage of the pipeline and includes instructions that fail their condition codes. This is slightly different from the pipeline status codes that indicate instruction executed and condition code test passed (these codes have the letter E, standing for “Executed”, in their mnemonics), and instruction executed and condition code failed (these codes have the letter N, standing for Not Executed, in their mnemonics).

If the instruction reaches execution but fails its condition code test, a pipeline status code or P-header is generated that includes the letter N in its mnemonic, to indicate an instruction not executed. ETMv1.2 introduced the facility to control trace using the result of the condition code test whenever an instruction is executed.

Table 4.2 shows how ETMv3 traces exceptions. In many cases, exceptions can be either cancelling or non-cancelling depending on when the last instruction traced completed execution. Where an exception can be cancelling or non-cancelling, the value of r14 in the exception handler and the address of the last traced instruction determine whether the last traced instruction was canceled. For example, when an FIQ occurs, if the last traced instruction was at r14-4, this instruction was canceled because the exception handler returns to re-execute this instruction. If the last traced instruction was at r14-8, the last traced instruction was not canceled.

Table 4.2. ETMv3 exception tracing

ExceptionCancellingNon-cancelling
Halt, entry to Debug stateLast instruction traced did not completeLast instruction traced completed
Secure Monitor Call [a] (SMC)-SMC always completes
Asynchronous data abortLast instruction traced (r14-8) did not completeLast instruction traced (r14-12) completed
Jazelle/ThumbEE[b]Last instruction traced caused the exceptionLast instruction traced did not cause the exception
Processor resetThis is always cancelling-
Undefined Instruction-Always non-cancelling
Supervisor Call [a] (SVC)-Always non-cancelling

Prefetch abort [c]

External prefetch abort [c]

Breakpoint debug exception[c]

Watchpoint debug exception[c]

BKPT instruction[c]

Last instruction traced (r14-4) did not completeLast instruction traced (r14-8) completed

DABORT[c]

Vector Catch Debug Exception

Last instruction traced (r14-8) did not completeLast instruction traced (r14-12) completed
Generic exception for implementation defined exceptionsLast instruction traced did not completeLast instruction traced completed
IRQLast instruction traced (r14-4) did not completeLast instruction traced (r14-8) completed

NMI

FIQ

Last instruction traced (r14-4) did not completeLast instruction traced (r14-8) completed

[a] Before ARMv7, the Secure Monitor Call (SMC) was called the Secure Monitor Interrupt (SMI), and the Supervisor Call (SVC) was called the Software Interrupt (SWI).

[b] Jazelle and ThumbEE exceptions can be cancelling or non-cancelling. See Jazelle and ThumbEE exceptions.

[c] ARM recommends that you trace and cancel these exceptions because it is useful to output the instruction that caused the exception in the trace stream. In these cases, the instruction that causes the exception is traced and then indicated as canceled.


Processor Reset exceptions are always traced as cancelling. However, zero or more instructions might not complete execution when a processor Reset exception occurs.

Where an instruction is considered for tracing, subject to TraceEnable, it must be considered by the address comparators. For example, a prefetch abort can be traced in one of two ways:

When traced as cancelling, the prefetch aborted instruction address is compared by the comparators and is subject to the rules defined in Address comparators. When traced as non-cancelling, the ETM does not know the address of the prefetch aborted instruction because the instruction is not traced so the comparators do not compare based on this address.

Jazelle and ThumbEE exceptions

For Jazelle and ThumbEE exceptions, the cancelling concept is:

  • if the instruction that caused the exception, for example an index check instruction, is traced, it must be canceled

  • if the instruction was not traced, the exception must be non-cancelling.

For null pointer checks on loads and stores, if the instruction is traced the exception must be cancelling. Otherwise it is non-cancelling. If the data transfer is traced, decompression tools must discard the data transfer, and the ETM comparators treat the data transfer as if it were an aborted data transfer. For more information, see Address comparators.

Copyright © 1999-2002, 2004-2009, 2011 ARM Limited. All rights reserved.ARM IHI 0014Q
Non-ConfidentialID101211