7.3.5. Branch Packets

Branch packets are used to indicate the destination address of indirect branches. See Direct and indirect branches for more information on indirect branches. Branch packets are also used to give information on exceptions, and to indicate changes of the instruction set state or security state of the processor.

This section provides a full description of all possible branch packets in ETMv3.0 and later.

If an instruction that causes an indirect branch is traced, a Branch address packet must be output even if the target of the branch is not traced, unless prevented by a FIFO overflow. This enables the address of the first instruction in any trace gap to be determined.

Multiple branch packets can be output for a single instruction. If this happens, each must be interpreted in turn in relation to the previous branch packet, after which all but the final branch packet must be ignored.

In cycle-accurate mode, the branch might not be traced on the same cycle as the instruction.

Branch packet summary

A branch packet consists of a maximum of five Address Bytes, optionally followed by up to three Exception Information Bytes.

The Address Bytes indicate:

  • the branch target address

  • the alignment of the instruction set, for example word, halfword or byte alignment

  • whether any Exception Information bytes follow.

The Exception Information Bytes indicate:

  • additional information about the instruction set

  • the security state

  • the hypervisor mode

  • when exceptions occur.

Note

Some implementations indicate exception information in the Address Bytes. See Branch packet formats with the original address encoding scheme, however this use is deprecated.

Figure 7.2. Branch packet structure

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


There are 2 formats used for the Address Bytes:

The ETMIDR indicates which address encoding scheme is implemented. This is bit [20] of the ETMIDR. See ID Register, ETMIDR, ETMv2.0 and later.

The Exception Information Bytes are encoded identically in all versions of the architecture. The presence of the Exception Information Bytes is indicated in the Address Bytes and is dependent on the encoding of the Address Bytes.

Some parts of the branch packet might not be output in every branch packet if they are not required to be traced, to reduce the quantity of trace generated. Table 7.5 shows how the missing bits are interpreted when they are not present.

Table 7.5. Interpretation of missing fields in branch packets

Missing fieldInterpretation
AddressThe missing address bits are the same as the last time they were traced in a branch packet or I-Sync packet.
NSThe NS bit is the same as the last time it was traced in a branch packet or I-Sync packet.
Excp[3:0]Excp[3:0] is b0000
Excp[8:4]Excp[8:4] is b00000
AltISAThe AltISA bit is the same as the last time it was traced in a branch packet or I-Sync packet.
CanCan is b0
HypThe Hyp bit is the same as the last time it was traced in a branch packet or I-Sync packet.
Resume[3:0]Resume[3:0] is b0000

Branch packet formats with the original address encoding scheme

The original branch address encoding scheme:

When a processor performs a branch operation, the destination of the branch is often close to the current address. This permits compression of the branch addresses. The ETM is required to output only the low-order bits that have changed since the last branch. The full address can be reconstructed when decompression of the trace information takes place.

To decide how many bytes are required, the on-chip logic registers the last branch address that it has output in either a branch packet or an I-Sync packet, and when another branch occurs, the new address is compared with the one that was previously output. Only sufficient low-order bits are output to cover all the bits that have changed in the address. For example, if the upper 12 bits of the address are unchanged and A[19] is the most significant bit to have changed, then it is only necessary to output A[19:0]. This can be done in three address bytes instead of five.

In the original branch encoding scheme, there are between one and five Address Bytes, as shown in Figure 2. The C bit of each Address Byte indicates if another byte follows this byte. If the C bit is 1 in Address Byte 5 then Exception Information byte 0 follows. If the C bit is 0 in any byte, this is the last byte of the branch packet.

Figure 7.3. Original encoding of ARM state branch address bytes

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.4. Original encoding of Thumb state branch address bytes

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.5. Original encoding of Jazelle state branch address bytes

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.6. Original encoding of ARM state branch with exception address bytes

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


