Most of the Software Developers spend 50% of time debugging the code so for efficiency purpose proper Debugging techniques must be employed. Cross Debugging an embedded application can be a complex tasks for many reasons: Real-time Execution, Lack of visibility to the target resources, dependent on the peripherals etc. Due to the above reasons its critical for the developers to use proper debugging tools that can resolve the problem quickly and more efficiently.

In the Real Time Embedded Systems, specifically in the multitasking OS based Implementations on of the challenges is the defect fixing, to resolve the defects the developer must be aware of the flow of the program during the defect or during the faulty condition.

Debugging technique like logging the output during the development build during the software maybe using the instrumentation mechanism (printing the data using the UART Protocol) decreases the overall performance of the system. Another technique is the use of the break-point based debugging features of the processor which in turn slow due to the high number of interruptions. Both techniques are intrusive because they modify the software temporarily for the analysis. This is especially troublesome in the concurrent programs running on multi-core processors or the real time applications as errors due to race conditions or inappropriate timing may be hidden.

For the Non-Intrusive Observation of the tracing, most of the modern Microprocessors features and Embedded Trace Unit which delivers the runtime information to a debug port of the processor in a highly compressed format. A specialized hardware is used to store this debugging data from the processor and store for the analysis.

Pure software tracing and profiling tools consume the already constrained resources on the production systems so as a result hardware tracing has emerged as a technique or a tool of choice of tracing as it provides the accurate and detailed view of the system with almost zero overhead. Hardware manufacturers such as Intel, Infineon, and ARM provide a program tracing (recording the sequence of executed instructions). These hardware debugging circuits provide dedicated resources (comparators, adders, MUX etc.) that can be used to trigger the events and store the data with almost zero overhead.

Hardware Trace gives the complete history of instructions executed by the processor. This information can be collected without modifying the running code so zero overhead on the application. Trace analysis tools can then convert this information into meaningful and powerful performance analysis data that will lead to analysis of the overall system and optimize the system for maximum performance.

One of the main disadvantage of this technology is traces can be recorded for atmost few seconds because very high performance memory with very fast write access is required to store the delivered information.

As per the IEEE Standards Hardware Tracing and Debugging features are classified into 4 classes, class 1 must provide with the following features setting up the breakpoints, analyzing registers, stepping instructions and they are transferred through the JTAG. Class 2 supports the capturing and transporting of the program control flow externally to the host devices along with the class 1 features. Class 3 adds the support for the data flow tracing and class 4 allows for the emulated memory and I/O Access though the external ports. So for tracing purpose the SOC must have support for the class higher than 1.

Hardware Tracing Modules for the recent processors above class 1 can either use the On chip buffer for tracing and recording the trace data from individual CPU on the SOC and send it for internal processing or storage. Off chip trace buffers can also be used for storing the trace data using the JTAG Ports through the high performance hardware trace probes. These hardware trace probes can contain dedicated trace buffers as large as 4gb and can handle the high speed trace data.

Generally there are 3 kinds of Hardware Tracing:

1. Program Flow Trace (Instruction Trace):

Trace data which is collected usually consists of a log of each instruction that is executed by the processor. It simply consists of list of PCs executed by the processor (we can see all the functions executed in the application).We will get the full insights into the system. This information gives the complete view of exactly what the processor was doing as the system is running. Using this data we can debug either a single application or the entire system by showing the interactions between the various tasks and the interrupts.

This procedure shows the assembly instructions along with timestamp. One of the disadvantages of Program Flow Tracing huge amount trace data is generated as a result short amount of traces can only be saved in this mode of operation as a result it is great mode of operation for the debugging but not for the real time analysis. We cannot get the OS related information like task states using this mode of hardware tracing.

Use this method we can get the trace or the timing parameters of a runnables.

2. Data Trace

In this technique we record certain sections of memory usually the trace device on the chip have the comparators to trace certain variables that we are interested in and it Shows read and write access to the variables with timestamps. It Can be used for instrumentation by writing into a dedicated variable.

