The Controller Area Network

Controller Area Network

CAN History Bosch originally developed the Controller Area Network (CAN) in 1985 for in-vehicle networks. In the past, automotive manufacturers connected electronic devices in vehicles using point-to-point wiring systems. Manufacturers began using more and more electronics in vehicles, which resulted in bulky wire harnesses that were very heavy and expensive. They then replaced dedicated wiring with in-vehicle networks, which reduce wiring cost, complexity, and weight. CAN, a high-integrity serial bus system for networking intelligent devices, emerged as the standard in-vehicle network. The automotive industry quickly adopted CAN and, in 1993, it became the international standard known as ISO 11898. Since 1994, several higher-level protocols have been standardized on CAN, such as CAN open and Device Net. Other markets have widely adopted these additional protocols, which are now standards for industrial communications. This white paper focuses on CAN as an in-vehicle network. Milestones of CAN History 1983 Start of the Bosch internal project to develop an In vehicle network.
DEPARTMENT OF COMPUTER SCIENCEPage 1

Controller Area Network

1986 1987

Official introduction of CAN protocol First CAN controller chips from Intel and Philips semiconductors. Bosch’s CAN specification 2.0 published. CAN kingdom CAN based higher layer Introduced by Kvaser.

1991 1991 protocol

1992 users

CAN in automation (CiA) international And manufacturers group established.

1992

CAN application layer (CAL) protocol Published by CiA. First car’s from Mercedes Benz used CAN Network. ISO 11898 standard published. First international CAN conference (iCC) Organized by CiA. Device net protocol introduction by Allen Bradley.

1992

1993 1994

1994

DEPARTMENT OF COMPUTER SCIENCEPage 2

Controller Area Network

1995

ISO 11898 amendment (Extended Frame Format) published. CAN open protocol published by CiA. Development of the Time triggered Communication protocol for CAN (TTCAN).

1995 2000

DEPARTMENT OF COMPUTER SCIENCEPage 3

Controller Area Network

INTRODUCTION The Controller Area Network (the CAN bus) is a serial communications bus for real-time control applications; operates at data rates of up to 1 Megabits per second, and has excellent error detection and confinement capabilities. CAN was originally developed by the German company, Robert Bosch, for use in cars, to provide a cost-effective communications bus for in-car electronics and as alternative to expensive, cumbersome and unreliable wiring looms and connectors. The car industry continues to use CAN for an increasing number of applications, but because of its proven reliability and robustness, CAN is now also being used in many other control applications. CAN is an international standard and is documented in ISO 11898 (for high-speed applications) and ISO 11519 (for lower-speed applications). Low-cost CAN controllers and interface devices are available as off-the-shelf components from several of the leading semiconductor manufacturers. Custom built devices and popular microcontrollers with embedded CAN controllers are also available. There are many CAN-related system development packages, hardware interface cards and easy-to-use
DEPARTMENT OF COMPUTER SCIENCEPage 4

Controller Area Network

software packages that provide system designers, builders and maintainers with a wide range of design, monitoring, analysis, and test tools. CAN technology used in Cars To satisfy customer requirements for greater safety, comfort, and convenience, and to comply with increasingly stringent government legislation for improved pollution control and reduced fuel consumption, the car industry has developed many electronic systems. Anti-lock Braking, Engine Management, Traction Control, Air Conditioning Control, central door locking, and powered seat and mirror controls are just some examples. The complexity of these controls systems, and the need to exchange data between them meant that more and more hard-wired, dedicated signal lines had to be provided. Sensors had to be duplicated if measured parameters were needed by different controllers. Apart from the cost of the wiring looms needed to connect all these components together, the physical size of the wiring looms sometimes made it impossible to thread them around the vehicle (to control panels in the doors, for example). In addition to the cost, the increased number of connections posed serious reliability, fault diagnosis, and repair problems during both manufacture and in service.
DEPARTMENT OF COMPUTER SCIENCEPage 5

Controller Area Network

A new solution was needed and, in the mid 1980s, the Robert Bosch company (a highly regarded supplier of components and sub systems to the automotive industry) provided the answer by specifying the Controller Area Network (CAN). Many of the world's chip manufacturers now offer a wide range of semiconductor devices that implement the protocol in small low-cost controllers and interface devices and most modern cars (certainly in Europe - and increasingly in the rest of the world) now use CAN. Industrial Applications of CAN CAN controllers and interface chips are physically small. They are available as low-cost, off-the-shelf components. They will operate at high, real-time speeds, and in harsh environments. All these properties have led to CAN also being used in a wide range of applications other than the car industry. The benefits of reduced cost and improved reliability that the car industry gains by using CAN are now available to manufacturers of a wide range of products. For example: Marine control and navigation systems Elevator control systems
DEPARTMENT OF COMPUTER SCIENCEPage 6

Controller Area Network

Agricultural machinery Production line control systems Machine tools Large optical telescopes Photo copiers Medical systems Paper making and processing machinery Packaging machinery Textile production machinery even toys for children Using CAN to network controllers, actuators, sensors, and transducers, manufacturers of all the abovementioned computer controlled products have benefited from: Reduced design time (readily available, multi sourced components, and tools) Lower connection costs (lighter, smaller cables and connectors) Improved reliability (fewer connections.) Safety: The safety-related aspects of using CAN in cars attracted the attention of manufacturers of medical systems. Because of the inherent reliability of the data transmission and the stringent safety
DEPARTMENT OF COMPUTER SCIENCEPage 7

Controller Area Network

requirements that need to be built into medical equipment such as X-ray machines and radio-therapy systems, CAN is now used in a range of these systems. User Groups: To cater for the growth in the use of CAN and to provide a forum for discussion, several User Groups have been formed. One of the first to be formed was the CAN Textile Users Group, but the principal international Users Group is CAN in Automation (CiA). Click here to access the CiA web site. How does CAN works? Principle: Data messages transmitted from any node on a CAN bus do not contain addresses of either the transmitting node, or of any intended receiving node. Instead, the content of the message (e.g. Revolutions Per Minute, Hopper Full, X-ray Dosage, etc.) is labelled by an identifier that is unique throughout the network. All other nodes on the network receive the message and each performs an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node. If the message is relevant, it will be processed; otherwise it is ignored. The unique identifier also
DEPARTMENT OF COMPUTER SCIENCEPage 8

Controller Area Network

determines the priority of the message. The lower the numerical value of the identifier, the higher the priority. In situations where two or more nodes attempt to transmit at the same time, a non-destructive arbitration technique guarantees that messages are sent in order of priority and that no messages are lost. Bit encoding: CAN uses Non Return to Zero (NRZ) encoding (with bit-stuffing) for data communication on a differential two wire bus. The use of NRZ encoding ensures compact messages with a minimum number of transitions and high resilience to external disturbance. The physical bus: The two wire bus is usually a twisted pair (shielded or unshielded). Flat pair (telephone type) cable also performs well but generates more noise itself, and may be more susceptible to external sources of noise. Robustness: CAN will operate in extremely harsh environments and the extensive error checking mechanisms ensure

DEPARTMENT OF COMPUTER SCIENCEPage 9