With the original address encoding scheme, a branch with an exception always requires the trace to output five bytes of address information. In this scheme, a branch to an exception vector can be output as:

  • A 5-byte packet, with information about the exception included in Address Byte 5. See Figure 7.6. This format can only be used in ARM state, and is deprecated.

  • 5 Address Bytes, plus one or more Exception Information Bytes. See Figure 7.3 to Figure 7.5.

Depending on the alignment of the instruction set of the instruction at the address provided in the branch packet, the address bits in the Address Bytes are arranged differently. For the ARM instruction set where instructions are always word-aligned, bits [1:0] of instruction addresses are always zero and therefore only bits [31:2] are output in the trace. For the Thumb and ThumbEE instruction sets the instructions are always halfword-aligned, bit [0] of the instruction address is always zero and therefore only bits [31:1] are output in the trace. For Jazelle bytecodes, bits [31:0] are output. The alignment of the instruction set is determined from Address Byte 5.

If the alignment of the instruction set changes, then all five Address Bytes are required.

Figure 7.7. Normal Thumb branch with no change in address bits [31:7]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.8. Normal Thumb branch with no change in address bits [31:14]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.9. Normal Thumb branch with no change in address bits [31:21]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.10. Normal Thumb branch with no change in address bits [31:28]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


When there is a change in [31:28], no address compression is possible and the full 5-byte packet is required. Figure 7.11 shows this packet.

Figure 7.11. Normal Thumb branch with a change in address bits [31:28]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Table 2 shows the encodings of Address Byte 5.

Table 7.6. Address Byte 5 encodings, original encoding scheme

Address Byte 5 ValueDescription
b0C001xxx

ARM state branch address. Bits marked xxx are Address [31:29].

The C bit is set to 1 if the Exception Information Byte 0 follows this byte, otherwise this is the last byte of the branch packet.

b0C01xxxx

Thumb or ThumbEE state branch address. Bits marked xxxx are Address [31:28].

The C bit is set to 1 if the Exception Information Byte 0 follows this byte, otherwise this is the last byte of the branch packet.

b0C1xxxxx

Jazelle state branch address. Bits marked xxxxx are Address [31:27].

The C bit is set to 1 if the Exception Information Byte 0 follows this byte, otherwise this is the last byte of the branch packet.

b0x000xxx

Reserved.

b10EEExxx

Exception executed in ARM state. Bits marked xxx are Address [31:29].

The EEE bits indicate the type of exception. See Table 7.7.

This is the last byte of the branch packet.

Use of this format is deprecated in favour of using the Exception Information Bytes.

b11EEExxx

Exception executed in ARM state. Bits marked xxx are Address [31:29].

The EEE bits indicate the type of exception. See Table 7.7.

The exception cancels the last traced instruction.

This is the last byte of the branch packet.

Use of this format is deprecated in favour of using the Exception Information Bytes.


Table 3 shows the encoding of the EEE field in Address Byte 5. If Address Byte 5 is not traced then no exception occurred.

Table 7.7. EEE field encodings, original branch encoding scheme

EEE fieldException
b000

Processor reset, Undefined Instruction, SVC, prefetch abort, or data abort. The exact type of exception is determined from the branch address.

Software breakpoint and software watchpoint exceptions are also traced using this encoding and are indistinguishable from prefetch aborts and data aborts respectively.

Data aborts are always cancelling exceptions, as indicated by bit [6] of Address Byte 5 set to 1.

Undefined instruction exceptions and SVC are always non-cancelling exceptions, as indicated by bit [6] of Address Byte 5 set to 0.

Processor reset exceptions and prefetch abort exceptions might be cancelling or non-cancelling.

b001

IRQ

b010

Reserved

b011

b100

Jazelle exception, other than unimplemented bytecode. The exception type is determined from the branch address in conjunction with the Jazelle exception vector table.

An ordinary exception, such as a FIQ or data abort, while in Jazelle state is not a Jazelle exception and is traced using the normal encodings.

b101

FIQ

b110

Asynchronous data abort

b111

Debug Exception


Branch packet formats with the alternative address encoding scheme

