Professional Documents
Culture Documents
3.5 Can Protocol: Floor, Eureka Court, Beside Image Hospital, Ameerpet, HYDERABAD 73
3.5 Can Protocol: Floor, Eureka Court, Beside Image Hospital, Ameerpet, HYDERABAD 73
5 CAN PROTOCOL
3.5.1 INTRODUCTION:
Controller Area Network (CAN) was initially created by German automotive
system supplier Robert Bosch in the mid-1980s for automotive applications as a method
for enabling robust serial communication. The goal was to make automobiles more
reliable, safe and fuel-efficient while decreasing wiring harness weight and complexity.
Since its inception, the CAN protocol has gained widespread popularity in industrial
automation and automotive/truck applications. Other markets where networked solutions
can bring attractive benefits like medical equipment, test equipment and mobile machines
are also starting to utilize the benefits of CAN, the goal of this application note is to
explain some of the basics of CAN and show the benefits of choosing CAN for
embedded systems networked applications.
Bus access conflicts are resolved by bit-wise arbitration of the identifiers involved
by each station observing the bus level bit for bit. This happens in accordance with the
wired-and- mechanism, by which the dominant state overwrites the recessive state. All
those stations (nodes) with recessive transmission and dominant observation lose the
competition for bus access. All those "losers" automatically become receivers of the
message with the highest priority and do not re-attempt transmission until the bus is
available again.
Transmission requests are handled in order of their importance for the system as a
whole. This proves especially advantageous in overload situations. Since bus access is
prioritized on the basis of the messages, it is possible to guarantee low individual latency
times in real-time systems.
The CAN protocol supports two message frame formats, the only essential difference
being in the length of the identifier. The “CAN base frame” supports a length of 11 bits
for the identifier, and the “CAN extended frame” supports a length of 29 bits for the
identifier.
The difference between an extended frame format message and a base frame
format message is the length of the identifier used. The 29-bit identifier is made up of the
11-bit identifier (“base identifier”) and an 18-bit extension (“identifier extension”). The
distinction between CAN base frame format and CAN extended frame format is made by
using the IDE bit, which is transmitted as dominant in case of an 11-bit frame, and
transmitted as recessive in case of a 29-bit frame. As the two formats have to co-exist on
one bus, it is laid down which message has higher priority on the bus in the case of bus
access collision with different formats and the same identifier / base identifier: The 11-bit
message always has priority over the 29-bit message. The extended format has some
trade-offs: The bus latency time is longer (in minimum 20 bit- times), messages in
extended format require more bandwidth (about 20 %), and the error detection
performance is lower (because the chosen polynomial for the 15-bit CRC is optimized for
frame length up to 112 bits).
CAN controllers, which support extended frame format messages are also able to
send and receive messages in CAN base frame format. CAN controllers that just cover
the base frame format do not interpret extended frames correctly. However there are
CAN controllers, which only support the base frame format but recognize extended
messages and ignore them. Detecting and signaling errors Unlike other bus systems, the
CAN protocol does not use acknowledgement messages but instead signals errors
immediately as they occur. For error detection the CAN protocol implements three
mechanisms at the message level (data link layer: OSI layer 2):
• Cyclic Redundancy Check (CRC): The CRC safeguards the information in the frame by
adding a frame check sequence (FCS) at the transmission end. At the receiver this FCS is
• Frame check: This mechanism verifies the structure of the transmitted frame by
checking the bit fields against the fixed format and the frame size. Errors detected by
frame checks are designated "format errors".
• ACK errors: Receivers of a message acknowledge the received frames. If the transmitter
does not receive an acknowledgement an ACK error is indicated.
The CAN protocol also implements two mechanisms for error detection at the bit level
(physical layer: OSI layer 1):
• Monitoring: The ability of the transmitter to detect errors is based on the monitoring of
Bus signals. Each station that transmits also observes the bus level and thus detects
differences between the bit sent and the bit received. This permits reliable detection of
Global errors and errors local to the transmitter.
• Bit stuffing: The coding of the individual bits is tested at bit level. The bit
representation used by CAN is "Non Return to Zero (NRZ)" coding. The synchronization
edges are generated by means of bit stuffing. That means after five consecutive equal bits
the transmitter inserts a stuff bit into the bit stream. This stuff bit has a complementary
value, which is removed by the receivers. If one or more errors are discovered by at least
one station using the above mechanisms, the current transmission is aborted by sending
an "error frame". This prevents other stations from accepting the message and thus
ensures the consistency of data throughout the network. After transmission of an
erroneous message that has been aborted, the sender automatically re-attempts
transmission (automatic re-transmission). Nodes may again compete for bus access.
However effective and efficient the method described may be, in the event of a
defective station it might lead to all messages (including correct ones) being aborted. If
CAN Overview:
1. Flexible :
* Fully customizable data flow management - wire up your CAN data however you
want, load and modify the CAN database, and connect or disconnect functional blocks
without ever having to stop the "live" capture.
* Connect multiple ECOM devices in the CAN flow chart to create virtual gateways
that can bridge, manipulate, filter, and analyze activity between isolated buses.
2. Powerful:
* Custom scripting allows for everything from end-of-line testing procedures to on-
the-fly data encryption/decryption. Implement advanced filters beyond the capabilities of
the standard packet filter by using the C/C++ like syntax. Plenty of examples are
available.
Because CAN was initially designed for use in automobiles, a protocol that efficiently
handled errors was critical if it was to gain market acceptance. With the
release of version 2.0B of the CAN specification, the maximum communication rate was
increased 8x over the version 1.0 specification to 1Mbit/sec. At this rate, even the most
time-critical parameters can be transmitted serially without latency concerns. In addition
to this, the CAN protocol has a comprehensive list of errors it can detect that ensures the
integrity of messages.
CAN nodes have the ability to determine fault conditions and transition to
different modes based on the severity of problems being encountered. They also have the
Based on the severity of the errors detected this feature is called Fault
Confinement. No faulty CAN node or nodes will be able to monopolize all of the
bandwidth on the network because faults will be confined to the faulty nodes and these
faulty nodes will shut off before bringing the network down. This is very powerful
because Fault Confinement guarantees bandwidth for critical system information. There
are five error conditions that are defined in the CAN protocol and three error states that a
node can be in, based upon the type and number of error conditions detected.
* Record data in the field, and then replay and analyze it later with full or variable
speed playback. Let your clients log the data and/or go back and analyze a recorded
session with different variables being watched or graphed. Alternately, log data packets
or variable watches to excel for in-depth post-analysis
* Create standalone EXE files custom built from any CAN capture configuration for
distributing to
3.5Errors Detected:
1. CRC Error :
In the Acknowledge Field of a message, the transmitting node checks if the Acknowledge
Slot (which it has sent as a recessive bit) contains a dominant bit. This dominant bit
would acknowledge that at least one node correctly received the message. If this bit is
recessive, then no node received the message properly. An Acknowledge Error has
occurred. An Error Frame is then generated and the original message will be repeated
after a proper intermission time.
Form Error :
If any node detects a dominant bit in one of the following four segments of the message:
End of Frame, Interframe Space, Acknowledge Delimiter or CRC Delimiter, the CAN
protocol defines this to be a form violation and a Form Error is generated. The original
message is then resent after a proper intermission time. (see Figure 2 and/or Figure 3 for
where these segments lie in a CAN message).
Bit Error :
A Bit Error occurs if a transmitter sends a dominant bit and detects a recessive bit, or if it
sends a recessive bit and detects a dominant bit when monitoring the actual bus level and
comparing it to the bit that it has just sent. In the case where the transmitter sends a
recessive bit and a dominant bit is detected during the Arbitration Field or Acknowledge
Slot, no Bit Error is generated because normal arbitration or acknowledgment is
occurring. If a Bit Error is detected, an Error Frame is generated and the original message
is resent after a proper intermission time.
Stuff Error:
CAN protocol uses a Non-Return–to-Zero (NRZ) transmission method. This means that
the bit level is placed on the bus for the entire bit time. CAN is also asynchronous, and bit
stuffing is used to allow receiving nodes to synchronize by recovering clock information
from the data stream. Receiving nodes synchronize on recessive to dominant transitions.
www.mycollegeproject.com Ph: +91 9490219339, 040-23731030
Ameerpet: A-8, 2nd floor, Eureka court, beside Image hospital, Ameerpet, HYDERABAD 73.
Santoshnagar: Opp: Magna Hypermarket, Santoshnagar X-Roads, HYDERABAD – 59.
If there are more than five bits of the same polarity in a row, CAN automatically stuff an
opposite polarity bit in the data stream. The receiving node(s) will use it for
synchronization, but will ignore the stuff bit for data purposes. If, between the Start of
Frame and the CRC Delimiter, six consecutive bits with the same polarity are detected,
then the bit stuffing rule has been violated. A Stuff Error then occurs, an Error Frame is
sent, and the message is repeated.
3.6 CONCLUSION
The CAN protocol was optimized for systems that need to transmit and receive
relatively small amounts of information (as compared to Ethernet or USB, which are
designed to move much larger blocks of data) reliably to any or all other nodes on the
network. CSMA/ CD allows every node to have an equal chance to gain access to the
bus, and allows for smooth handling of collisions. Since the protocol is message-based,
not address based, all messages on the bus receive every message and acknowledge every
message, regardless of whether in needs the data or not. This allows the bus to operate in
node-to-node or multicast messaging formats without having to send different types of
messages. Fast, robust message transmission with fault confinement is also a big plus for
CAN because faulty nodes will automatically drop off the bus not allowing any one node
from bringing a network down. This effectively guarantees that bandwidth will always be
available for critical messages to be transmitted. With all of these benefits built into the
CAN protocol and its momentum in the automotive world, other markets will begin to
see and implement CAN into their systems.
FEATURES:
PIN DIAGRAM
DEVICE OVERVIEW
The MCP2561/2 is a high-speed CAN, fault-tolerant device that serves as the
interface between a CAN Protocol controller and the physical bus. The MCP2561/2
device provides differential transmit and receive capability for the CAN protocol
controller, and is fully compatible with the ISO-11898-5 standard. It will operate at
speeds of up to 1 Mb/s.Typically, each node in a CAN system must have a device to
convert the digital signals generated by a CAN controller to signals suitable for