Controller Area Network

that any transmission errors are detected. See the 'Error Handling' section of this site for more details. The ISO11898 standard "Recommends" that bus interface chips be designed so that communication can still continue (but with reduced signal to noise ratio) even if: - Either of the two wires in the bus is broken - Either wire is shorted to power - Either wire is shorted to ground Network Flexibility and Expansion: The content-oriented nature of the CAN messaging scheme delivers a high degree of flexibility for system configuration. New nodes that are purely receivers, and which need only existing transmitted data can be added to the network without the need to make any changes to existing hardware or software. Measurements needed by several controllers can be transmitted via the bus, thereby removing the need for each controller to have its own individual sensor. Arbitrary Works on the CAN Bus: In any system, some parameters will change more rapidly than others. For example - parameters that change quickly could be the RPM of a car engine, or the current floor level of an elevator (US) - lift (UK).
DEPARTMENT OF COMPUTER SCIENCEPage 10

Controller Area Network

Slower changing parameters may be the temperature of the coolant of a car engine. It is likely that the more rapidly changing parameters need to be transmitted more frequently and, therefore, must be given a higher priority. To determine the priority of messages, CAN uses the established method known as Carrier Sense, Multiple Access with Collision Detect (CSMA/CD) but with the enhanced capability of non-destructive bitwise arbitration to provide collision resolution, and to deliver maximum use of the available capacity of the bus. Non-Destructive Bitwise Arbitration: The priority of a CAN message is determined by the numerical value of its identifier. The numerical value of each message identifier (and thus the priority of the message) is assigned during the initial phase of system design. The identifier with the lowest numerical value has the highest priority. Any potential bus conflicts are resolved by bitwise arbitration in accordance with the wired-and mechanism, by which a dominant state (logic 0) overwrites a recessive state (logic 1). The Benefits: Non-destructive bitwise arbitration provides bus allocation on the basis of need, and delivers
DEPARTMENT OF COMPUTER SCIENCEPage 11

Controller Area Network

efficiency benefits that cannot be gained from either fixed time schedule allocation (e.g. Token ring) or destructive bus allocation (e.g. Ethernet.) With only the maximum capacity of the bus as a speed limiting factor CAN will not collapse or lock up. Outstanding transmission requests are dealt with in their order of priority, with minimum delay, and with maximum possible utilization of the available capacity of the bus. CAN Message Format Message Frames: In a CAN system, data is transmitted and received using Message Frames. Message Frames carry data from a transmitting node to one, or more, receiving nodes. The Standard CAN protocol (version 2.0A), also now known as Base Frame Format, supports messages with 11 bit identifiers. The Extended CAN protocol (version 2.0B), also now known as Extended Frame Format, supports both 11 bit and 29 bit identifiers. Most 2.0A controllers transmit and receive only Standard format messages, although some (known as 2.0B passive) will receive extended format

DEPARTMENT OF COMPUTER SCIENCEPage 12

Controller Area Network

messages - but then ignore them. 2.0B controllers can send and receive messages in both formats. 2.0A Format: A Standard CAN (Version 2.0A) Message Frame consists of seven different bit fields: A Start of Frame (SOF) field - which indicates the beginning of a message frame. An Arbitration field, containing a message identifier and the Remote Transmission Request (RTR) bit. The RTR bit is used to discriminate between a transmitted Data Frame and a request for data from a remote node.

Fig.CAN 2.0A Message Frame

A Control Field containing six bits: * two reserved bits (r0 and r1) and * a four bit Data Length Code (DLC). The DLC indicates the number of bytes in the Data Field that follows A Data Field, containing from zero to eight bytes.
DEPARTMENT OF COMPUTER SCIENCEPage 13

Controller Area Network

The CRC field, containing a fifteen bit cyclic redundancy check code and a recessive delimiter bit The Acknowledge field, consisting of two bits. The first is the Slot bit which is transmitted as recessive, but is subsequently over written by dominant bits transmitted from any node that successfully receives the transmitted message. The second bit is a recessive delimiter bit The End of Frame field, consisting of seven recessive bits. Following the End of Frame is the Intermission field consisting of three recessive bits. After the three bit Intermission period the bus is recognized to be free. Bus Idle time maybe of any arbitrary length including zero. 2.0B Format: The CAN 2.0B format provides a twenty nine (29) bit identifier as opposed to the 11 bit identifier in 2.0A. Version 2.0B evolved to provide compatibility with other serial communications protocols used in automotive applications in the USA. To cater for this, and still provide compatibility with the 2.0A format, the Message Frame in Version 2.0B has an extended format. The differences are:

DEPARTMENT OF COMPUTER SCIENCEPage 14

Controller Area Network

- In Version 2.0B the Arbitration field contains two identifier bit fields. The first (the base ID) is eleven (11) bits long for compatibility with Version 2.0A. The second field (the ID extension) is eighteen (18) bits long, to give a total length of twenty nine (29) bits. - The distinction between the two formats is made using an Identifier Extension (IDE) bit. - A Substitute Remote Request (SRR) bit is also included in the Arbitration Field. The SRR bit is always transmitted as a recessive bit to ensure that, in the case of arbitration between a Standard Data Frame and an Extended Data Frame, the Standard Data Frame will always have priority if both messages have the same base (11 bit) identifier. All other fields in a 2.0B Message Frame are identical to those in the Standard format. 2.0A and 2.0B Compatibility: 2.0B controllers are completely backward compatible with 2.0A controllers and can transmit and receive messages in either format. Note, however, that there are two types of 2.0A controllers: - The first is capable of transmitting and receiving only messages in 2.0A format. With this type of controller, reception of any 2.0B message will flag an error.
DEPARTMENT OF COMPUTER SCIENCEPage 15

Controller Area Network

- The second (known as 2.0B passive) is capable of sending and receiving 2.0A messages. They will also acknowledge receipt of 2.0B messages - but then ignore them. Therefore, within the above mentioned constraints it is possible to use both Version 2.0A (with 2.0B passive capabilities) and 2.0B controllers on a single network. The number of unique identifiers available to users, on a single 2.0A network, is 2,032 (2 to the power 11 - 2 to the power 4). Leaving aside the use for compatibility purposes with American buses, the number of unique identifiers available on a 2.0B network is in excess of 500 million! Implementations of CAN Communication is identical for all implementations of CAN. However, there are two principal hardware implementations. The two implementation are known as Basic CAN and Full CAN. ***Note*** The terms Basic CAN and Full CAN must not be confused with the terms Standard CAN - also known as Base Frame Format (11 bit identifier, Version 2.0A
DEPARTMENT OF COMPUTER SCIENCEPage 16

Controller Area Network

data format) and Extended CAN - also known as Extended Frame Format (29 bit identifier, or Version 2.0B data format). Suitably configured, each implementation (Basic or Full CAN) can handle both Base and Extended data formats. Basic CAN: In the Basic-CAN devices, only basic functions concerning the filtering and management of CAN messages are implemented in hardware. A Basic-CAN controller typically provides one transmit buffer for outgoing messages and one or two receive buffers for incoming messages. In the receive path, an acceptance filtering is available which allows that only certain CAN identifiers are stored in the receive buffer. Because there are only two buffers for the reception of messages the host controller is quite busy reading and storing the incoming messages before they get overwritten by the following ones which results in a quite high CPU load. Also the answering of Remote Frames with the corresponding Data Frame has to be handled by the host controller. Therefore Basic-CAN devices should only be used at low baud rates and low bus loads with only a few different messages.