Branch packet formats with the original address encoding scheme describes the original scheme for branch address encoding:

  • The C bit of each Address Byte is used to indicate the last address byte of the packet. It is set to 0 for the last byte, and set to 1 for all other bytes.

  • Branch address compression cannot be used for exception packets.

From ETMv3.4, an ETM implementation can choose to implement an alternative scheme for branch address encoding that permits address compression on exception packets.

Bit [20] of the ETMIDR indicates whether an ETM implements the original or the alternative scheme for branch address encoding. See ID Register, ETMIDR, ETMv2.0 and later.

If implemented, the alternative encoding applies to all branch packets in ARM, Thumb and Jazelle states, including branches on an exception.

Because address compression is always applied when it is possible to do so, the branch packet formats for the alternative scheme are described in the following sections:

As with the original encoding, a branch packet is one or more bytes long. In the alternative branch address encoding scheme:

  • when bit [7] = 1, the byte is interpreted in exactly the same way as in the original scheme

  • when bit [7] = 0:

    • for the first byte of a branch packet, this is the only byte in the packet

    • otherwise, bit [6] holds indicates whether there are any Exception Information Bytes.

Table 7-6 describes the use of bits [7:6] in full. The use of these bits is clarified by the packet examples in:

Table 7.8. Interpretation of bits [7:6] in Address bytes 1-4

Address ByteBit [7]Bit [6]Interpretation
1-41-

The address continues in the next Address Byte. Bit [6] of this byte is part of the address field.

The interpretation of bit [7] is the same as it is in the original encoding.

1

0

-

This is the only Address Byte. Bit [6] of this byte is part of the address field.

The interpretation of bit [7] is the same as it is in the original encoding.

2-4

0

1

This byte contains the final address bits for the branch packet. Exception Information Byte 0 follows.

2-4

0

0

This byte contains the final address bits for the branch packet and is the last byte of the branch packet.


Depending on the alignment of the instruction set of the instruction at the address provided in the branch packet, the address bits in the Address Bytes are arranged differently. For the ARM instruction set where instructions are always word-aligned, bits [1:0] of instruction addresses are always zero and therefore only bits [31:2] are output in the trace. For the Thumb and ThumbEE instruction sets the instructions are always halfword-aligned, bit [0] of the instruction address is always zero and therefore only bits [31:1] are output in the trace. For Jazelle bytecodes, bits [31:0] are output. The alignment of the instruction set is determined from Address Byte 5.

Branch packets without Exception Information Bytes, in the alternative encoding

In the alternative encoding, for a branch packet which does not require any Exception Information Bytes:

  • the single-byte packet is exactly the same as in the original encoding

  • longer packets comprise:

    • one or more bytes with bit [7] = 1, where bits [6:0] hold address information

    • a final byte with bits [7:6] = b00, where bits [5:0] can hold address information

  • the 5-byte packet is identical to a 5-byte packet in the original encoding.

Figure 7.12. Alternative encoding of normal Thumb branch with no change in address bits [31:7]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.13. Alternative encoding of normal Thumb branch with no change in address bits [31:13]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.14. Alternative encoding of normal Thumb branch with no change in address bits [31:20]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.15. Alternative encoding of normal Thumb branch with no change in address bits [31:27]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.16. Alternative encoding of normal Thumb branch when address bits [31:27] change

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


These examples show all possible packet lengths for branches in Thumb state. Address compression is similar for branches in other processor states. The only difference is in the address bit range held in each byte of the packet:

  • Figure 7.17 shows the trace packet for a branch in ARM state when there is no change in bit [31:14] of the address

  • Figure 7.18 shows the trace packet for a branch in Jazelle state when there is no change in bit [31:19] of the address.

Figure 7.17. Alternative encoding of normal ARM branch with no change in address bits [31:14]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.18. Alternative encoding of normal Jazelle branch with no change in address bits [31:19]

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


In all processor states, the 1-byte and 5-byte packets are identical to the 1-byte and 5-byte packets in the original encoding.

