| Copyright © 1999-2002, 2004-2009, 2011 ARM Limited. All rights reserved. | ARM IHI 0014Q |
| Non-Confidential | ID101211 |
 PDF version | |
| Home > ETMv3 Signal Protocol > Instruction tracing > Branch Packets |
| |||
| Home > ETMv3 Signal Protocol > Instruction tracing > 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.
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.
Some implementations indicate exception information in the Address Bytes. See Branch packet formats with the original address encoding scheme, however this use is deprecated.
There are 2 formats used for the Address Bytes:
Original branch encoding scheme, from ETMv3.0. See Branch packet formats with the original address encoding scheme
Alternative branch encoding scheme, available from ETMv3.4. See Branch packet formats with the alternative address encoding scheme
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 field | Interpretation |
|---|---|
| Address | The missing address bits are the same as the last time they were traced in a branch packet or I-Sync packet. |
| NS | The 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 |
| AltISA | The AltISA bit is the same as the last time it was traced in a branch packet or I-Sync packet. |
| Can | Can is b0 |
| Hyp | The 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 |
The original branch address encoding scheme:
Is always implemented in ETMv3.0 to ETMv3.3
Can be implemented in ETMv3.4 and later. ETMIDR bit [20] identifies when this scheme is implemented. See ID Register, ETMIDR, ETMv2.0 and later.
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.
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.
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.
Table 2 shows the encodings of Address Byte 5.
Table 7.6. Address Byte 5 encodings, original encoding scheme
| Address Byte 5 Value | Description |
|---|---|
| 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 field | Exception |
|---|---|
| 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 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:
Branch packets without Exception Information Bytes. See Branch packets without Exception Information Bytes, in the alternative encoding
Branch packets with Exception information Bytes. See Branch packets with Exception Information Bytes, in the alternative encoding
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:
Branch packets without Exception Information Bytes. See Branch packets without Exception Information Bytes, in the alternative encoding
Branch packets with Exception information Bytes. See Branch packets with Exception Information Bytes, in the alternative encoding
Table 7.8. Interpretation of bits [7:6] in Address bytes 1-4
| Address Byte | Bit [7] | Bit [6] | Interpretation |
|---|---|---|---|
| 1-4 | 1 | - | 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.
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.
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.
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.
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
Figure 7.20. Thumb branch with exception information bytes and no change in address bits [31:20], alternative encoding
Figure 7.21. Thumb branch with exception information bytes and no change in address bits [31:27], alternative encoding
Figure 7.22. Thumb branch with exception information bytes and when address bits [31:27] change, alternative encoding
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
Figure 7.24. Jazelle branch with exception information bytes and no change in address bits [31:26], alternative encoding
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.
The meanings of the fields are shown in Table 5.
Table 7.9. Meanings of fields in Exception Information Bytes
| Name | Function | Description |
|---|---|---|
| NS | Security level | If 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 Byte | Required 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.
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] | Meaning | Exception[8:0] [a] | Meaning |
|---|---|---|---|
b0 0000 0000 (0x000) | No exception | b0 0001 0010 (0x012) | Reserved |
b0 0000 0001 (0x001) | IRQ1 | b0 0001 0011 (0x013) | HardFault |
b0 0000 0010 (0x002) | IRQ2 | b0 0001 0100 (0x014) | Reserved |
b0 0000 0011 (0x003) | IRQ3 | b0 0001 0101 (0x015) | BusFault |
b0 0000 0100 (0x004) | IRQ4 | b0 0001 0110 (0x016) | Reserved |
b0 0000 0101 (0x005) | IRQ5 | b0 0001 0111 (0x017) | Reserved |
b0 0000 0110 (0x006) | IRQ6 | b0 0001 1000 (0x018) | IRQ8 |
b0 0000 0111 (0x007) | IRQ7 | b0 0001 1001 (0x019) | IRQ9 |
b0 0000 1000 (0x008) | IRQ0 | b0 0001 1010 (0x01A) | IRQ10 |
b0 0000 1001 (0x009) | UsageFault | b0 0001 1011 (0x01B) | IRQ11 |
b0 0000 1010 (0x00A) | NMI | b0 0001 1100 (0x01C) | IRQ12 |
b0 0000 1011 (0x00B) | SVC | b0 0001 1101 (0x01D) | IRQ13 |
b0 0000 1100 (0x00C) | Debug Monitor | b0 0001 1110 (0x01E) | IRQ14 |
b0 0000 1101 (0x00D) | MemManage | b0 0001 1111 (0x01F) | IRQ15 |
b0 0000 1110 (0x00E) | PendSV | b0 0010 0000 (0x020) | IRQ16 |
b0 0000 1111 (0x00F) | SysTick | ... | ... |
b0 0001 0000 (0x010) | Reserved | b1 1111 1110 (0x1FE) | IRQ494 |
b0 0001 0001 (0x011) | Processor reset | b1 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. | |||
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.
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 |
|---|---|
| b0000 | No exception occurred |
| b0001 | Halting-debug exception |
| b0010 | Secure Monitor Call (SMC) |
| b0011 | Entry to Hyp mode[a] |
| b0100 | Asynchronous data abort |
| b0101 | Jazelle exception or ThumbEE check. See the address for the type. |
| b0110 | Reserved |
| b0111 | Reserved |
| b1000 | Processor reset exception |
| b1001 | Undefined Instruction exception |
| b1010 | Supervisor Call (SVC) |
| b1011 | Prefetch abort or software breakpoint exception |
| b1100 | Synchronous data abort or software watchpoint exception |
| b1101 | Generic exception [b] |
| b1110 | IRQ |
| b1111 | FIQ |
[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.
Excp[8:4] are always b00000 for processor architectures other than ARMv7-M.
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.
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.
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.
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.
No exception occurs in this situation. However, it is included here because it is traced in the same way as exceptions.
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.
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 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 bit | Meaning |
|---|---|---|
| ARM, word | 0 | Processor is in ARM state after the branch |
| 1 | AltISA=1 is Reserved when processor is in ARM state | |
| Thumb, halfword | 0 | Processor is in Thumb state after the branch |
| 1 | Processor is in ThumbEE state after the branch | |
| Jazelle, byte | 0 | Processor is in Jazelle state after the branch |
| 1 | AltISA=1 is Reserved when processor is in Jazelle state | |
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.
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.
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 change | Address Bytes | Exception Information Bytes | AltISA bit |
|---|---|---|---|
| ARM to Jazelle | 5 | 0-3 | 0 |
| ARM to Thumb | 5 | 0-3 | 0 |
| ARM to ThumbEE | 5 | 1-3 | 1 |
| Jazelle to ARM | 5 | 0-3 | 0 |
| Thumb to ARM | 5 | 0-3 | 0 |
| Thumb to ThumbEE | 5 | 1-3 | 1 |
| ThumbEE to ARM | 5 | 1-3 | 0 |
| ThumbEE to Thumb | 5 | 1-3 | 0 |
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
| Step | Instruction | State (change) | Trace generated |
|---|---|---|---|
| 1 | - | ARM state | Trace enabled, I-Sync packet generated indicating ARM state |
| 2 | BLX #immed | (to Thumb state) | No branch packet generated because this is a direct branch |
| 3 | MOVS 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
| Step | Instruction | State (change) | Trace generated |
|---|---|---|---|
| 1 | - | ARM state | Trace enabled, I-Sync packet generated indicating ARM state |
| 2 | MOVS | (to ThumbEE state) | Branch packet with 5 Address Bytes and Exception Information Byte 0, indicating ThumbEE state.[a] |
| 3 | LEAVEX | (to Thumb state) | No branch packet generated because this is a direct branch |
| 4 | MOVS | (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.
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-Confidential | ID101211 |
| PDF version | |
| Home > ETMv3 Signal Protocol > Instruction tracing > Branch Packets |