DEPARTMENT OF COMPUTER SCIENCEPage 17

Controller Area Network

Full CAN: Full-CAN devices provide the whole hardware for convenient acceptance filtering and message management. For each message to be transmitted or received these devices contain one so called message object in which all information regarding the message (e.g. identifier, data bytes etc.) are stored. During the initialisation of the device, the host CPU defines which messages are to be sent and which are to be received. Only if the CAN controller receives a message whose identifier matches with one of the identifiers of the programmed (receive-) message objects the message is stored and the host CPU is informed by interrupt. Another advantage is that incoming Remote Frames can be answered automatically by the FullCAN controller with the corresponding Data Frame. In
DEPARTMENT OF COMPUTER SCIENCEPage 18

Controller Area Network

this way, the CPU load is strongly reduced compared to the Basic-CAN solution. Using Full CAN devices, high baudrates and high bus loads with many messages can be handled. Many Full-CAN controller provide a "Basic-CAN Feature": One of their message objects behaves like a Basic-CAN Receive Buffer, i.e. it can be programmed in a way that every message is stored there that does not match with one of the other message objects. This can be very helpful in applications where the number of message objects is not enough to receive all desired messages.

Network Sizes:

DEPARTMENT OF COMPUTER SCIENCEPage 19

Controller Area Network

The number of nodes that can exist on a single network is, theoretically, limited only by the number of available identifiers. However, the drive capabilities of currently available devices impose greater restrictions. Depending on the device types, up to 32 or 64 nodes per network is normal, but at least one manufacturer now provides devices that will allow networks of 110 nodes. Data Rate vs. Bus Length: The rate of data transmission depends on the total overall length of the bus and the delays associated with the transceivers. For all ISO11898 compliant devices running at 1Mbit/sec speed, the maximum possible bus length is specified as 40 Meters, For longer bus lengths it is necessary to reduce the bit rate. To give some indication of this the following numbers are from the Device Net features list: 500 K bits per second at 100 meters (328 ft) 250 K bits per second at 200 metres (656 ft) 125 K bits per second at 500 metres (1640 ft)

The OSI model ISO7498 defines a communications standard known as the Open Systems Interconnection (OSI) model. This model describes how communications should
DEPARTMENT OF COMPUTER SCIENCEPage 20

Controller Area Network

occur between computers on any network, and has been adopted as a general "open" network communication standard. In principle - anything that conforms to the standard can communicate, electronically, with anything else that conforms to the standard. The OSI model defines seven independent "layers" of a protocol stack. Strict compliance with the standard requires that each layer is insulated from the others by well-defined interfaces. Few, if any, networks comply absolutely with the OSI model with regard to provision of all seven layers as distinct entities.

Fig.OSI reference model. CAN and the OSI Model

DEPARTMENT OF COMPUTER SCIENCEPage 21

Controller Area Network

The CAN specification (ISO11898) discusses only the Physical and Data-Link layers for a CAN network. The Data-Link Layer - is the only layer that recognizes and understands the format of messages. This layer constructs the messages to be sent to the Physical Layer, and decodes messages received from the Physical Layer. In CAN controllers, the Data-Link Layer is usually implemented in hardware. The Physical Layer - specifies the physical and electrical characteristics of the bus, and of the hardware that converts the characters of a message into electrical signals for transmitted messages - and electrical signals into characters for received messages. Although the other layers may be implemented in either hardware (as chip level functions) or software, the Physical Layer is always "real" hardware. CAN Applications Layers: Many applications of CAN require services that are beyond the basic functionality specified by the DataLink Layer but which may be implemented at the Application Layer. For example, the transmission or reception of data units longer than eight bytes. To meet this need several organizations have developed Application Layers. Brief details about just a few of them and contact details are given below. CAL (CAN Application Layer):
DEPARTMENT OF COMPUTER SCIENCEPage 22

Controller Area Network

Aptly named, and based on an existing and proven protocol originally developed by Philips Medical Systems, CAL is an application-independent application layer that has been specified and is now maintained by the CAN in Automation (CiA) user group. Anyone who implements CAL may do so free of any license royalty. The CAL specification (document reference CiA DS-201...207) may be purchased from CiA. See the CiA web site for details. CAN open: CAN open is an implementation of CAL and is defined by the CAN open Communications Profile in CiA DS301. This document may also be purchased from CiA. Information about CAN open may be obtained from the CiA User Group You might also want to get hold of a copy of "Embedded Networking with CAN and CAN open" by Olaf Pfeiffer, Andrew Ayre and Christian Keydel. Published by RTC Books. ISBN: 0-929392-78-7. Price in the USA $49.95. Device Net: Device Net is a CiA-approved application layer based on CAN 2.0A and is widely used in industrial automation applications. Device Net (originally developed by Rockwell/Allen-Bradley) is now an “Open” field bus regulated by an independent organization knows as the Open Device Net Vendors
DEPARTMENT OF COMPUTER SCIENCEPage 23

Controller Area Network

Association, from who copies of the specification may be purchased. Purchasers of the specification receive an unlimited, royalty-free license to develop Device Net compatible products. See the ODVA web site for full details. NMEA 2000: An application layer used in the marine and pleasure craft sector. For details see the NMEA web site. SDS (Smart Distributed System): SDS is also a CiA-approved application layer. Developed by Honeywell, one of the main uses of SDS is for machine control applications. See the Honeywell web site for details. CAN Kingdom: Another CiA-approved application layer, named CAN Kingdom, is provided by a Swedish company named Kvaser AB. You can find out all about it if you search the Kvaser site.

DEPARTMENT OF COMPUTER SCIENCEPage 24

Controller Area Network

Error Detection CAN implements five error detection mechanisms; three at the message level and two at the bit level. At the message level: Cyclic Redundancy Checks (CRC) Frame Checks Acknowledgment Error Checks (ACK) At the bit level: Bit Monitoring Bit Stuffing Cyclic Redundancy Check: Every transmitted message contains a 15 bit Cyclic Redundancy Check (CRC) code. The CRC is computed by the transmitter and is based on the message content. All receivers that accept the message perform a similar calculation and flag any errors. If node B detects a mismatch between the calculated and the received CRC sequence, then a CRC error has occurred. Node B discards the message and transmits an Error Frame to request retransmission of the garbled frame.
DEPARTMENT OF COMPUTER SCIENCEPage 25

Controller Area Network

Frame Check: There are certain predefined bit values that must be transmitted at certain points within any CAN Message Frame. If a receiver detects an invalid bit in one of these positions a Form Error (also known as a Format Error) will be flagged. If a transmitter detects a dominant bit in one of the four segments:  CRC Delimiter,  Acknowledge Delimiter,  End of Frame or  Interframe Space
DEPARTMENT OF COMPUTER SCIENCEPage 26