Branch packets with Exception Information Bytes, in the alternative encoding

In the original encoding, address compression is not possible when any Exception Information Bytes are required, and such branch packets always require all five Address Bytes.

From ETMv3.4, the alternative encoding scheme provides address compression when any Exception Information Bytes are required. For a branch packet which requires one or more Exception Information Bytes:

  • There are at least 2 Address Bytes:

    • one or more Address Bytes with bit [7] = 1, where bits [6:0] hold address information

    • a final byte with bits [7:6] = b01, where bits [5:0] can hold address information

  • There are one or more Exception Information Bytes.

Figure 7.19. Thumb branch with exception information bytes and no change in address bits [31:13], alternative encoding

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.20. Thumb branch with exception information bytes and no change in address bits [31:20], alternative encoding

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.21. Thumb branch with exception information bytes and no change in address bits [31:27], alternative encoding

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.22. Thumb branch with exception information bytes and when address bits [31:27] change, alternative encoding

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Note

See Branch address packets for change of processor state for details of the use of the AltISA (Alternative instruction set) bit of the branch continuation byte, in ETMv3.3 and later.

These examples show all possible packet lengths for exception branches in Thumb state. Address compression is similar for branches in other processor states. The only difference is in the address bit range held in each byte of the packet:

  • Figure 7.23 shows the trace packet for an exception branch in ARM state when there is no change in bit [31:21] of the address

  • Figure 7.24 shows the trace packet for a branch in Jazelle state when there is no change in bit [31:26] of the address.

Figure 7.23. ARM branch with exception information bytes and no change in address bits [31:21], alternative encoding

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 7.24. Jazelle branch with exception information bytes and no change in address bits [31:26], alternative encoding

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Exception Information Bytes

The Exception Information Bytes indicate:

  • additional information about the instruction set

  • the security state

  • the hypervisor mode

  • when exceptions occur.

The Address Bytes are used to indicate if any Exception Information Bytes are present.

The format of the Exception Information Bytes is shown in Figure 3.

Figure 7.25. Format of Exception Information Bytes

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


The meanings of the fields are shown in Table 5.

Table 7.9. Meanings of fields in Exception Information Bytes

NameFunctionDescription
NSSecurity levelIf set to 1, the processor is in Non-secure state following the branch.

Excp[8:0]

Exception

If an exception occurs, this field indicates the exception type.

For ARMv7-M processors, see Encoding of Exception[8:0], for ARMv7-M processor architectures .

For non ARMv7-M processors see Possible combinations of Excp[8:0], Can and Resume[3:0].

Can

Canceled

If set to 1, the most recently traced instruction has been canceled and must be discarded.

AltISA

Alternative instruction set

If set to 1, the processor is in ThumbEE state after the branch. For more information see The AltISA bit, ETMv3.3 and later

Hyp

Hypervisor mode

If set to 1, indicates the processor is in Hypervisor mode after the branch.

Resume

Exception Resume

Indicates if an instruction was pause for continuation, or if a previously paused instruction was resumed. See Encoding of Exception[8:0], for ARMv7-M processor architectures .


Table 6 shows when each of the Exception Information Bytes are required.

Table 7.10. Requirements for Exception Information Bytes

Exception Information ByteRequired when any of the following apply:
0

AltISA bit changes

NS bit changes

Excp[8:0] is non-zero

Resume[3:0] is non-zero

Hyp bit changes

1

Excp[8:4] is non-zero

Hyp bit changes

2

Resume[3:0] is non-zero


If any Exception Information Bytes are required, Exception information byte 0 is always output:

  • If this is the only Exception information byte output then the C bit is 0, otherwise the C bit is 1.

  • If the exception number is 15 or less (b1111 or less) then the value in Exception[3:0] is used to identify the exception. In this case, Exception information byte 1 is not output, and Exception[8:4] = b00000.

If Exception information byte 1 is output:

  • If Exception information byte 2 is not output then the C bit is 0, otherwise the C bit is 1.

  • The value of Exception[8:0] is used to identify the exception.

