Thought Leadership

Non-intrusive debug

By Colin Walls

I recently posted about using printf() for debugging – or, rather, I suggested a few good alternatives, which make more sense to embedded developers. Most debugging/tracing technologies involve adding some code to the target system, which might make some developers uncomfortable. Surely the code being debugged is no longer the same as you plan to ship?

Broadly speaking, this is really a manifestation of what physicists call the Observer Effect. This effect refers to changes in a system that are caused by attempts to make measurements. This effect can be mitigated in various ways, but there is the possibility of eliminating intrusiveness all together …

Even using LTTng, as I discussed before, does have a very small impact on the performance of the system that is being debugged. For most applications, the impact is negligible and may be ignored. However, there are occasions when the real time behavior of a system is absolutely critical. It may not be the case for all aspects of a system, but if just part of it exhibits such time criticality, it is a safe bet that you will need to debug that area.

There are two ways to approach this problem. First is to consider simulation. This is a low cost way to run a system in a potentially cycles-accurate way, even if it is not at full speed. If that is not viable – because you really need to run at full speed to interact with other systems – some appropriate instrumentation is required.

Historically, very high speed probes, that enable a system to be monitored at full speed, have suffered from three drawbacks:

  • Cost – they tended to be very expensive
  • Capacity – trace buffer size was never quite enough
  • Usability – the user interface was typically unfamiliar to the developer

The good news is that all three of these issues have been addressed to the point that this approach is viable for many development teams. Mentor Embedded announced the integration of Ashling’s excellent Vitra-XD with the Sourcery CodeBench environment. This gives the developer the opportunity to seamlessly move from debugging/analyzing code on a real target or under simulation to operating with a state of the art trace probe.

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at