Controller Area Network

then a Form Error has occurred and an Error Frame is generated. The message will then be repeated.

Acknowledgement (ACK) Error Check: If a transmitter determines that a message has not been acknowledged then an ACK Error is flagged. With the Acknowledge Check, the transmitter checks in the Acknowledge Field of a message to determine if the Acknowledge Slot, which is sent out as a recessive bit, contains a dominant bit. If this is the case, at least one other node, (here node B) has received the frame correctly. If not, an Acknowledge Error has occurred and the message has to be repeated. No Error Frame is generated, though.

DEPARTMENT OF COMPUTER SCIENCEPage 27

Controller Area Network

Bit Monitoring: Any transmitter automatically monitors and compares the actual bit level on the bus with the level that it transmitted. If the two are not the same, a bit error is flagged. All nodes perform Bit Monitoring: A Bit Error occurs if a transmitter sends a dominant bit but detects a recessive bit on the bus line or, sends a recessive bit but detects a dominant bit on the bus line. An Error Frame is generated and the message is repeated. When a dominant bit is detected instead of a recessive bit, no error occurs during the Arbitration Field or the Acknowledge Slot because these fields must be able to be overwritten by a dominant bit in order to achieve arbitration and acknowledge functionality.
DEPARTMENT OF COMPUTER SCIENCEPage 28

Controller Area Network

Bit Stuffing: CAN uses a technique known as bit stuffing as a check on communication integrity. After five consecutive identical bit levels have been transmitted, the transmitter will automatically inject (stuff) a bit of the opposite polarity into the bit stream. Receivers of the message will automatically delete (de-stuff) such bits before processing the message in any way. Because of the bit stuffing rule, if any receiving node detects six consecutive bits of the same level, a stuff error is flagged. If six consecutive bits with the same
DEPARTMENT OF COMPUTER SCIENCEPage 29

Controller Area Network

polarity are detected between Start of Frame and the CRC Delimiter, the bit stuffing rule has been violated. A stuff error occurs and an Error Frame is generated. The message is then repeated.

Error Frame: If an error is detected by any node, using any and all of the five mechanisms described above, the node that detects the error aborts the transmission by sending an Error Frame. This prevents any other node from accepting the message and ensures consistency of data throughout the network. Error Confinement: Error confinement is a mechanism which is understood to be unique to CAN and provides a method for discriminating between temporary errors and permanent failures. Temporary errors may be
DEPARTMENT OF COMPUTER SCIENCEPage 30

Controller Area Network

caused by, spurious external conditions, voltage spikes, etc. Permanent failures are likely to be caused by bad connections, faulty cables, defective transmitters or receivers, or long lasting external disturbances. The general principle only is described here. More detailed information is available in the ISO standard, and in the data sheets from the device manufacturers. Error Counts: When an error is flagged, error counts are added to one of two dedicated error count registers within each CAN controller on each node. It's more complex than stated here, but - in principal - receive errors are given a weighting of 1 and are accumulated in a Receive Error Count register; transmit errors are given a weighting of 8 and accumulated in a Transmit Error Count register. If errors continue to occur, the error counts continue to increase. Any good messages decrement the Error Count registers and, if no further errors are detected, both Error Counts go back to zero. The accumulated error counts determine the error status of a node.

DEPARTMENT OF COMPUTER SCIENCEPage 31

Controller Area Network

Error Active Mode: Nodes usually operate in a state known as Error Active mode. In this condition a node is fully functional and both the Error Count registers contain counts of less than 127.

DEPARTMENT OF COMPUTER SCIENCEPage 32

Controller Area Network

Error Passive Mode: If the count in either Error Count register in a node exceeds 127, the node will go from Error Active mode to a heightened state of "alert" known as Error Passive mode. Error Passive nodes can still transmit and receive messages but are restricted in relation to how they flag any errors that they may detect. The ISO standard (and some of the device data sheets) explain the precise mechanisms in more detail.
DEPARTMENT OF COMPUTER SCIENCEPage 33

Controller Area Network

Bus Off Mode: If an error condition persists, such that the Transmit Error Count of a device exceeds 255, the device will take itself off the bus by going to BusOff mode. This means that a permanently faulty device will cease to be active on the bus until reconnected under user control, but communications between the other nodes can continue unhindered. Error Detection Capabilities: Error detection on CAN is extremely thorough.

DEPARTMENT OF COMPUTER SCIENCEPage 34

Controller Area Network

Global errors which occur at all nodes are 100% detectable. For local errors (i.e. errors which may appear at only some nodes) the CRC check alone has the following error detection capabilities: Up to 5 single bit errors are 100% detectable, even if the errors are distributed randomly within the code word All single bit errors are detected if their total number within the code word is odd The residual (undetected) error probability of the CRC check alone is 3 x 10 to the power -5. In conjunction with all the other error checking mechanisms, a more realistic value is 10 to the power -11.

Bit time: As defined in ISO11898, the nominal time for each bit in a CAN message frame is made up of four nonoverlapping time segments as shown below.

DEPARTMENT OF COMPUTER SCIENCEPage 35

Controller Area Network

Fig. Bit time segments Sync-seg is the segment that is used to synchronize the nodes on the bus. A bit edge (if there is a data change) is expected during this segment. Prop-Seg is a period of time that is used to compensate for physical delay times within the network. Phase-seg1 is a buffer segment that may be lengthened during resynchronization to compensate for oscillator drift and positive phase differences between the oscillators of the transmitting and receiving node(s). Phase-seg2 is a buffer segment that may be shortened during resynchronization (described below) to compensate for negative phase errors and oscillator drift. The Sample point is always at the end of Phase-seg1 and is the time at which the bus level is read and interpreted as the value of the current bit. Whether transmitting or receiving, all nodes on a single CAN bus must have the same nominal bit time. Bit time is programmable at each node on a CAN Bus
DEPARTMENT OF COMPUTER SCIENCEPage 36

Controller Area Network

and is a function of the period of the oscillator local to each node, the value that is user-programmed into a Baud Rate Prescaler (BRP) register in the controller at each node, and the programmed number of time quanta per bit. One time quanta (Also known as the system clock period) is defined as the period of the local oscillator, multiplied by the value in the BRP. Each of the four time segments in one bit is one or more time quanta long. As stated in the Bosch CAN2 spec: Sync-Seg is always one time quantum long Prop-Seg is programmable from one to eight (or, optionally, more) time quanta long Phase-seg1 is programmable from one to eight (or, optionally, more) time quanta long Phase-seg2 is the maximum of Phase-seg1 and the Information Processing Time Where the Information Processing Time is less than or equal to 2 time quanta. Synchronization When any node receives a data frame or a remote frame, it is necessary for the receiver to synchronize with the transmitter.
DEPARTMENT OF COMPUTER SCIENCEPage 37

Controller Area Network

