Timing Analysis

When it comes to find­ing and fix­ing bugs or unde­sir­able behav­ior in embed­ded appli­ca­tion code, most devel­op­ers will prob­a­bly think first and fore­most of inter­ac­tive debug­ging. In this process, the devel­op­er uses break­points, step­ping, and mem­o­ry watch­es to get an idea of how the appli­ca­tion is run­ning. While this type of debug­ging is part of every soft­ware devel­op­er’s dai­ly rou­tine, it has some inher­ent lim­i­ta­tions, espe­cial­ly when deal­ing with embed­ded sys­tems. Inter­ac­tive debug­ging does not give a clear indi­ca­tion of the real-time behav­ior of an appli­ca­tion.

Hardware tracing – a neglected debugging technique?

There are proven stan­dard tech­niques for debug­ging embed­ded soft­ware, such as inter­ac­tive debug­ging and printf debug­ging. A tech­nique that has been neglect­ed so far is hard­ware trac­ing – even though it com­bines the best of both worlds by pro­vid­ing insights to the soft­ware’s flow with­out affect­ing run­time behav­ior.

The three classes of Timing Analysis

From a pure­ly sta­tis­ti­cal analy­sis based on sam­pling cer­tain objects with­in the soft­ware to on-chip or off-chip mea­sure­ments by, for exam­ple, tog­gling a pin and mea­sur­ing the tim­ing with an oscil­lo­scope up to Hard­ware Trace, pro­vid­ing the max­i­mum of infor­ma­tion.

Play Now

Hardware Trace — The foundation of Timing Analysis

Hard­ware Trace has the unique capa­bil­i­ty that it pro­vides full insights into the sys­tem’s behav­ior via a sequence of events. From this infor­ma­tion, you can derive a com­plete set of tim­ing met­rics, ana­lyze CPU load over time, ana­lyze event-chains and func­tion call sequences.

Play Now

The winIDEA Profiler …

The real pow­er of an Embed­ded Soft­ware develop­ment and test tool like winIDEA is to be found in its Analyzer/Profiler, a pro­gram and data trace visu­al­iza­tion tool. By cap­tur­ing the com­plete exe­cu­tion of an appli­ca­tion via a hard­ware trace inter­face, engi­neers can use the Ana­lyz­er to mea­sure the time tak­en to exe­cute a func­tion, an ISR, or an RTOS task.

Play Now

Profiling of different Object Types

Which objects are the most impor­tant when per­form­ing Tim­ing Analy­sis?

Play Now

Profiler Statistics — Calculate Net, Gross or Call Time

Mea­sure func­tion tim­ing para­me­ters, e.g. core exe­cu­tion time or time between entry and exit etc. with TASKING Pro­fil­er Sta­tis­tics.

Play Now

Profiling with various operating modes

Flat, Range, Entry/Exit func­tion pro­fil­ing modes dif­fer­en­ti­ate between one anoth­er by the trace method, pos­si­bil­i­ty of func­tion nest­ing, and a pre­req­ui­site to pro­file the con­text switch­es of an OS.

Play Now

Call Stack Analysis and the use of Profiler Inspectors

When stop­ping at a break­point, we obvi­ous­ly know which func­tion we stopped in. It is often use­ful to know the sequence of events that has led us to this point. For exam­ple, the same func­tion can be called from var­i­ous points in the appli­ca­tion, and if we know which func­tion calls pre­ced­ed our cur­rent stop­ping point and when. It gives us more insight into the cur­rent state of the sys­tem that we’re ana­lyz­ing.

Play Now

CPU Load / CPU Utilization Analysis

CPU Load and CPU Uti­liza­tion are used syn­ony­mous­ly in the Embed­ded Tim­ing Analy­sis world. This mea­sure­ment is impor­tant to under­stand the real-time behav­ior of an appli­ca­tion.​ There are dif­fer­ent approach­es to mea­sure CPU uti­liza­tion – polling is the eas­i­est to set up and hard­ware trac­ing gives the most insights. Both approach­es can be achieved with­out any over­head (no instru­men­ta­tion).

Play Now

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

The big dif­fer­ence between sam­pling-based Pro­fil­ing com­pared to hard­ware trace-based Pro­fil­ing is that the Analy­sis is not done based on data cap­tured from any sort of trace inter­face. The data is obtained by sam­pling spe­cif­ic mem­o­ry loca­tions or the CPU Pro­gram Counter, mean­ing the Debug­ger reads out these objects via the debug inter­face.

Play Now

We’d love to hear from you

Have ques­tions about our prod­ucts, fea­tures, tri­als, or pric­ing? Need a demo?
Our teams will help you.

Get in touch

TASKING Timing Solutions

Synchronous Debug & Trace on two Infineon AURIX devices

How to set­up the TASKING winIDEA and debug­ger to syn­chro­nous­ly debug and trace two Infi­neon AURIX devices

Find out more

Vector Microsar Profiling

How to use the TASKING winIDEA Ana­lyz­er for the tim­ing analy­sis of the Vec­tor MICROSAR oper­at­ing sys­tem

Find out more

EB tresos Safety OS 2.x Thread Profiling

Two approach­es for OS sched­ul­ing analy­sis on EB tre­sos Safe­ty OS.

Find out more

ETAS RTA-HVR Hypervisor & Multi RTA-OS Profiling

How to use winIDEA for Mul­ti-OS tim­ing analy­sis (pro­fil­ing) using the ETAS Light­weight Hyper­vi­sor, RTA-HVR.

Find out more

Elektrobit EB tresos AutoCore Profiling

How to use winIDEA for Mul­ti-OS tim­ing analy­sis (pro­fil­ing) using the ETAS Light­weight Hyper­vi­sor, RTA-HVR.

Find out more

Elektrobit EB tresos Runnable Profiling

How to use the TASKING winIDEA Ana­lyz­er for the tim­ing analy­sis of AUTOSAR Runnables of the two Elek­tro­bit AUTOSAR solu­tions “EB tre­sos Auto­Core” and “EB tre­sos Safe­ty”.

Find out more

Software Modeling/Simulation Tool Co-operations

Prov­ing that an auto­mo­tive appli­ca­tion can ful­fill the spec­i­fied task on time, every time, is an enor­mous chal­lenge. Togeth­er with our part­ners, TASKING has com­mit­ted to sev­er­al trace for­mats (e.g., the Best Trace For­mat (BTF), MDF4, and oth­ers), enabling real time appli­ca­tion inter­ac­tions to be import­ed to 3rd par­ty tim­ing analy­sis tools.

Scroll to Top