| |||
| Home > ETMv3 Signal Protocol > Additional trace features for ARMv7‑M processors, from ETMv3.4 > Automatic stack push on exception entry and pop on exception exit | |||
The ARMv7-M architecture introduces an automatic stack push whenever an exception occurs. When considering data tracing, this is a major difference from all other ARM processor architectures, where data transfers are always initiated by an instruction, and data trace can always be associated with a traced instruction.
In the ARMv7-M architecture, when an exception occurs, eight registers are pushed onto the stack automatically. When execution of the exception handler is complete, the eight registers are popped from the stack and restored. There is a special case extension of this, referred to as tail-chaining, when two exceptions are executed back-to-back. In this case, there is no stack pop and subsequent push between the handling of the two events, and the handling of the two tail-chained events is:
Before entry to the first event handler the registers are pushed onto the stack.
Control passes to the first event handler.
When execution of the event handler is complete control passes directly to the second event handler, without any pop, restore and push of the registers.
When execution of the second event handler is complete the registers are popped from the stack and restored.
Being able to perform data tracing of the register push and pop operations is important, because this gives access to the contents of the registers. Also, you can use this trace to help to identify the cause of any corruption of the stack by software. Therefore, the ETM must trace the data transfers for the stack push that occurs before the exception handler is entered. These transfers do not have a parent instruction. Instead, an Exception entry packet is inserted into the trace stream, to indicate the start of the stack push. The data transfers for the stack push are associated with this packet, not with the previous instruction. These transfers are traced in the same way as a normal STM instruction.
Figure 7.38 shows the format of the Exception entry packet.
If cycle-accurate tracing is enabled, outputting an Exception entry packet has no effect on the current cycle count, and does not imply that any W, E, or N atoms have occurred.
During instruction-only trace the data transfers for the stack push are not traced, and Exception entry packets are not output.
Tracing might be enabled while a stack push is in progress, either because of exit from an overflow condition or from a normal trace-on occurrence. In this situation, tracing must be enabled immediately:
the I-Sync packet traces the address of the instruction that caused the exception
the Exception entry packet is traced immediately after the I-Sync packet
no P-header is traced for the instruction that caused the exception.
A higher-priority exception might occur during an exception-entry stack push. This results in one of the following two situations, that must be traced as described here:
The original stack push completes, the first exception is taken, and its vector table entry is loaded. At this point a second stack push is performed, to enter the second exception handler.
In this case, the trace sequence is:
Exception entry packet and data trace for the first stack push
Exception branch packet for the first exception handler
P-header for the first instruction of the first exception handler
Exception entry packet and data trace for the second stack push
Exception branch packet for the second exception handler
P-header for the first instruction of the second exception handler.
The original stack push completes, but the first exception is not taken. The vector table load is performed for the second exception. The first exception is taken only when the higher-priority exception handler has completed. At that point the original exception is traced as if it has just been noticed.
In this case the trace sequence is:
Exception entry packet and data trace for the stack push.
Exception branch packet for the second exception handler.
P-header for the first instruction of the second exception handler, followed immediately by the trace for all of the code of the second exception handler.
When the second exception handler has completed there is no stack pop and restore, because this is a tail-chained case.
Exception branch packet for the first exception handler
P-header for the first instruction of the first exception handler.
If another higher-priority exception occurs during the execution of the second exception handler then the branch to the first exception handler is not taken until execution of the handler for the new exception has completed.