Because there is no explicit clock signal that a CAN system can use as a timing reference, two mechanisms are used to maintain synchronization. The first is hard synchronization and occurs at Startof-Frame (SOF). To compensate for oscillator drift, and phase differences between transmitter and receiver oscillators, additional synchronization is needed. So - for subsequent bits in any received frame, if a bit edge does not occur in the Sync-Seg segment of bit time, resynchronization is automatically invoked and will shorten or lengthen the current bit time depending on where the edge occurs. The maximum amount by which the bit time is lengthened or shortened is determined by a user-programmable number of time quanta known as the Synchronization Jump Width (SJW).

DEPARTMENT OF COMPUTER SCIENCEPage 38

Controller Area Network

The overview of Controller Area Network’s Basics Is a high-integrity serial data communications bus for real-time control applications. Operates at data rates of up to 1 Mega bits per second Have excellent error detection and confinement capabilities Was originally developed for use in cars Is now being used in many other industrial automation and control applications CAN is documented in ISO 11898 (for applications up to 1 Mega bits per second) and ISO 11519 (for applications up to 125 K bits per second)

DEPARTMENT OF COMPUTER SCIENCEPage 39

Controller Area Network

CONTROLLER AREA NETWORK (CAN) PROTOCOL The Controller Area Network (CAN) protocol, developed by ROBERT BOSCH GmbH, offers a comprehensive solution to managing communication between multiple CPUs. The CAN protocol specifies versatile message identifiers that can be mapped to specific. Control information categories. Communications may occur at a maximum recommended rate of 1 Mbit/sec (roughly a 40 meter bus length). The protocol has found wide acceptance in automotive in-vehicle applications as well as many non-automotive due to its low cost, high performance, and the availability of
DEPARTMENT OF COMPUTER SCIENCEPage 40

Controller Area Network

various CAN protocol implementations. In-vehicle networking protocols must satisfy unique requirements not present in other networking protocols such as those found in telecommunications and data processing. These requirements include a high level of error detection, low latency times and configuration flexibility. The CAN protocol provides four primary benefits. First, a standard communications protocol simplifies and economizes the task of interfacing subsystems from various vendors onto a common network. Second, the communications burden is shifted from the host-CPU to an intelligent peripheral; the host-CPU has more time to run its system tasks. Third, as a multiplexed network, CAN greatly reduces wire harness size and eliminates point-to-point wiring. Lastly, as a standard protocol, CAN has broad market appeal which motivates semiconductor makers to develop competitively priced CAN devices. An example of an application well-served by the CAN protocol is automotive networking because many modules are inter-dependent. Sub-systems such as the engine,
DEPARTMENT OF COMPUTER SCIENCEPage 41

Controller Area Network

transmission, anti-lock braking, and accident avoidance systems require the exchange of particular performance and position information within a defined communications latency. The engine transmits engine speed and acceleration parameters to the transmission to allow smoother shifting. Perhaps the transmission requests the engine to reduce fuel injection before a gear change. CAN is a CSMA/CD-A, or Carrier Sense Multiple Access by Collision Detection using Arbitration protocol. Through a multi-master architecture, prioritized messages of length 8 bytes or less are sent on a serial bus. Error detection mechanisms, such as a 15-bit Cyclical Redundancy Check (CRC), provide a high level of data integrity. For information on the CAN protocol, please read the CAN Specification, Version 2.0. The CAN 2.0 protocol was chosen by the SAE Truck & Bus Control and Communications Network Subcommittee of the Truck & Bus Electrical Committee to support its ``Recommended Practice for Serial Control and Communciations Vehicle Network CLASS C'' called the SAE J1939 specification. The SAE CLASS C passenger car subcommittee is currently evaluating CAN,
DEPARTMENT OF COMPUTER SCIENCEPage 42

Controller Area Network

which is a candidate for its high speed networks. Products using CAN Version 2.0 are already in production. The previous CAN specification, Version 1.2, has been successfully implemented in passenger car, train and factory automation applications since 1989. CAN Version 2.0, which features an ``extended frame'' with a 29bit message identifier, broadens the application base for this protocol by allowing J1850 message schemes to be mapped into the CAN message format. The Intel 82526 was the first implementation of the CAN protocol, in production since 1989. The Intel 82527 is a follow-on to the 82526 which implements CAN Version 2.0, provides greater message handling capability and implements a more flexible interface to CPUs.

DEPARTMENT OF COMPUTER SCIENCEPage 43

Controller Area Network

Vehicle Applications of Controller Area Network

Introduction

DEPARTMENT OF COMPUTER SCIENCEPage 44

Controller Area Network

In the automotive industry, embedded control has grown from stand-alone systems to highly integrated and networked control systems [11, 7]. By networking electro-mechanical subsystems, it becomes possible to modularize functionalities and hardware, which facilitates reuse and adds capabilities. Figure shows an example of an electronic control unit (ECU) mounted on a diesel engine of a Scania truck. The ECU handles the control of engine, turbo, fan, etc. but also the CAN communication. Combining networks and mechatronic modules makes it possible to reduce both the cabling and the number of connectors, which facilitates production and increases reliability. Introducing networks in vehicles also make it possible to more efficiently carry out diagnostics and to coordinate the operation of the separate subsystems.

Protocol extensions
DEPARTMENT OF COMPUTER SCIENCEPage 45

Controller Area Network

CAN provides the basic functionality described above. In many situations, it is desirable to use standardized protocols that define the communication layers on top of the CAN. Such higher-layer protocols are described below together with CAN gateways and the time-triggered extension of CAN denoted TTCAN, which allows periodic access to the communication bus with a high degree of certainty. Higher-layer protocols In order to use CAN, protocols are needed to define the other layers. Field bus protocols usually do not define the session and presentation layers, since they are not needed in these applications. The users may either decide to define their own software for handling the higher layers, or they may use a standardized protocol. Existing higher-layer protocols are often tuned to a certain application domain. Examples of such protocols include SAE J1939, CAN open, and Device Net. It is only SAE J1939 that is specially developed for vehicle applications. Recently, attempts have been made to interface CAN and Ethernet, which is the dominant technology for local area networks and widely applied for connecting to the Internet. SAE J1939 is a protocol that defines the higher-layer communication control. It was developed by the American Society of Automotive Engineers (SAE) and is thus targeted to the automotive industry. The advantage of having a standard is considerable, since it enables
DEPARTMENT OF COMPUTER SCIENCEPage 46

Controller Area Network

independent development of the individual networked components, which also allows vehicle manufacturers to use components from different suppliers. SAE J1939 specifies, e.g., how to read and write data, but also how to calibrate certain subsystems. The data rate of SAE J1939 is about 250 kbps, which gives up to about 1850 messages per second [6]. Applications of SAE J1939 include truckand-trailer communication, vehicles in agriculture and forestry, as well as navigation systems in marine applications. CAN open is a standardized application defined on top of CAN and widely used in Europe for the application of CAN in distributed industrial automation. It is a standard of the organization CAN in Automation (CiA). CAN open specify communication profiles and device profiles, which enable an application-independent use of CAN. The communication profile defines the underlying communication mechanism. Device profiles exist for the most common devices in industrial automation, such as digital and analog I/O components, encoders, and controllers. The device can be configured through CAN open independent of its manufacturer. CAN open distinguish real-time data exchange and less critical data exchange. It provides standardized communication objects for real-time data, configuration data, network management data, and

