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

DEPARTMENT OF COMPUTER SCIENCE


1983 Start of the Bosch internal project to develop an In vehicle network.

1986 Official introduction of CAN protocol

1987 First CAN controller chips from Intel and Philips semiconductors.

1991 Bosch’s CAN specification 2.0 published.

1991 CAN kingdom CAN based higher layer protocol Introduced by Kvaser.

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

1992 CAN application layer (CAL) protocol Published by CiA.

1992 First car’s from Mercedes Benz used CAN Network.

1993 ISO 11898 standard published.

1994 First international CAN conference (iCC)



Organized by CiA.

1994 Device net protocol introduction by Allen Bradley.

1995 ISO 11898 amendment (Extended Frame Format) published.

1995 CAN open protocol published by CiA.

2000 Development of the Time triggered Communication protocol for CAN (TTCAN).



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 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.

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

Agricultural machineryDEPARTMENT OF COMPUTER SCIENCE


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 above-mentioned 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 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


http://www.can-cia.de/


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 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 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). 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 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 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.

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:

- 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.

- 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. DEPARTMENT OF COMPUTER SCIENCE


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 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 outgoingmessages 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 thecorresponding 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.



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 calledmessage 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 whichare 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 Full-CAN controller with the corresponding Data Frame. In 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:

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 modelDEPARTMENT OF COMPUTER SCIENCE


ISO7498 defines a communications standard known as the Open Systems Interconnection (OSI) model. This model describes how communications should 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

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 Data-Link Layer but which may be implemented at the Application Layer. For example, the transmission or DEPARTMENT OF COMPUTER SCIENCE


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):

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 DS-301. 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 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 SCIENCE

http://www.kvaser.se/

http://www.kvaser.se/

http://content.honeywell.com/sensing/prodinfo/sds/

http://content.honeywell.com/sensing/prodinfo/sds/

http://www.nmea.org/pub/2000/index.html

http://www.odva.org/


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 receivedCRC sequence, then a CRC error has occurred.Node B discards the message and transmits an Error Frame to request retransmission of the garbled frame.

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

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 theAcknowledge 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.



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 erroroccurs 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.



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 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 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.



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.



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.

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.

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 non-overlapping time segments as shown below.

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 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.

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 Start-of-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).

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)



CONTROLLER AREA NETWORK (CAN) PROTOCOL

The Controller Area Network (CAN) protocol,developed by ROBERT BOSCH GmbH, offers acomprehensive solution to managing communicationbetween multiple CPUs. The CAN protocol specifiesversatile message identifiers that can be mapped to specific.

Control information categories. Communicationsmay occur at a maximum recommended rate of 1Mbit/sec (roughly a 40 meter bus length). The protocolhas found wide acceptance in automotive in-vehicleapplications as well as many non-automotive due toits low cost, high performance, and the availability ofvarious CAN protocol implementations.

In-vehicle networking protocols must satisfy unique requirements not present in other networking protocolssuch as those found in telecommunications and dataprocessing. These requirements include a high level of



error detection, low latency times and configurationflexibility.

The CAN protocol provides four primary benefits.First, a standard communications protocol simplifiesand economizes the task of interfacing subsystems fromvarious vendors onto a common network. Second, thecommunications burden is shifted from the host-CPUto an intelligent peripheral; the host-CPU has moretime to run its system tasks. Third, as a multiplexednetwork, CAN greatly reduces wire harness size andeliminates point-to-point wiring. Lastly, as a standardprotocol, CAN has broad market appeal which motivatessemiconductor makers to develop competitively pricedCAN devices.

An example of an application well-served by the CANprotocol is automotive networking because many modulesare inter-dependent. Sub-systems such as the engine,transmission, anti-lock braking, and accidentavoidance systems require the exchange of particularperformance and position information within a definedcommunications latency. The engine transmits engine



speed and acceleration parameters to the transmissionto allow smoother shifting. Perhaps the transmissionrequests the engine to reduce fuel injection before agear change.

CAN is a CSMA/CD-A, or Carrier Sense Multiple Accessby 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 CyclicalRedundancy Check (CRC), provide a high level of dataintegrity. For information on the CAN protocol, pleaseread the CAN Specification, Version 2.0.

The CAN 2.0 protocol was chosen by the SAE Truck &Bus Control and Communications Network Subcommitteeof the Truck & Bus Electrical Committee to supportits ``Recommended Practice for Serial Control andCommunciations Vehicle Network CLASS C'' calledthe SAE J1939 specification. The SAE CLASS C passenger car subcommittee is currently evaluating CAN,which is a candidate for its high speed networks. Productsusing CAN Version 2.0 are already in production.The previous CAN specification, Version 1.2, has been



successfully implemented in passenger car, train andfactory automation applications since 1989. CAN Version2.0, which features an ``extended frame'' with a 29-bit message identifier, broadens the application base forthis protocol by allowing J1850 message schemes to bemapped into the CAN message format.

The Intel 82526 was the first implementation of theCAN protocol, in production since 1989. The Intel82527 is a follow-on to the 82526 which implementsCAN Version 2.0, provides greater message handlingcapability and implements a more flexible interface toCPUs.



Vehicle Applications ofController Area Network

Introduction

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 modularizefunctionalities 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. Introducingnetworks in vehicles also make it possible to more efficiently carry out diagnostics and to coordinate the operation of the separate subsystems.

Protocol extensions



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 todefine 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 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 truck-and-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 definesthe 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 certain special functions (e.g., time stamp and synchronizationmessages).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 token-passing 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 ECUin 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.

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 the complex inter-connected network can be hard to predict even if theindividual networks are predictable. Ethernet (or rather Ethernet/IP) is quite a different communication protocolcompared 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 longdistances 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 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 sampled-data 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 11898-4 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 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 anattitude 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 leftfigure 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 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 thedriver 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 thelateral force for this wheel. The central components ofVDC 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.)

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 fromthe launcher, the thrusting phases on the orbit to the moon, and the moon observation phase.

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:DEPARTMENT OF COMPUTER SCIENCE


• 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 forsmaller angles. Both controllers use the reaction wheels as actuators and the sun tracker as sensor. The spacecraft rotation is controlled using a PI controller. When the angular velocity of the reaction wheels exceeds aCertain 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 thereaction 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 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 requirements. The control systems are increasingly being implemented in distributed computer systems and require a multitude ofcompetences to be developed and integrated to meet quality requirements in a cost-efficient way. A major research problem is to develop techniques andtools 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-by-wire 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 versatile and robust serial communication interface. This reference guide is applicable for the TMS320x28xx and TMS320x28xxxfamily 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 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



eCAN Compatibility With Other TI CAN Modules

The eCAN module is identical to the “High−end CAN Controller (HECC)” used in the TMS470_ series microcontrollers from Texas Instruments with someminor 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 bit-layout structure and bitfunctionality 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 registersAfter the reception of a valid message by the CPK, the receive control unit of the message controller determines if the received message must be stored into one of the 32 message objects of the mailbox RAM. The receive controlunit checks the state, the identifier, and the mask of all message objects to determine the appropriate mailbox location. The received message is stored intothe 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 interruptwhen a message has not been received or transmitted during an allowed period of time (time−out). The time−stamping feature is available in eCANmode only.

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 amailbox has been configured to receive messages, the CPU easily reads its data registers using CPU read instructions. The mailbox may be configured tointerrupt 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 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−bitand 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 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 usedfor 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 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.

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 notstored.

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; mailbox31 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 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 timing registers should not contain a value that is not permitted by the CAN protocol.


the controller area network

Documents