Exception information byte 2 is only output if the instruction being traced was paused for continuation or if a previously paused instruction is being resumed. In that case, the value of Resume[3:0], together with the value of the Can bit from Exception Information byte 0, gives information about resuming execution. See Table 7.12.

When an extended exception branch packet with two Exception information bytes is output, the last byte can be either Exception information byte 1 or byte 2. A debugger can tell which byte it is by checking bit [6]:

  • for Exception information byte 1, bit [6] = 0

  • for Exception information byte 2, bit [6] = 1.

Encoding of Exception[8:0], for ARMv7-M processor architectures

The ARMv7-M processor architecture includes a number of features that affect the tracing of exceptions, in particular:

  • The architecture supports up to 512 exceptions. These comprise 15 standard exceptions plus up to 496 interrupts.

  • Some processor instructions can be paused for continuation when an interrupt is received. Processing of a paused instruction is resumed on return from the exception.

Table 7.11. Encoding of Exception[8:0] for ARMv7-M processors

Exception[8:0] [a]MeaningException[8:0] [a]Meaning
b0 0000 0000 (0x000)No exceptionb0 0001 0010 (0x012)Reserved
b0 0000 0001 (0x001)IRQ1b0 0001 0011 (0x013)HardFault
b0 0000 0010 (0x002)IRQ2b0 0001 0100 (0x014)Reserved
b0 0000 0011 (0x003)IRQ3b0 0001 0101 (0x015)BusFault
b0 0000 0100 (0x004)IRQ4b0 0001 0110 (0x016)Reserved
b0 0000 0101 (0x005)IRQ5b0 0001 0111 (0x017)Reserved
b0 0000 0110 (0x006)IRQ6b0 0001 1000 (0x018)IRQ8
b0 0000 0111 (0x007)IRQ7b0 0001 1001 (0x019)IRQ9
b0 0000 1000 (0x008)IRQ0b0 0001 1010 (0x01A)IRQ10
b0 0000 1001 (0x009)UsageFaultb0 0001 1011 (0x01B)IRQ11
b0 0000 1010 (0x00A)NMIb0 0001 1100 (0x01C)IRQ12
b0 0000 1011 (0x00B)SVCb0 0001 1101 (0x01D)IRQ13
b0 0000 1100 (0x00C)Debug Monitorb0 0001 1110 (0x01E)IRQ14
b0 0000 1101 (0x00D)MemManageb0 0001 1111 (0x01F)IRQ15
b0 0000 1110 (0x00E)PendSVb0 0010 0000 (0x020)IRQ16
b0 0000 1111 (0x00F)SysTick......
b0 0001 0000 (0x010)Reservedb1 1111 1110 (0x1FE)IRQ494
b0 0001 0001 (0x011)Processor resetb1 1111 1111 (0x1FF)IRQ495

[a] To make it easier to relate this table to the diagram of the packet in Figure 7.27, the binary values in this column are shown with a space between the Exception[8:4] and Exception[3:0] sub-fields.


Encoding of Exception[3:0], for processor architectures other than ARMv7-M

When tracing processor that comply with architectures other than the ARMv7-M, branch packets only include a maximum of one Exception information byte, and the exception is described by the Exception[3:0] field. The encoding of this field is given in Table 7.12.

Note

See Encoding of Exception[8:0], for ARMv7-M processor architectures for details of exception tracing for ARMv7-M processors.

Table 7.12. Encoding of Exception[3:0] for non-ARMv7-M processors

Exception[3:0]Exception
b0000No exception occurred
b0001Halting-debug exception
b0010Secure Monitor Call (SMC)
b0011Entry to Hyp mode[a]
b0100Asynchronous data abort
b0101Jazelle exception or ThumbEE check. See the address for the type.
b0110Reserved
b0111Reserved
b1000Processor reset exception
b1001Undefined Instruction exception
b1010Supervisor Call (SVC)
b1011Prefetch abort or software breakpoint exception
b1100Synchronous data abort or software watchpoint exception
b1101Generic exception [b]
b1110IRQ
b1111FIQ