DEPARTMENT OF COMPUTER SCIENCEPage 47

Controller Area Network

certain special functions (e.g., time stamp and synchronization messages).Device Net is another standardized application defined on top of CAN for distributed industrial automation. It is mainly used in the U.S.A. and Asia and was originally developed by Rockwell Automation. Device Net, Control-Net, and transmission control protocol/Internet protocol (TCP/IP) are open network technologies that share upper layers of the communication protocol, but are based on lower layers. Device Net is built on CAN, Control Net on a tokenpassing bus protocol, and TCP/IP on Ethernet. CAN Kingdom is a high-layer protocol used for motion control systems. It is also used in the maritime industry; CAN Kingdom allows the changing of network behavior at any time, including while the system is running. For example, CAN Kingdom allows the system troubleshooter to turn off individual nodes. The CAN node identifiers and the triggering conditions for sending messages can be changed while the system is running. One instance when real-time network reconfiguration is used is during failure conditions. An example is a loss of a radio link ECU in a maritime application. The network monitor, also known as the King, in that case first shuts off the radio node to keep it from sending any more commands, and then tells the appropriate nodes to get data from the King.

DEPARTMENT OF COMPUTER SCIENCEPage 48

Controller Area Network

This operation eliminates the problem of a node receiving two simultaneous but conflicting commands. It also eliminates the problem of two nodes sending the same CAN id. The high-level protocols described above have been developed with different applications and traditions in mind, which is reflected, for example, in their support for real-time control. Although SAE J1939 is used for implementing control algorithms, it does not provide explicit support for time-constrained messaging. In contrast, such functionalities are provided by CAN Kingdom and CAN open, which handle explicit support for inter-node synchronization. CAN Kingdom and CAN open allow static and dynamic configuration of the network, whereas SAE J1939 provides little flexibility. CAN gateways Gateways and bridges enable CAN-based networks to be linked together or linked to networks with other protocols. A gateway between a CAN and another communication network maps the protocols of the individual networks. There exist many different types of CAN gateways, e.g., CAN-RS232 and CAN-TCP/IP gateways. The latter can provide remote access to a CAN through the Internet, which allows worldwide monitoring and maintenance. The networks connected through a gateway or a bridge are disconnected in terms of their real-time behavior, so obviously the timing and performance of

DEPARTMENT OF COMPUTER SCIENCEPage 49

Controller Area Network

the complex inter-connected network can be hard to predict even if the individual networks are predictable. Ethernet (or rather Ethernet/IP) is quite a different communication protocol compared to CAN, but is still of growing importance in industrial automation either in constellations with CAN or on its own. Traditionally, Ethernet is used in office automation and multimedia applications, while CAN dominates in vehicles and in certain industrial automation systems. The strength of Ethernet is the ability to quickly move large amounts of data over long distances and that the number of nodes in the network can be large. CAN, on the other hand, is optimized for transmitting small messages over relatively short distances. A drawback with a network based on the Ethernet protocol is that the nodes need to be quite powerful and complex (and therefore more expensive) in order to handle the communication control. Another drawback with Ethernet is that during network traffic congestion the delay jitter can be severe and unpredictable, although at low network load Ethernet gives almost no delay. Time-triggered communication on CAN Traditional CAN communication is event based: asynchronous events are triggered by node applications that initialize each transmission session. In many cases, this strategy is an efficient way to
DEPARTMENT OF COMPUTER SCIENCEPage 50

Controller Area Network

share the network resource. There are a variety of applications, however, that require a guaranteed access to the communication bus with a fixed periodic rate. This constraint is typical for sampleddata feedback control systems. In the automotive industry, x-by-wire systems are examples of such control systems with deterministic communication behavior during regular operation. By introducing the notion of global network time, the standard ISO 118984 define the extension Time-triggered communication on CAN (TTCAN). It is built on top of the traditional event-triggered CAN protocol and enables existing CAN nodes to work in parallel with TTCAN nodes. The global clock requires hardware implementation; otherwise, TTCAN is a pure software extension of CAN. The synchronization in TTCAN takes place through a periodic reference message, which all TTCAN nodes recognize and use to synchronize their clocks. The nodes are configured to know when to send their message after the reference message. The period time of the transmission of a periodic node should be a multiple of the reference period. Traditional CAN nodes (or event-based TTCAN nodes) compete for the access of the free windows between the reference messages, along the line of the conventional CAN protocol. This mechanism is thus the reason why time-triggered and even triggered scheduling is possible simultaneously in TTCAN. The sender of the reference message is obviously a crucial node in TTCAN to guarantee clock
DEPARTMENT OF COMPUTER SCIENCEPage 51

Controller Area Network

synchronization. Therefore, an automatic procedure is provided for letting another node take over if the reference sender fails, and taking the reference back when the original clock master recovers. It is possible to use an external clock, for example, from the global positioning system (GPS).

Control Applications Two vehicular control systems with loops closed over CAN buses are discussed in this section. The first example is a vehicle dynamics control system for passenger cars that is manufactured by Bosch. The second example is an attitude and orbit control system for the SMART-1 spacecraft discussed in the previous section. Vehicle Dynamics control system Vehicle dynamics control4 systems are designed to assist the driver in over steering, under-steering and roll-over situations [15, 9]. The principle of a vehicle dynamics control (VDC) system is illustrated in figure. The left figure shows a situation where over-steering takes place, illustrating the case where the friction limits are reached for the rear wheels causing the tire forces to saturate (saturation on the front wheels will
DEPARTMENT OF COMPUTER SCIENCEPage 52

Controller Area Network

instead cause an under-steer situation). Unless the driver is very skilled, the car will start to skid, meaning that the vehicle yaw rate and vehicle side slip angle will deviate from what the driver intended. This is the situation shown for the left vehicle. For the vehicle on the right, the on-board VDC will detect the emerging skidding situation and will compute a compensating torque, which for the situation illustrated is translated into applying a braking force to the outer front wheel. This braking force will provide a compensating torque and the braking will also reduce the lateral force for this wheel. The central components of VDC are illustrated on the right in figure. In essence, the VDC will assist the driver by making the car easier to steer and by improving its stability margin.

Illustration of behavior during over-steering for vehicle with and without VDC system (left figure). Central components of VDC (right figure). (Based on figures provided by the Electronic Stability Control Coalition.) DEPARTMENT OF COMPUTER SCIENCEPage 53

Controller Area Network

Attitude and orbit control system This section describes parts of the SMART-1 attitude and orbit control system and how it is implemented in the on-board distributed computer system. The control objectives of the attitude and orbit control system are to: • follow desired trajectories according to the goals of the mission, • point the solar panels toward the sun, and • minimize energy consumption. The control objectives should be fulfilled despite the harsh environment and torque disturbances acting on the spacecraft, such as aero drag (initially when close to earth), gravitational gradient, magnetic torque, and solar pressure (mechanical pressure from photons). There are several phases that the control system should be able to handle, including the phase just after separation from the launcher, the thrusting phases on the orbit to the moon, and the moon observation phase.