In conjunction with Instruction Tracing Many trace implementations also contain information about the data that is read from the written to memory and also the information about the context switches and interrupts occurring.. As the trace data has the ability to show the data values using this we can examine the values which lead the program to take the incorrect execution path which gives the insight into what caused the problem and how to fix it.

Using this method we can get calculate the trace objects for task/ISR state and the semaphores

3. System Traces(ARM-STM)/ Ownership Traces (Nexus) / Software Traces (Renases)

In this technique it shows the write access to the dedicated registers and it can be used for instrumentation by writing into these registers.

Oscilloscope allows viewing the waveforms within the system. Oscilloscope should have a sufficient bandwidth to view the signals with in the computer. There must be a correspondence between the frequency of the oscilloscope and the system clock frequency. A 30MHZ oscilloscope cannot be used to view the waveforms of the 100MHz system clock. The higher the frequency of the oscilloscope when compared with the system clock frequency the more precise the view will be and we can see the fine spikes of noise on the signal lines which may adversely affect the state of the machine.

T1.scope is a trace view feature of an T1-host software, it shows the real time behavior by displaying the task time-lines similar to the output of oscilloscope.T1.scope hooks on the OS related events and saves the start time, end time and the related details in a ring buffer.

This ring buffer data is transferred to the HOST software using the communication interface between the host software and the target software. Then the host software performs all the analysis and the calculation on the host machine and displays a trace diagram as seen in the oscilloscope.

T1 Scope traces are similar to that of the traces of the oscilloscope. In the digital oscilloscope we can see the various levels of the signal similarly in T1 Scope snapshot trace we can whether the task is in running state , ready state or terminated. We can check the timing between the signal raise levels in the oscilloscope, similarly in the T1.Scope snapshot trace we can check the timing parameters like CET,GET etc.

A particular variable can be checked in the oscilloscope by directing it towards the debug probes(Software modification) and visualizing it in the oscilloscope whereas in the T1 scope we can use the T1 mod or Data Access Inspector to check the value of particular variable.

T1.Scope is used to get the snapshot traces let’s see how it works and look it into issue how it can be used to get the continuous traces as in the case of Oscilloscope.

The main API of the T1 with regard to write events to the trace buffer is the T1_TraceEvent API, For efficiency reasons T1 provides three different variants whereas each has its own special scope with regards to interrupt status in the calling context.

In the Application Interface functions T1_AppHandler() wrapper function is responsible for the communication between the T1-Target SW and the T1- Host SW. T1_AppHandler consists of T1_TransmitFrame() and T1_AppReceiveFrame for data transmissions. In case of CAN two CAN ID’s are required for the data transmission and data receiving.

Whenever we want to download the trace buffer data from the target software the T1_AppHandler () wrapper function is invoked which in turn invokes the T1_TransmitFrame() which transmits the data using selected communication interface. During the transmission of the data the trace buffer is freezed the target software cannot update the values in the trace buffer till the data transmission isn’t finished as a result few trace data is lost.

In the case of snapshot trace we can get the trace from the target to the Host using the software triggers, or when a constraint is be broken by the application such as crossing over the timing value threshold specified for a specific parameter.

By calling with T1_TransmitFrame frequently(as per the user’s applications highest CET task) and using the high bandwidth protocol(Ethernet) for the communication between the host and target software we can convert the trace data in the buffer into a continuous stream tracing feature as in the case of the oscilloscope. The bandwidth of the CAN is much lower than the bandwidth offered by the Ethernet , so when communicating using the CAN these is high probability of loss of trace data which is not same in the case of the Ethernet.

Capturing program and data traces during program execution unobtrusively in real-time is crucial in debugging and testing of cyber-physical systems. However, tracing a complete program unobtrusively is often cost-prohibitive, requiring large on-chip trace buffers and wide trace ports. Whereas program execution traces can be efficiently compressed in hardware, compression of data address and data value traces is much more challenging due to limited redundancy. Menlopark along with its Partner GLIWA GmBH is supporting Automotive OEMs and Tier 1 & 2 Suppliers with various Timing analysis mechanisms.