[a] The Entry to Hype mode encoding, b0011, is introduced in ETMv3.5. In previous versions of the ETM architecture this encoding is Reserved.

[b] The Generic exception encoding, b1101, is introduced in ETMv3.3. In previous versions of the ETM architecture this encoding is Reserved.


When the processor enters Halting-debug state, the ETM might generate a branch packet indicating a Halting-debug exception. Whether this packet is generated is implementation specific. If the branch packet is generated, the following information in the branch packet is not valid and can be ignored:

  • Address

  • Instruction set, including the AltSA bit

  • Security state, using the NS bit

  • Hypervisor mode, using the Hyp bit.

Note

Excp[8:4] are always b00000 for processor architectures other than ARMv7-M.

Possible combinations of Excp[8:0], Can and Resume[3:0]

The rules for generating the Exception information section of an extended exception branch packet, and the additional architectural requirements given in Table 7.9, mean that only certain combinations of the Exception information bytes are possible. This section describes each possibility, and the circumstances in which it is output.

Figure 7.26. Only Exception information byte 0 is output

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


There are two situations where only Exception information byte 0 is output:

  • If there is no exception and no resumption of a paused for continuation instruction. In this case Exception[3:0] is zero and the Can bit is zero.

  • If an exception with exception number of 15 or less occurs, without pausing an instruction. This can occur with or without cancellation of the previous instruction:

    • Exception[3:0] holds the exception number, see Table 7.12

    • Can is set to 1 if the previous instruction was canceled.

Figure 7.27. Only Exception information bytes 0 and 1 are output

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


There is only one situation where only Exception information bytes 0 and 1 are output:

  • If an exception with exception number greater than 15 occurs without the pausing of an instruction. This can occur with or without cancellation of the previous instruction:

    • Exception[8:0] holds the exception number, see Table 7.11

    • Can is set to 1 if the previous instruction was canceled.

Figure 7.28. Only Exception information bytes 0 and 2 are output

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


There are two situations where only Exception information bytes 0 and 2 are output:

  • If an exception with exception number of 15 or less occurs, and an instruction is paused:

    • Exception[3:0] is nonzero, and holds the exception number, see Table 7.11

    • Can is set to 1.

  • If a paused for continuation instruction is resumed:

    • Exception[3:0] is zero, because there is no exception

    • Can is set to 0.

    Note

    No exception occurs in this situation. However, it is included here because it is traced in the same way as exceptions.

Figure 7.29. All Exception information bytes are output

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


There is only one situation where all three Exception information bytes are output:

  • If an exception with exception number greater than 15 occurs, and an instruction is paused:

    • Exception[8:0] is nonzero, and holds the exception number, see Table 7.11

    • Can is set to 1.

Extended Exception handling in Instruction-only trace

When performing instruction-only tracing, and an instruction is paused for continuation, no trace information is required to indicate where the instruction is resumed. With instruction-only trace:

  • if the previous instruction completed:

    • Can = 0

    • Resume[3:0] = b0000

  • if the previous instruction is paused for continuation, or restarted, it is treated as if the instruction is canceled:

    • Can = 1

    • Resume[3:0] = b0000.

This means that, with instruction-only trace, Exception information byte 2 is never output.

The AltISA bit, ETMv3.3 and later

The fifth address byte of the packet for an exception branch address indicates the Instruction Set, see Table 7.6. From ETMv3.3, this information is qualified by the value of the AltISA bit, bit [6], of the continuation byte. Table 7.13 shows the meaning of this bit.

Table 7.13. Meaning of the AltISA bit in the Continuation byte

State and alignment [a]AltISA bitMeaning
ARM, word0Processor is in ARM state after the branch
1AltISA=1 is Reserved when processor is in ARM state
Thumb, halfword0Processor is in Thumb state after the branch
1Processor is in ThumbEE state after the branch
Jazelle, byte0Processor is in Jazelle state after the branch
1AltISA=1 is Reserved when processor is in Jazelle state