DEPARTMENT OF COMPUTER SCIENCEPage 54

Controller Area Network

Structure of SMART-1 spacecraft with sensors and actuators for the attitude And orbit control system. (Courtesy of the Swedish Space Corporation.)

The attitude and orbit control system consists of a set of control functions for rate damping, sun pointing, solar array rotation, momentum reduction, three-axis attitude control, and electric propulsion (EP) thruster orientation. The system has a number of operation modes, which consist of a subset of these control functions. The operation modes include the following: • Detumble mode: In this mode, rotation is stabilized using one P-controller per axis with the aid of the hydrazine thrusters and the rate sensors. • Safe mode: Here the EP thruster is pointed toward the sun and set to rotate one revolution per hour around the sun vector. The attitude is controlled using a bang-bang strategy for large sun angles and a PID controller for smaller angles. Both controllers use the reaction wheels as actuators and the sun tracker as sensor.
DEPARTMENT OF COMPUTER SCIENCEPage 55

Controller Area Network

The spacecraft rotation is controlled using a PI controller. When the angular velocity of the reaction wheels exceeds a Certain limit, their momentum is reduced by use of the hydrazine thrusters. • Science mode: In this mode, ground provides the attitude set-points for the spacecraft and the star tracker provides the actual attitude. The reaction wheels and the hydrazine thrusters are used. • Electric propulsion control mode: This mode is similar to the science mode apart from the additional control of the EP orientation mechanism. This mechanism can be used to tilt the thrust vector in order to off-load the reaction wheel momentum about the two spacecraft axes that form the nominal EP thrust plane. This reduces the amount of hydrazine needed. The EP mechanism is controlled in an outer and slower control loop (PI) based on the speed of the reaction wheels and the rotation of the spacecraft body. Sales of CAN Nodes in Automation The CAN protocol was internationally standardized in 1993 as ISO 11898-1. The development of CAN was mainly motivated by the need for new functionality, but it also reduced the need for wiring. The use of CAN in the automotive industry has caused mass production of CAN controllers. Today, CAN controllers are integrated on many microcontrollers and available at a low cost. Figure
DEPARTMENT OF COMPUTER SCIENCEPage 56

Controller Area Network

shows the number of CAN nodes that were sold during 1999–2003.

The number of CAN nodes sold per year is currently about 400 million. (Data from the association CAN in Automation)

Perspectives The development of vehicles is going through a dramatic evolution, in their transition from pure mechanical systems to mechatronic machines with highly integrated hardware and software subsystems. DaimlerChrysler estimates that 90% of the innovations in the automotive area lie in electronics and software. A challenge in the development of vehicular embedded control systems is safety and real-time
DEPARTMENT OF COMPUTER SCIENCEPage 57

Controller Area Network

requirements. The control systems are increasingly being implemented in distributed computer systems and require a multitude of competences to be developed and integrated to meet quality requirements in a cost-efficient way. A major research problem is to develop techniques and tools to bridge the gap between functional requirements and the final design. In this section, we describe two particular trends in the vehicular networked embedded systems, namely, brake-bywire and other x-by-wire systems, and standardized platforms and open-ended architectures for distributed control units in vehicles.

The enhanced Controller Area Network (eCAN) ARCHITECTURE The enhanced Controller Area Network (eCAN) module implemented in the C28x DSP is compatible with the CAN 2.0B standard (active). It uses established protocol to communicate serially with other controllers in electrically noisy environments. With 32 fully configurable mailboxes and time−stamping feature, the eCAN module provides a
DEPARTMENT OF COMPUTER SCIENCEPage 58

Controller Area Network

versatile and robust serial communication interface. This reference guide is applicable for the TMS320x28xx and TMS320x28xxx family of processors. The CAN modules used in these devices are exactly identical to each other. The eCAN module in TMS320x281x devices and the eCAN-A module in TMS320x28xxx devices are mapped to the same address space, with identical register offset addresses. Some devices in the TMS320x28xxx family have a second CAN module, eCAN-B. The word eCAN is generically used to refer to the CAN modules. The specific module reference (A or B) is used where appropriate. Features The eCAN module has the following features: Fully compliant with CAN protocol, version 2.0B  Supports data rates up to 1 Mbps  Thirty−two mailboxes, each with the following properties:  Configurable as receive or transmit  Configurable with standard or extended identifier  Has a programmable acceptance filter mask  Supports data and remote frame  Supports 0 to 8 bytes of data  Uses a 32−bit time stamp on received and transmitted message  Protects against reception of new message


DEPARTMENT OF COMPUTER SCIENCEPage 59

Controller Area Network

 Allows dynamically programmable priority of transmit message  Employs a programmable interrupt scheme with two interrupt levels  Employs a programmable interrupt on transmission or reception time−out  Low−power mode  Programmable wake−up on bus activity  Automatic reply to a remote request message  Automatic retransmission of a frame in case of loss of arbitration or error  32−bit time−stamp counter synchronized by a specific message (communication in conjunction with mailbox 16)  Self−test mode  Operates in a loopback mode receiving its own message. A “dummy” acknowledge is provided, thereby eliminating the need for another node to provide the acknowledge bit. eCAN BLOCK DIAGRAM

DEPARTMENT OF COMPUTER SCIENCEPage 60

Controller Area Network

eCAN Compatibility With Other TI CAN Modules

DEPARTMENT OF COMPUTER SCIENCEPage 61

Controller Area Network

The eCAN module is identical to the “High−end CAN Controller (HECC)” used in the TMS470_ series microcontrollers from Texas Instruments with some minor changes. The eCAN module features several enhancements (such as increased number of mailboxes with individual acceptance masks, time stamping, etc ) over the CAN module featured in 240x series of DSPs. For this reason, code written for 240x CAN modules cannot be directly ported to eCAN. However, eCAN follows the same register bitlayout structure and bit functionality as that of 240x CAN (for registers that exist in both devices) i.e., many registers and bits perform exactly identical functions across these two platforms. This makes code migration a relatively easy task, more so with code written in C language. eCAN Controller Overview The eCAN is a CAN controller with an internal 32−bit architecture.  The eCAN module consists of:  The CAN protocol kernel (CPK)  The message controller comprising:  The memory management unit (MMU), including the CPU interface and the receive control unit (acceptance filtering), and the timer management unit  Mailbox RAM enabling the storage of 32 messages  Control and status registers After the reception of a valid message by the CPK, the receive control unit of the message controller
DEPARTMENT OF COMPUTER SCIENCEPage 62

Controller Area Network

determines if the received message must be stored into one of the 32 message objects of the mailbox RAM. The receive control unit checks the state, the identifier, and the mask of all message objects to determine the appropriate mailbox location. The received message is stored into the first mailbox passing the acceptance filtering. If the receive control unit could not find any mailbox to store the received message, the message is discarded. A message is composed of an 11− or 29−bit identifier, a control field, and up to 8 bytes of data. When a message must be transmitted, the message controller transfers the message into the transmit buffer of the CPK in order to start the message transmission at the next bus−idle state. When more than one message must be transmitted, the message with the highest priority that is ready to be transmitted is transferred into the CPK by the message controller. If two mailboxes have the same priority, then the mailbox with the higher number is transmitted first. The timer management unit comprises a time−stamp counter and apposes a time stamp to all messages received or transmitted. It generates an interrupt when a message has not been received or transmitted during an allowed period of time (time−out). The time−stamping feature is available in eCAN mode only.
DEPARTMENT OF COMPUTER SCIENCEPage 63

