logo slogan

Driving fearlessly for the future

By Flora McDonald

June 2018

Profanity is an odd thing. My children come out with stuff that would make a docker blush and, yet, it is a rare occasion indeed when I resort to a curse. My parents almost never swore; I think in all my years my Mum has only ever sworn twice and although my Dad did swear a little more (and not the obscenities that even the BBC seem to think is OK) it always reserved for the car. I remember, as a youngster, going on a family outing and my Dad would always make sure he had his toolbox in the boot of the car because “the ruddy thing” would breakdown before we got to our destination and he would have to get out and fix it at the roadside. That’s when Mum would tell us all to block our ears.

I can also recall early winter mornings, on my way to school our street resounding to the coughing and wheezing of our neighbours trying to start their cars. Fast forward a few years and I got my own car: a lovely 1979 Alfa Romeo. Journeys in those days were always such an adventure: would I get there; would I get home again and how much of the car would make it home with me?

Nowadays, we all take reliable cars for granted. I know my car will always start in the morning, it will always get me where I need to go and it will always get me home again. I have air conditioning, anti-lock brakes, traction control, and a magic cruise control thingy that slows the car down if the car in front slows down. Much of the reliability is just because things are better built than they used to be but all the rest is down to the electronics and, especially, the software in the car. I strongly suspect my car has more computing power than the entire Apollo missions that put men on the moon.

What worries me as we blindly hurtle towards autonomous driving and self-steering, self-braking cars is who’s writing all this software? At the end of the day if things go south my life is at the mercy of their design meetings. I’ve been in design meetings and these thoughts do not make me happy!

Now to the main thrust of this blog entry: how to make sure your software is as good as you can make it.

Most micro-processors aimed at the automotive market have a debug interface: many of them go above and beyond a basic debug interface. Many of them implement the IEEE 5001 (NEXUS) standard debug interface (http://www.nexus50001.org). Debug interfaces are divided into four classes with each providing more capabilities than the previous one. This article will focus on using the Lauterbach TRACE32 tool with a selection of features found in NEXUS Class 3 as provided by the MPC55xx, MPC56xx and MPC57xx processors. I’ve chosen these processors as typical examples of those that are used in the automotive industry. There are others and many of those also subscribe to the NEXUS way of doing things

Setup is quite easy. If you have the correct Lauterbach trace hardware, plug it in to the board, power it all up, select the correct CPU type and establish a connection then the NEXUS features will have already been configured and are presented to you in the NEXUS window. Here’s a picture of one from an MPC5646.



Maybe in a future entry (if anyone is really interested or sad enough) I could go into more detail about the NEXUS protocol but essentially parts of the chip can generate messages. These messages are collected and spooled off-chip to a waiting set of trace tools. A brief introduction to the main message types follows.

Branch Trace Messages (BTM)
These are generated when a non-linear instruction is executed: a branch, a jump, an interrupt, etc. Collected they can form a program flow trace.

History Trace Message (HTM)
The NEXUS bandwidth is finite. Think of HTM as a clearing house. It collects a lot of BTMs and stuffs them all into a single message. This reduces the likelihood of messages dropping from the chip’s internal FIFO due to overflow. Unfortunately, all of the events in an HTM message have the same timestamp.

Ownership Trace Message (OTM)
These are created by an operating system and are used to indicate to the debugger that a task switch has occurred or that an interrupt or service call has been executed.

Watchpoint Trace Message (WTM)
These are created when a watchpoint is hit. Multiple watchpoints may be encapsulated into a single packet.

Data aQcuisition Message (DQM)
These messages are generated under software control and allow the user to log events of significance into the trace stream.

Data Trace Message (DTM)
Trace packets are generated on Load and/or Store operations.

Other options are there to offer fine tuning of the NEXUS interface, for example suppressing the generation of certain types of messages when the FIFO becomes nearly full; causing the processor to stall until a full FIFO has been emptied to ensure no loss of trace data; or adding program trace correlation messages to improve timing for certain statistical analyses. All of these options are fully described in the excellent Lauterbach documentation.

All of this data-y goodness allows you to do some very clever things when it comes to analysing your code.

Want to see the execution path through your code? It’s just a click away.



Want to view minimum, maximum and mean runtimes for your functions? Want to see how many times a function was called during a test? No problems.



How about runtimes of your RTOS’ threads?
For a single core system?


For a dual core SMP system?

 



All of this data is there waiting for you to go and explore it. The number of options for searching, analysing, calculating and displaying it are almost limitless: you can even export some, none or all of it to a bunch of other tools too!

Just before you go rushing off to play with your Lauterbach trace system (what do you mean you don’t have one?) allow me to let you in on another neat little secret that is hidden away in the NEXUS specification.

The processor is just a NEXUS client. A chip can support multiple NEXUS clients, all generating trace data to fulfil your sordid little desires for things to analyse. Think about that for a moment… What might those other clients be? A second core is one obvious answer that springs to mind, after all I did just show you a screenshot of a single RTOS running across a pair of processor cores in Symmetric Multi-Processing (SMP) fashion.

Another good guess might be the eTPU. You won’t see these messages in the Lauterbach PowerPC debugger because the eTPU is so important that it has its own debugger. It just happens to share the same hardware and connection as the PowerPC debugger but the two can run separately or inter-connected, to your choice.

In reality, the choice of clients is limited by the imagination of the silicon designer.
· Want to trace DMA transfers – check!
· Want to see what your FlexRay controller is doing – no problems.
· How about if you have an Ethernet controller and want to see what it’s up to – again, no problems.
All of these blocks can be capable of emitting NEXUS trace messages which will arrive at your debugger with little or no effort on your part. I know: “<insert your favourite profanity here> me, that’s impressive” I hear you exclaim. But it gets better.

The NEXUS-2012 specification allows for this wealth of data to be transmitted via the AURORA high speed interface. This may not mean much to you but for the same reason that PC hard-drives went from IDE (nasty, slow) to SATA (much faster, less prone to errors, cheaper), trace is moving from parallel to high speed serial. This change moves form 16 bits wide at around 80MHz to up to four single bit wide channels each clocked at 6.25GHz. This removes pressure on tiny on-chip FIFOs and means that more of that precious data can be delivered to allow developers to be even more certain that their code is just right.

The data is there, the next generation of engineers need to be trained how to manage and use it. Quality software engineering is becoming less about “hacking something together” and more about verifying that what you’ve created matches requirements and proving that it does what it is supposed to AND NOTHING ELSE! Now if only we could do something similar for all the bad decisions made in design meetings I would feel so much safer in my self-driving flying car of the future.

Let me know what you think?

Regards,

Flora. (email Flora at info@phaedsys.com )