This chapter explains Renesas RH850 specific configuration for Trace, Profiler and Coverage analysis. For general analyzer information refer to the general Analyzer chapter.
The RH850 family supports three trace interface modes.
For program trace, trace port sends a message only for every executed non-sequential instruction, effectively on changes of a program flow. Each message contains the instruction type information and a destination program counter. Based on this information, the debugger reconstructs complete program flow by inserting sequential instructions between the recorded non-sequential instructions. This can work as long as the debugger has a complete code image of the application (download file) in order to know which sequential instructions are located between the non-sequential. For the same reason, a self-modifying code cannot be traced.
Transmitted OCT messages are appended with time-stamp information. That is a time of message, not of execution. All sequential instructions being reconstructed by the debugger, relying on the code image and inserted between the recorded addresses, do not contain exact time information. Any interpolation with the recorded addresses containing valid time stamp can be misleading.
Data trace can record all data access cycles issued by the CPU. However, access to CPU core registers (R0-R31, FEPC, CTBP, etc) cannot be traced, unless the code is instrumented with the SFT processor opcodes.
Trace port bandwidth becomes quickly restrictive with the data trace enabled since data trace usually generates 2 messages for a single traced data access. When the number of trace messages exceeds the trace port bandwidth, an overflow message is sent out to inform the user that messages were lost. From that point on and until the next synchronization message, there will be a gap in the trace display. It’s up to the user then to either limit the number of traced data accesses to prevent trace overflow, or to turn on the non-real-time trace mode, which stalls the CPU in order for the trace port to transmit all messages from the internal trace pipeline without loss. The non-real-time trace mode is turned on by checking the Stall CPU to prevent overflows option in the Trigger configuration / SoC dialog. This means that the application execution time may differ, of course.
Before using trace for the first time please refer to the Analyzer chapter to learn more about trace technologies and possibilities. A selection between trace Analyzer Operation modes is done in the CPU Options dialog. Refer to Analyzer Configuration for more information.
Cycle Duration parameter is used for time-stamp calculation in On-Chip and SFT modes, and depends on the MCU core clock frequency. The period roughly matches the core clock. The above example for an 80MHz PLL core clock has been fine-tuned from 12.5 to 13.5ns with an oscilloscope measuring application that was toggling a port pin.
This is the most straightforward and simple way to use trace. Use the Default Trace Configuration provided under the Analyzer Configuration toolbar.
After starting the trace, program execution trace messages are stored to the On-Chip trace buffer, and when it’s full, it is read and decoded to get a reconstructed program flow display.
After starting the trace, program execution trace messages are sent directly through the Nexus port to the emulator’s trace buffer. The trace recording is uploaded to the PC while the sampling continues. The recording is then decoded to get a reconstructed program flow display.
Trace based on the RH850 OCTB or Nexus can be used in three different ways, Single Shot, Trigger position, Continuous mode.
Where the trace buffer starts recording trace messages and records until the trace buffer gets filled up.
Trace functions this way when the Trigger Immediately option is checked. This setting also overrides any Instruction or Data event configured for Trigger / Watchpoint detection.
Where trace buffer records trace messages before and after the trigger event until the trace buffer gets filled up.
Trigger position setting adjusts the amount of trace buffer before the trigger event and indirectly the remaining part of the trace buffer acts as a post trigger buffer. ‘Begin’ sets 1/16 of the complete buffer before the trigger event (15/16 after the trigger), ‘Center’ sets ½ (1/2 after the trigger), and End sets 15/16 of the buffer before the trigger (1/16 after the trigger). In this mode, trace stops recording after the trace buffer fills up after the trigger event hits. Trace functions this way when configuring one of the available Instruction and Data events for trigger operation (Trigger / Watchpoint option checked).
Where trace buffer records trace messages until manually stopping the trace or until the application is stopped due to a breakpoint hit. Trace functions this way when no trigger is configured (no trigger event configured and Trigger Immediately option is unchecked).
Stall CPU to prevent overflows
CPU will be stalled if traced data overwhelm device internal trace logic capabilities.
Below example configurations cover different use cases:
Record complete program execution until the the buffer is filled up.
Record complete program execution + one data variable until application is stopped by the execution breakpoint hit or trace is stopped manually.
Record one complete function (Address_TestScope) until buffer is filled up.
Record complete program execution + one data variable (iCounter)
Record program execution between function 1 call and function two call + one data variable accesses
Refer to the Profiler Analysis chapter for Profiler theory, background and result interpretation.
Refer to the Analyzer Configuration chapter for details on Analyzer and Profiler configuration.
Refer to the Coverage Analysis chapter for Coverage theory, background and result interpretation.
Refer to the Analyzer Configuration chapter for details on Analyzer and Coverage configuration.