Collecting an Execution History

2.13 Collecting an Execution History

This section describes how to collect an execution history of the program.

Generally, a program's execution history is referred to as a "trace", the term of which is used in the pages below. If the program goes wild, it is very difficult to find the cause of the problem from the memory contents or stack information after the program has run out of control. However, analysis of the content of collected trace data makes it possible explore a process of malfunction until the program starts running wild, providing an effective means for discovering potential bugs in the program.

Caution 1.

[E20(JTAG) [RX600 Series]]
Part of the trace functions and real-time RAM monitor functions (RRM functions) can be used only on a mutually exclusive basis.

Caution 2.

[E1] [E20] [EZ Emulator]
When you use a Printf event (an action event) and it occurs, the execution history up to that point is cleared and the onward execution history is recorded.

Caution 3.

[EZ Emulator [RX100, RX200 Series]]
If the reset signal is input through the reset pin, all trace data that has been acquired before the reset is erased. Trace acquisition is resumed when the EZ Emulator restarts the execution of the program.

Caution 4.

[E1] [E20] [EZ Emulator]
If a reset (e.g. input of a reset signal through the reset pin, or reset of the CPU by the watchdog timer) is issued while a user program is running, the correct recording of trace information both before and after the reset will not be possible.

Caution 5.

When trace start events and end events have been set, stopping and restarting tracing during program execution is not possible.

Caution 6.

[OCD (JTAG)] [OCD (serial)]
The timestamps of trace information will not indicate the right times if the time between frames exceeds that corresponding to the trace counter (20 bits) or when trace output is lost.