Why Use Trace ?
In short, trace reduces development time and saves money.
QTrace provides visualisations of how embedded software is running that just isn’t possible using traditional debugging techniques. Here are a few examples of what’s possible with trace:
● Reveal which functions and conditional branches have been executed without stopping the CPU
● Identify which functions are being called most frequently and which are hogging the CPU
● See which interrupts are occurring and how often
● Review 10’s of milliseconds of execution prior to a CPU exception
● Determine the percentage of functions that have been executed, and the paths within them
According to the EETimes 2017 Embedded Markets Study, the no.1 item that developers would like to improve is debugging tools. This is no surprise considering that debugging an embedded application takes at least 20% of an overall software development budget. If the process of actually making code work on the target is included then the figure increases significantly. Clearly, any improvements to debugging tools will result in savings of both time and money.
Time consuming bugs
Most projects have a number of bugs that consume hours or even days of investigation, especially those which cause CPU exceptions. Having as much insight as possible into what the code is doing is key to solving these problems and that’s exactly what trace provides. In the case of CPU exceptions, QTrace will highlight exactly where an exception occurred and then give 10’s of milliseconds of execution history prior to the fault to help pin point the problem.
Hard-to-find bugs are usually intermittent and here traditional debugging can be inadequate as it is unlikely that breakpoints are set in every location of interest. With code coverage, the QTrace source code view reveals exactly where the processor has been, and how many times. It’s like having 1000’s of continuously active breakpoints to provide a ‘smoking gun’ for many bugs.
One of the key strengths of Trace is being able to gather information about program execution without affecting it in any way. Being able to see how an application is running without stopping the processor is particularly useful for communication stacks. These are used in some form in most applications and are becoming even more prevalent with the growth of the Internet of Things. Traditional break-and-step debugging will usually cause timeouts at the other end of a connection and can make debugging tricky and time consuming.
Other examples of applications that can’t be stopped without causing problems include motion control, high speed data acquisition, PID controllers, etc. With QTrace, a graphical call stack can be generated from any executed source line without stopping the processor. This can be invaluable to understand how a particular function is being called but without interferring with the program flow.
Being able to see in real-time which areas of code are being executed, and how often, is incredibly powerful. It can throw up surprises by revealing non-executed code which was expected to have been run. Similarly, being able to see instantly which interrupts are occurring and how often is another very useful feature. To acheive this with traditional debugging requires instrumentation code to be added but that takes time to implement (and execute) and can introduce problems of it’s own.