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, RX700 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]
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. | [E1] [E20]
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 4. | When trace start events and end events have been set, stopping and restarting tracing during program execution is not possible. |
Caution 5. | [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. |