Last week there was a new release of Sourcery CodeBench, which I saw somewhere posted as “A Christmas present from Mentor Embedded”. As this release covers a wide range of functionality in both Sourcery CodeBench and Sourcery Analyzer, I thought it would be interesting to focus on a specific new feature and dig into the technology a little.
I have been investigating Diagnostic Log and Trace [DLT] …
A while ago I sent a proposal to a conference for a paper titled “Debug is Dead”. I thought that this was a suitably contentious title, which would pique their curiosity. It was rejected. When I inquired, I learned that the organizers felt that it sounded rather negative and, anyway, debugging was very much alive as programmers had not yet learned to write bug-free code. If they had read my abstract carefully, they would have seen that I was taking a very positive view and simply explaining that traditional “stop and stare” debugging was not quite good enough for high-performance, maybe multicore, embedded systems. An alternative strategy was needed: gather lots of data and use sophisticated viewing/analysis tools to get a clear view of how the system is behaving [or, more likely, misbehaving!].
Mentor Embedded’s Sourcery Analyzer [MESA] is an excellent tool for this purpose. It lays the emphasis on using a sophisticated data processing engine to crunch very large data sets and, thus, provide means to analyze, rather than just view, system activity over time. This technology was derived from chip design tools, where enormous quantities of data needed to be marshaled. There is a nice video, which explains what MESA is all about.
The newly-announced release includes support in MESA for GENEVI DLT format. Unless you work on automotive applications, you may not be familiar with GENEVI. It is a non-profit industry alliance supporting an open-source In-Vehicle Infotainment [IVI] development platform. This platform fosters a high level of compatibility between software components and development tools from a wide range of suppliers.
The approach of using logging and tracing instead of “conventional” debugging [or, of course, it might be in addition to it] is widely recognized as desirable and many vendors offer tools of one kind or another. Typically a daemon runs on the target and a viewer [or, better, an analyzer] runs on the host development computer. A protocol of some kind operates between the two components. DLT is an attempt to bring together the key features and benefits of a number of existing protocols to offer a single standard [in the automotive sector, at least].
Detailed documentation of the DLT protocol is, of course, available from GENIVI, so I will just give a brief overview here to give a flavor. The protocol is a message based byte stream. Each message has a mandatory header of 4, 8, 12 or 16 bytes [the more basic versions are intended for use where connection bandwidth is an issue], a 10-byte optional extended header and an optional payload of indefinite size. The relatively complex header arrangement is designed to maximize the flexibility of the protocol, as numerous aspects of communication are customizable. As I see it, the protocol is not designed to be “bullet proof”, but has some precautions for identifying lost messages [each message has a count, which is an unsigned 8-bit value maintained by the daemon] for example. Timestamping is optional and, if used, has a resolution of 0.1 milliseconds. The communication of data can be in Non-Verbose or Verbose modes. With the former, there is a fixed interpretation of data, depending on the Message ID; this is intended for use with a small target system, where memory and communication bandwidth may be limited. In Verbose mode, the message carries all the necessary information required by the DLT client to interpret the data.
A much more complete description of DLT protocol can be found on the GENIVI website.
If you want to know more about the GENIVI Alliance, a good place to start is this video featuring Steve Crumb, Executive Director, GENIVI Alliance.