Timing Analysis

When it comes to finding and fixing bugs or undesirable behavior in embedded application code, most developers will probably think first and foremost of interactive debugging. In this process, the developer uses breakpoints, stepping, and memory watches to get an idea of how the application is running. While this type of debugging is part of every software developer's daily routine, it has some inherent limitations, especially when dealing with embedded systems. Interactive debugging does not give a clear indication of the real-time behavior of an application.

Hardware tracing – a neglected debugging technique?

There are proven standard techniques for debugging embedded software, such as interactive debugging and printf debugging. A technique that has been neglected so far is hardware tracing – even though it combines the best of both worlds by providing insights to the software's flow without affecting runtime behavior.

Get the FREE article

I have read and accept the iSYSTEM privacy statement

<iframe name='formresponse1' style="display: none;" width='300' height='200'></iframe>

The three classes of Timing Analysis

From a purely statistical analysis based on sampling certain objects within the software to on-chip or off-chip measurements by, for example, toggling a pin and measuring the timing with an oscilloscope up to Hardware Trace, providing the maximum of information.

Hardware Trace - The foundation of Timing Analysis

Hardware Trace has the unique capability that it provides full insights into the system's behavior via a sequence of events. From this information, you can derive a complete set of timing metrics, analyze CPU load over time, analyze event-chains and function call sequences.

The winIDEA Profiler ...

The real power of an Embedded Software development and test tool like winIDEA is to be found in its Analyzer/Profiler, a program and data trace visualization tool. By capturing the complete execution of an application via a hardware trace interface, engineers can use the Analyzer to measure the time taken to execute a function, an ISR, or an RTOS task.

Profiling of different Object Types

Which objects are the most important when performing Timing Analysis?

Profiler Statistics - Calculate Net, Gross or Call Time

Measure function timing parameters, e.g. core execution time or time between entry and exit etc. with iSYSTEM Profiler Statistics.

Profiling with various operating modes

Flat, Range, Entry/Exit function profiling modes differentiate between one another by the trace method, possibility of function nesting, and a prerequisite to profile the context switches of an OS.

Call Stack Analysis and the use of Profiler Inspectors

When stopping at a breakpoint, we obviously know which function we stopped in. It is often useful to know the sequence of events that has led us to this point. For example, the same function can be called from various points in the application, and if we know which function calls preceded our current stopping point and when. It gives us more insight into the current state of the system that we're analyzing.

CPU Load / CPU Utilization Analysis

CPU Load and CPU Utilization are used synonymously in the Embedded Timing Analysis world. This measurement is important to understand the real-time behavior of an application.​ There are different approaches to measure CPU utilization – polling is the easiest to set up and hardware tracing gives the most insights. Both approaches can be achieved without any overhead (no instrumentation).

What if your target doesn’t support trace at all?

The big difference between sampling-based Profiling compared to hardware trace-based Profiling is that the Analysis is not done based on data captured from any sort of trace interface. The data is obtained by sampling specific memory locations or the CPU Program Counter, meaning the Debugger reads out these objects via the debug interface.

×

When you start the video, content is loaded from Youtube and thereby your IP address is transmitted to YouTube.
Learn more

iSYSTEM Timing Solutions

Synchronous Debug & Trace on two Infineon AURIX devices

How to setup the iSYSTEM winIDEA and debugger to synchronously debug and trace two Infineon AURIX devices

Find out more

Vector Microsar Profiling

How to use the iSYSTEM winIDEA Analyzer for the timing analysis of the Vector MICROSAR operating system

Find out more

EB tresos Safety OS 2.x Thread Profiling

Two approaches for OS scheduling analysis on EB tresos Safety OS.

Find out more

ETAS RTA-HVR Hypervisor & Multi RTA-OS Profiling

How to use winIDEA for Multi-OS timing analysis (profiling) using the ETAS Lightweight Hypervisor, RTA-HVR.

Find out more

Elektrobit EB tresos AutoCore Profiling

How to use the iSYSTEM winIDEA Analyzer for the timing analysis of the EB tresos AutoCore operating system.

Find out more

Elektrobit EB tresos Runnable Profiling

How to use the iSYSTEM winIDEA Analyzer for the timing analysis of AUTOSAR Runnables of the two Elektrobit AUTOSAR solutions “EB tresos AutoCore” and “EB tresos Safety”.

Find out more

Software Modeling/Simulation Tool Co-operations

Proving that an automotive application can fulfill the specified task on time, every time, is an enormous challenge. Together with our partners, iSYSTEM has committed to several trace formats (e.g., the Best Trace Format (BTF), MDF4, and others), enabling real time application interactions to be imported to 3rd party timing analysis tools.