[a] The instruction set state and alignment are determined by the most significant bits of the fifth byte of the Branch address packet, see Table 7.6.


Note

From ETMv3.4, if the alternative address compression scheme is implemented, the fifth address byte of a branch packet might not be output. In this case the branch packet does not give an explicit indication of the current state of the processor. However, all five address bytes are always included in the branch packet for a change of processor state. For more information, see Branch address packets for change of processor state.

Branch address packets for change of security state

On processors that support the Security Extensions, the ETM always traces a change of security state by issuing a branch packet with at least one Exception information byte:

  • If the original address encoding scheme is implemented, a change of security state is traced with all five Address Bytes and at least one Exception information byte.

  • From ETMv3.4, if the alternative address encoding scheme is implemented a change of security state is traced with a packet that has between two and five Address Bytes, followed by at least one Exception information byte.

Branch address packets for change of processor state

When an indirect branch occurs that changes the processor state, the ETM always traces a branch packet with all five Address Bytes. Some changes in processor state also require one or more Exception Information Bytes.

Table 7.14. State change branch packets

State changeAddress BytesException Information BytesAltISA bit
ARM to Jazelle50-30
ARM to Thumb50-30
ARM to ThumbEE51-31
Jazelle to ARM50-30
Thumb to ARM50-30
Thumb to ThumbEE51-31
ThumbEE to ARM51-30
ThumbEE to Thumb51-30

Changes of state that are not indicated explicitly

Not all state changes require a branch packet to be output in the trace, because a direct branch instruction can cause a state change. When such a state change occurs, subsequent branch packets are output with all the bits that have changed since the last broadcast address output in either an I-Sync packet or a branch packet. However, there are cases where a state change is not indicated in the trace.

Table 8 shows a sequence of instructions including a direct branch causing a change from ARM to Thumb state:

Table 7.15. Direct branch with change from ARM to Thumb state

StepInstructionState (change)Trace generated
1-ARM stateTrace enabled, I-Sync packet generated indicating ARM state
2BLX #immed(to Thumb state)No branch packet generated because this is a direct branch
3MOVS PC(to ARM state)Branch packet generated

In this example, Thumb state is not indicated explicitly in the trace stream, because the state change is caused by a direct branch instruction. The branch packet generated at step 3 does not require all five Address Bytes because the most recent broadcast address, in the I-Sync packet generated at step 1, indicates ARM state.

Table 7-16 shows a sequence of instructions that include changes between Thumb and ThumbEE states

Table 7.16. Direct branch with changes between Thumb and ThumbEE states

StepInstructionState (change)Trace generated
1-ARM stateTrace enabled, I-Sync packet generated indicating ARM state
2MOVS(to ThumbEE state)Branch packet with 5 Address Bytes and Exception Information Byte 0, indicating ThumbEE state.[a]
3LEAVEX(to Thumb state)No branch packet generated because this is a direct branch
4MOVS(to ThumbEE state)Branch packet generated but does not require any Exception Information Bytes.

[a] Address Byte 5 indicates Thumb state and the AltISA bit in Exception Information Byte 0 is set to 1.


In this case, the entry to Thumb state at step 3 trace stream is not indicated explicitly in the trace stream, because the state change is caused by a direct branch. The branch packet generated at step 4 does not require any Exception Information Bytes, because the state entered is the same as that indicated in the most recent broadcast address, that was in the branch packet generated at step 2.

ETM Architecture revision differences

The NS bit is only set in ETMv3.2 and later.

The AltISA bit is only set in ETMv3.3 and later.

Exception information bytes 1 and 2 are only implemented in ETMv3.4 and later.

The Alternative branch encoding scheme is only available in ETMv3.4 and later.

The Hyp bit is only set in ETMv3.5.

The Resume field is only used on ARMv7-M processors.

Bits [8:4] of the Excp field in Exception Information byte 1 are non-zero only on ARMv7-M processors.

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