Controller Area Network

To initiate a data transfer, the transmission request bit has to be set in the corresponding control register. The entire transmission procedure and possible error handling are then performed without any CPU involvement. If a mailbox has been configured to receive messages, the CPU easily reads its data registers using CPU read instructions. The mailbox may be configured to interrupt the CPU after every successful message transmission or reception. Standard CAN Controller (SCC) Mode The SCC Mode is a reduced functionality mode of the eCAN. Only 16 mailboxes (0 through 15) are available in this mode. The time stamping feature is not available and the number of acceptance masks available is reduced. This mode is selected by default. The SCC mode or the full featured eCAN mode is selected using bit SCB (CANMC.13). Memory Map The eCAN module has two different address segments mapped in the TMS320x28xx memory. The first segment is used to access the control registers, the status registers, the acceptance masks, the time stamp, and the time−out of the message objects. The access to the control and status registers is
DEPARTMENT OF COMPUTER SCIENCEPage 64

Controller Area Network

limited to 32−bit wide accesses. The local acceptance masks, the time stamp registers, and the time−out registers can be accessed 8−bit, 16−bit and 32−bit wide. The second address segment is used to access the mailboxes. This memory range can be accessed 8−bit, 16−bit and 32−bit wide. Each of these two memory blocks, shown in Figure 1−4, uses 512 bytes of address space. The message storage is implemented by a RAM that can be addressed by the CAN controller or the CPU. The CPU controls the CAN controller by modifying the various mailboxes in the RAM or the additional registers. The contents of the various storage elements are used to perform the functions of the acceptance filtering, message transmission, and interrupt handling. The mailbox module in the eCAN provides 32 message mailboxes of 8−byte data length, a 29−bit identifier, and several control bits. Each mailbox can be configured as either transmit or receive. In the eCAN, each mailbox has its individual acceptance mask. Message Objects The eCAN module has 32 different message objects (mailboxes). Each message object can be configured to either transmit or receive. Each message object has its individual acceptance mask. A message object consists of a message mailbox with:  The 29−bit message identifier  The message control register
DEPARTMENT OF COMPUTER SCIENCEPage 65

Controller Area Network

 8 bytes of message data  A 29−bit acceptance mask  A 32−bit time stamp  A 32−bit time−out value Furthermore, corresponding control and status bits located in the registers allow control of the message objects. Message Mailbox The message mailboxes are the RAM area where the CAN messages are actually stored after they are received or before they are transmitted. The CPU may use the RAM area of the message mailboxes that are not used for storing messages as normal memory. Each mailbox contains: ✔ The message identifier ✔ 29 bits for extended identifier ✔ 11 bits for standard identifier ✔ The identifier extension bit, IDE (MSGID.31) ✔ The acceptance mask enable bit, AME (MSGID.30) ✔ The auto answer mode bit, AAM (MSGID.29) ✔ The transmit priority level, TPL (MSGCTRL.12−8) ✔ The remote transmission request bit, RTR (MSGCTRL.4) ✔ The data length code, DLC (MSGCTRL.3−0) ✔ Up to eight bytes for the data field Each of the mailboxes can be configured as one of four message object types Transmit and receive
DEPARTMENT OF COMPUTER SCIENCEPage 66

Controller Area Network

message objects are used for data exchange between one sender and multiple receivers (1 to n communication link), whereas request and reply message objects are used to set up a one−to−one communication link. Transmit Mailbox The CPU stores the data to be transmitted in a mailbox configured as transmit mailbox. After writing the data and the identifier into the RAM, the message is sent if the corresponding TRS[n] bit has been set, provided the mailbox is enabled by setting the corresponding the CANME.n bit. If more than one mailbox is configured as transmit mailbox and more than one corresponding TRS[n] is set, the messages are sent one after another in falling order beginning with the mailbox with the highest priority. In the SCC−compatibility mode, the priority of the mailbox transmission depends on the mailbox number. The highest mailbox number (=15) comprises the highest transmit priority. In the eCAN, the priority of the mailbox transmission depends on the setting of the TPL field in the message control field (MSGCTRL) register. The mailbox with the highest value in the TPL is transmitted first. Only when two mailboxes have the same value in the TPL is the higher numbered mailbox transmitted first.

DEPARTMENT OF COMPUTER SCIENCEPage 67

Controller Area Network

If a transmission fails due to a loss of arbitration or an error, the message transmission will be reattempted. Before reattempting the transmission, the CAN module checks if other transmissions are requested and then transmits the mailbox with the highest priority. Receive Mailbox The identifier of each incoming message is compared to the identifiers held in the receive mailboxes using the appropriate mask. When equality is detected, the received identifier, the control bits, and the data bytes are written into the matching RAM location. At the same time, the corresponding receive−message−pending bit, RMP[n] (RMP.31−0), is set and a receive interrupt is generated if enabled. If no match is detected, the message is not stored. When a message is received, the message controller starts looking for a matching identifier at the mailbox with the highest mailbox number. Mailbox 15 of the eCAN in SCC compatible mode has the highest receive priority; mailbox 31 has the highest receive priority of the eCAN in eCAN mode. RMP[n] (RMP.31−0) has to be reset by the CPU after reading the data. If a second message has been received for this mailbox and the receive message pending bit is already set, the corresponding message−lost bit (RML[n] (RML.31−0)) is set. In this case, the stored message
DEPARTMENT OF COMPUTER SCIENCEPage 68

Controller Area Network

is overwritten with the new data if the overwrite−protection bit OPC[n] (OPC.31−0) is cleared; otherwise, the next mailboxes are checked. If a mailbox is configured as a receive mailbox and the RTR bit is set for it, the mailbox can send a remote frame. Once the remote frame is sent, the TRS bit of the mailbox is cleared by the CAN module. CAN Module Operation in Normal Configuration If the CAN module is being used in normal configuration (i.e., not in self−test mode), there should be at least one more CAN module on the network, configured for the same bit rate. The other CAN module need NOT be configured to actually receive messages from the transmitting node. But, it should be configured for the same bit rate. This is because a transmitting CAN module expects at least one node in the CAN network to acknowledge the proper reception of a transmitted message. Per CAN protocol specification, any CAN node that received a message will acknowledge (unless the acknowledge mechanism has been explicitly turned off), irrespective of whether it has been configured to store the received message or not. The requirement of another node does not exist for the self−test mode (STM). In this mode, a transmitting node generates its own acknowledge signal. The only requirement is that the node be configured for any valid bit−rate. That is, the bit

DEPARTMENT OF COMPUTER SCIENCEPage 69

Controller Area Network

timing registers should not contain a value that is not permitted by the CAN protocol.

DEPARTMENT OF COMPUTER SCIENCEPage 70