Sign In
Forgot Password?
Sign In | | Create Account

Non-intrusive debug

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.

Debugging, ashling, Trace, non-intrusive debug

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: Visit The Colin Walls Blog

More Posts by Colin Walls


No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)


Online Chat