CANopen diagnosis with UDE CANOpen-MessageFormatter-PlugIn

Efficient combination between CANopen diagnosis and microcontroller debugging

Lauta, January 2006 - For verification of microcontroller software and for diagnosis of CAN bus to date usually two different tools are used featuring two separate communication devices for CAN bus and debug interface to the microcontroller - running often on two diverse PCs. A solution for this dilemma is the integration of a CAN recorder in the microcontroller debugger including a flexible message formatting mechanism for CANopen and other protocols. This approach allows a significant increase of efficiency compared to traditional solutions based on separated tools.

Since only layer 1 and 2 are defined as transport media in the underlying CAN bus it is necessary to use an application layer protocol (layer 7) to describe the data exchange. For this CANopen is a widely used standard. A CAN message is structured at the lower layers via an identifier and up to 64 bits of data. A standard identifier (CAN base frame) contains 11 bits and an extended identifier (CAN extended frame) 29 bits. So single bus nodes respectively bus node functions are addressable respectively observable. The content of the message is included in the 64 bits of data.

The importance of the single message ID for the standard identifier range (0-7FFh) is defined in CANopen as shown in figure on the right side. For the transport of data there are of interest the service data objects (SDO) and process data objects. Whereas the SDOs are designed reading and writing of configuration and status data the PDOs are used for the actual application data. The CANopen standard provides a scheme for using the program data objects via so called device profiles.

In CANopen the device configurations files (DCF) are of particular importance. These are readable ASCII- text files and they are used for describing the characteristics and interfaces of the CAN nodes. Included are among others the names of the nodes, the used CAN IDs, and the usage of the PDOs. Thereby the names and types of parameters are defined that are included in the transmitted 64 bits of a PDO. The type of a parameter describes the size and location of the bit array dedicated to the parameter.

Basis of the concept realized by pls is a simple CAN recorder that is available as an add-in for a microcontroller debugging environment. It is able to lossless record all CAN massages and monitor symbolic names for the identifier. Filtering the identifiers and sending messages is also possible. The CAN interface for recording of messages is realized via the debugging communication device. This includes beside CAN a variety of interfaces like JTAG bus and serial interfaces for debug access to the microcontroller. The communication device itself features a powerful 32-bit microcontroller and a JTAG controller realized in hardware in a FPGA. This combination enables the continuous recording of all messages on the CAN bus even if the device is used primarily for the debug communication with a microcontroller system. The link to the CAN bus takes place via a D-Sub connector. The pin assignment is according to standard CiA 303-1. The device features a high speed interface driver according to ISO-11898-2.

The extension of the CAN recorder for interpreting the recorded data at the CAN bus is shown on right hand. It is made up of a general CANopen interpreter, the message formatter, and a DFC converter. The CANopen interpreter generates plain text output for every message types defined in the standard. This includes network management master messages (NMT), heartbeat, SDO protocol, sycn message, time stamp, and emergency message. If there is no more exact specification due to a message format file a text output is generated for the ID range given by the standard.

The message formatter allows monitoring such message content as edited text taken from this description file. The description file is able to contain blank lines and comment lines. The comment lines must start with a hash sign (#) as first printable character. The proper definition lines are made up syntactically as follows:

  <definition line> := <message ID> , "<format string>" [, <parameter list>]

  <parameter list> := <keyword> [, <keyword> …]

  <keyword> := <MSGID()> | <STDMSGID()> | >TIMESTAMP()> | <BITVALUE(start,end)>

• MessageIndex - for consecutive numbering of the recorded CAN messages.
• MessageID - for displaying the CAN identifier numerically or symbolically. In addition to the mentioned complex interpretation of the message you can use a simple mapping table between CAN identifiers and freely selectable text strings that are then displayed in this column.
• Timestamp - for displaying the time in milliseconds that runs between start of recording and receiving the appropriate message.
• Extended ID Flag - monitors whether the actual identifier uses the extended format. Identifiers from the standard ID range are not able to recognize the extended format from the plain numerical value.
• Message Direction - monitors whether a message was sent or received or it is a remote frame.
• Number of Bytes - shows the amount of data bytes in the recorded message.
• Message Lost Flag - displays if there was an overflow of the receive buffer of the recorders CAN hardware or whether there was a timeout by sending a message.
• Message Data - monitors the data bytes of a CAN message in numerical format
• Message formatter - allows the definition of a column for interpreted display of a CAN message in consideration of identifier and data bytes with a message formatter as mentioned; Figure below shows the display of formatted messages.

Trademarks

Editors contact