5.9. FIFO overflow

Under certain circumstances it is possible that so much trace information is generated on-chip that the FIFO can overflow. When this occurs a two-stage process to empty the FIFO and restart the trace takes place:

  1. First the pipeline status is changed to WT (Wait) and emptying of the FIFO is enabled. This ensures that all trace information up to the overflow condition is collected. This information might be useful in determining the cause of the FIFO overflow. If overflow occurs part way through a load or store instruction the pipeline status for the instruction must be generated. This is to enable the decompression software to associate any trace packets with an instruction.

  2. When the FIFO has been drained, tracing must be re-enabled as soon as possible, if TraceEnable is still active.


A trace decompressor must be able to deal with the loss of some or all of the packets for an instruction. This lost information might include data, address, and Context ID packets.

The trace decompressor can successfully decode a FIFO overflow sequence, if it is aware that a BE (Branch Executed) marked as FIFO overflow is speculative and might be followed by another BE also marked as FIFO overflow. If this is the case, then the second BE marked as FIFO overflow can overwrite the Address Packet Offset of the speculative BE. This is not a problem, because the speculative BE has been found to be incorrect, and therefore can be discarded.

In ETMv1.1 and later, a status register is provided, see ETM Status Register, ETMSR, ETMv1.1 and later. Bit [0] of this register is a pending overflow flag, indicating that an overflow has occurred but no overflow occurred reason code been generated. This indication is required where tracing stops because of an ARM breakpoint. The pending overflow flag remains set until tracing is restarted and the overflow can be traced.

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