SFT Software Trace
This chapter describes SFT Software Trace via LPD Debug port:
Because of the inherently small On-Chip trace buffer, the OCTB is of limited use for running a function or task profiler. The SFT tries to overcome this limitation. User and OS vendor must instrument their software at key points by inserting instrumentation instructions DBCP, DBTAG and DBPUSH. When the CPU executes these instructions, program counter value, immediate 10-bit data (e.g. task or function ID), the selected number and values of core general purpose registers (e.g. R1 to R5), will be output via software trace output pins or LPD low-pin debug interface.
Sample code snippet (for IAR compiler):
asm("DBTAG 0x1");
asm("DBPUSH R1-R2");
asm("DBCP");
asm("PREPARE {r25},0");
asm("mov %0, R25" : "+r" (myVariable) ); // writes content of variable to rx register
asm("DBPUSH R25-R25"); // outputs rx register
asm("DISPOSE 0,{R25}"); // restores rx register
When instrumenting the code, care must be taken to not generate too many SFT messages because of a limited LPD serial port bandwidth. Each instrumentation instruction generates a unique software trace message. Each message is first stored in the On-Chip internal software trace buffer, which consists of 48 bits (1line) x 8 lines, before it is output to the LPD interface. This buffer acts as a FIFO buffer and helps overcoming short term bottlenecks when the LPD interface bandwidth is lesser than amount of software trace messages to be broadcasted to the debug tool. Once there is no free space for the software trace message in the software trace buffer, a software trace message loss occurs (overflow).
When an overflow occurs, the overflow message is stored in the software trace buffer and an overflow is also reported in winIDEA Analyzer window. The storing software trace message is resumed when a line in the software trace buffer is freed after the stored overflow message. In case of overflows, try adjusting the LPD clock in the Hardware / CPU Options / SoC page to a maximum working frequency which yields maximum LPD bandwidth for your setup.
During the SFT trace the LPD cannot be used for debugging. To regain debug control over the CPU, forcibly stop trace or program execution by respective winIDEA menu or toolbar button commands. |
The RH850 devices can output SFT Software Trace from one core at a time. Therefore, a single SFT source should be defined in the trace trigger dialogs. |
The CPU internal 8-stage FIFO buffer may introduce an output delay and thus timestamp inaccuracy of 8 x times the transmission time of a SFT message.
Say the LPD4 output frequency is 12MHz, then a transmission of a (net) 48-bit DBPUSH message typically used for task profiling takes 4us, and therefore the maximum message output delay is 8 x 4us = 32us. This in turn translates to a timestamp accuracy of 4 to 32us, depending on FIFO load.
A 48-bit message is split into 6 data frames with start and stop bits added. So, in full 60 bits are transmitted so the worst-case accuracy is 40us.
For function profiling a shorter DBTAG message can be used. In this case the accuracy can be better, between 1 to 10us.
![]() 1. Select the LPD SofTrace by clicking Hardware menu / CPU Options / Analyzer page. |
![]() 2. Create new Trace configuration entry. 3. In the Recorder page select a suitable Recording Size Limit. Initially, it is recommended to use small values for setup verification. For example, select 256KB or 1MB. |
In the SofTrace tab it is possible to set filters for the SFT messages. Because the LPD port bandwidth is very limited it is necessary to reduce the SFT traffic on a heavily instrumented code.
![]() 1. Select Manual Trigger / Recorder Configuration. 2. Click Configure. 3. Configure settings (Filters) in the Trigger dialog.
To trace all instrumentation instructions set all masks to FFs. |
Mask bit '1' ignores the corresponding Value bit. To trace tags from e.g. 0x010 to 0x01F, set Value to 0x010 and Mask to 0x00F.
For a specific Value, enter a number and set Mask to zero.
Represents a 32-bit mask, each bit corresponding to one of the general purpose registers R0-R31 (see the table below).
Trigger Configuration dialog extends to two SFT Filter modules.
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
R |
31 |
30 |
29 |
28 |
27 |
26 |
25 |
24 |
23 |
22 |
21 |
20 |
19 |
18 |
17 |
16 |
15 |
14 |
13 |
12 |
11 |
10 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
The hex value 0x00000002 means that the general purpose register R1 is selected for trace.
A mask 0x80000000 would select just R31. More than one register can be selected, of course.
A mask 0x00010038 enables R16, R5, R4 and R3 for the trace.
![]() Sample trace with trace all SFT, CPU on 80MHz and LPD on 4MHz |
![]() Although the SFT messages can be displayed in the Trace window, they are intended for profiling functions and OS tasks.
For effective use of the SFT profiling winIDEA correlates the SFT messages with application symbol information and custom instrumentation files refer to the SFTAnalyzer document and documents mentioned in the Profiler chapter below. |