Hello, and thanks for checking out this TI Precision Lab on CAN protocol and CAN FD. This lab will discuss how information is encoded and passed between devices on the CAN bus using the ISO 11 898 standard, including arbitration, frame structure, and bit stuffing. We will also introduce CAN with flexible data rate and discuss its benefits in application.

This is the structure of a CAN data frame as outlined in the ISO Standard. Before a frame is transmitted, the bus remains idle at the recessive voltage. The first thing a driver transmits onto the bus is a dominant bit indicating the beginning of transmission. This is called the start of frame bit.

After this bit, the driver begins transmitting the message identifier immediately followed by a remote transmission request bit. These fields are used for message arbitration. The remote transmission request bit determines whether this frame is a data frame, which transmits data, or a request frame, which solicits data from other devices.

The control field specifies the length of data to be transmitted in this message. For data frames, the data is transmitted immediately following the control field. Once the data is sent, a cyclic redundancy check sequence is transmitted that is used to check for errors in transmission. Once the CRC is sent, the driver remains recessive, and the receiver can transmit a dominant bit called the ACK or acknowledge bit to indicate successful message reception. The ACK bit is bounded by a delimiter bit on each side. Once the receiver has acknowledged transmission, the driver sends a seven bit end of frame message followed by a seven bit interframe spacing, which is the minimum time before another frame can be transmitted.

The allocation of priority to messages in the message identifier within a frame is a feature of CAN and CAN FD that makes it particularly attractive for use within a real time control environment. The lower the value of the binary message identifier number, the higher its priority. An identifier consisting entirely of zeros, which would be an entirely dominant identifier, is the highest possible priority message on a network.

In this example, we have two nodes that begin to transmit messages simultaneously. Each of these messages has a unique 11-bit binary message identifier. Remember, the identifier with the lower value is the higher priority. Here, the identifier for node A ha a value of 1,199 while the identifier for node B has a value of 1,530. This means that node A has higher priority between these two messages, and that it should win arbitration. Transceivers must know loop time and propagation delay to ensure proper message arbitration. Check out our TI Precision Lab titled CAN physical layer and hardware to learn more about delay.

Let's take a look at a simplified example of arbitration on the CAN or CAN FD bus. Imagine that we have three nodes that access the same single CAN bus and each simultaneously begins to send a message with message identifiers shown here in gray. During the first bit, all three of these nodes transmit a recessive signal since the first digit of each of their message identifiers is a one. This means that the CAN bus is recessive.

Next, all three of these particular nodes transmit a dominant bit representing the second digit of each of their identifiers. And the CAN bus is dominant. So far, there has been no signal destruction as all three nodes have transmitted the same signal. During the third bit, however, node B transmits a recessive signal. But since at least one of the devices on the network is transmitting a dominant signal, the bus carries a dominant signal. At this point, node B has lost arbitration since another message on the bus has higher priority.

CAN transceivers monitor the bus while driving and compare its state with the state it is driving. If the transceiver transmits a logic one but reads a logic zero, as is the case here for node B, it will immediately stop transmitting. So far, node A and node C have not experienced this. So these two nodes continue their respective transmissions until one of them receives a dominant signal while transmitting a recessive signal.

In this example, node C experiences this at bit seven. At this point, node C has lost arbitration. And it also immediately stops transmitting. Node A, as the only device left transmitting, finishes transmitting its 11-bit message identifier. Since node A sees a matching bus for the entirety of its message identifier, it can continue to transmit the rest of its message since it has won arbitration with the lowest binary identifier value. Nodes B and C will reattempt to transmit their lower priority messages after the next interframe spacing, which will be at the end of node A's transmission.

Let's take a look at a sample CAN frame from beginning to end. When no device is transmitting, the bus remains idle. When a device begins transmission, it sends a single dominant bit to indicate it will begin transmitting. This bit is called the start of frame bit or the SOF bit.

This start of frame bit is always dominant representing a logic zero. This bit is used to synchronize the nodes on a bus after being idle. Immediately after the start of frame bit is the message identifier field or ID field. The standard 11-bit identifier establishes the priority of the message and can indicate the target of the message. This is where arbitration occurs. As we mentioned earlier, the lower the binary value, the higher the message priority. This message has a binary value of 210.

The bit that immediately follows the identifier is the remote transmission request bit or RTR bit, which indicates whether this message is transmitting data packets or requesting data from another device. A dominant zero, as shown here, indicates that this is a data transmission frame. Alternatively, a recessive one would indicate that this message is a request for data from another device also known as a remote frame or a remote transmission request.

The next six bits are called the control field since they provide information about the message being transmitted. The first bit is the identifier extension bit or IDE bit, which indicates the length of the identifier being used in the message. A dominant signal, as shown here, indicates that this message contains an 11-bit identifier, which we showed previously, rather than a 29-bit extended CAN identifier, which would feature 18 additional identifier bits after the IDE. In this example, that is not the case. So the next bit is simply a reserved bit saved for possible use in a future CAN standard.

The last four bits of the control field are the data length code or DLC, which indicate how many bytes of data will be transmitted in this message. This particular DLC indicates that two bytes of data will be transmitted. The number indicated in the DLC must be between zero and eight for traditional CAN, as the maximum number of bytes that can be transmitted in one frame is eight bytes. Remote transmission requests will not have any data, so this field will be zero.

The first byte of data is transmitted immediately following the data length code. Remember bytes transmitted via CAN are transmitted most significant bit first. Subsequent data fields are transmitted in series. Earlier in this example transmission, we indicated that there would be two total bytes of data transmitted.

Once all of our data has been transmitted properly, a 15-bit cyclic redundancy check or CRC is sent, which is used as a means of error detection. The CRC is calculated using all of the bits transmitted in the message so far. If a receiver receives a CRC that does not match what it has calculated, this indicates an error condition.

The recessive CRC delimiter bit follows the 15-bit CRC. Once the transmitter has finished sending its data and redundancy check, the receiver must indicate that it has received the transmitter's message without error. This occurs immediately following the CRC delimiter in the position known as the ACK slot, meaning the acknowledgment slot.

Here, the transmitting node sends a recessive signal. If the receiver has received the message without error, it will override this slot with a dominant signal. Should a receiving node detect an error and leave this bit recessive, it discards the message, and the sending node repeats the message after rearbitration. This slot is immediately followed by a recessive delimiter. Using this important slot, each receiving node acknowledges the integrity of its data.

After acknowledgment, the transmitter sends an end of frame field or EOF field, which marks the end of a CAN message. This is a field of seven sequential recessive bits. After the EOF, the bus will become free, and another message can be sent after a seven bit interframe spacing. No node transmits during this interframe spacing.

An added feature of CAN and CAN FD is bit stuffing. During the transmission of a message, if five consecutive bits of the same polarity are transmitted, then a single bit of opposite polarity is inserted immediately following these bits. For example, this string contains at least five recessive bits in a row. Therefore, the transmitter would insert a dominant bit after the fifth consecutive recessive bit.

In this string, there are at least five dominant bits in a row. Here, the transmitter would insert a recessive bit after the fifth consecutive dominant bit. This third example shows a special case. Note that it starts with five consecutive dominant bits. Following the bit stuffing protocol, the transmitter stuffs a recessive bit immediately following these dominant bits. This stuffed recessive bit, however, has resulted in five consecutive recessive bits since stuffed bits count towards this five bit restriction. Accordingly, the transmitter would also stuff a dominant bit after these five consecutive recessive bits. Stuffed data is automatically destuffed by the receiver.

Let's take a look at the data we just transmitted in our prior simplified example and see if there are any areas where five consecutive identical bits were transmitted. It turns out that this occurred starting at the last bit of the message identifier where a total of six consecutive dominant bits were transmitted. In a real transmission of this data, our transmitter would insert a bit of opposite polarity, in this case, a recessive bit, after the fifth consecutive dominant bit. You may notice that there are numerous consecutive recessive bits at the end of our message as well. Bit stuffing is deactivated after the last bit of the 15-bit CRC. So the ACK slot, its surrounding delimiters, and the end of frame field are fixed size and are not subject to bit stuffing. Since the stuffed bits are automatically removed by the receiver, the stuffed data contains the exact same information as the originally displayed data. Anywhere prior to the CRC delimiter, six consecutive identical bits would constitute an error condition.

There are four types of CAN and CAN FD frames. Let's use this seven node example network to describe these types of interactions. The most common frame type is a data frame, which is used to transmit up to eight bytes of information across the bus. This was the type of frame shown in our prior example CAN message.

Devices can solicit or request data from other devices using a remote frame also known as a remote transmission request. This type of frame is explicitly marked by a recessive RTR bit after the message identifier. It contains no data. Nodes targeted by request frames can respond with a data frame.

If there is an error in the transmission or reception of a message or if any other error condition occurs at a node, that node transmits an error frame. The error frame is a special message that violates the formatting rules of a CAN message by deliberately sending at least six consecutive dominant bits, which would override all signals on the bus. Since this is itself considered an error, all other nodes on the bus send an error frame as well.

The original transmitter will then automatically retransmit the original message. An elaborate system of error counters in the CAN controller ensures that a node cannot tie up a bus by repeatedly transmitting error frames. The last type of frame is an overload frame. This frame is similar to an error frame, but it is sent between frames or during inter-frame spacing rather than during a frame. This is transmitted by a node that becomes too busy, and it provides extra delay between messages by ensuring that the bus is held up until the overload condition is cleared.

CAN with flexible data rate known as CAN FD is an enhancement to the traditional CAN protocol. CAN FD allows for usable bandwidths of up to five megabits per second. How does this happen? As implied by the name, this protocol implements variable data rates within an individual message. Using this method, the protocol allows you to, for example, send the same amount of data in half the original time. Or, alternatively, you could send twice the amount of data in the same original time.

This is possible because the data fields and the CRC bits can be transmitted at higher data rates, while the rest of the fields adhere to traditional CAN speeds. These speeds are different leading to varying data rates within the same message. Benefits of CAN FD include increased overall bandwidth. Not only does CAN FD permit faster data rates, but it also allows up to 64 bytes of data to be transmitted in a single message rather than the original limit of eight bytes imposed by traditional CAN.

CAN FD also features lower relative cost and complexity with a small incremental cost to increase bandwidth and less complexity than implementing major network changes such as flex ray or ethernet. CAN FD also allows for a fast end of line flash programming of modules and ECUs, reducing manufacturing costs. It is important to note that CAN FD is backward compatible to classical CAN. However, original CAN controllers are not forward compatible to CAN FD.

What system components are impacted by CAN FD? The CAN controller within the microcontroller is one. Hardware changes may be limited to the CAN controller in the microcontroller, assuming a data rate above one megabit per second is never used. The CAN controller in the microcontroller or protocol engine must also be updated to the new CAN FD standard. Remember CAN FD controllers are backward compatible, but traditional CAN controllers are not forward compatible.

Original CAN transceivers, cabling, connectors, and protection circuitry, meeting the CAN requirements for one megabit per second, may all be used for CAN FD at up to one megabit per second. Just like that of traditional CAN, the maximum data rate of CAN FD scales down due to long cabling lengths, higher node counts, isolation, or similar loading. When implementing CAN FD at greater than one megabit per second, they physical layer and hardware design may require changes.

Low level drivers for the new CAN controllers on the MCU must be updated to the new register map and longer payload options. And application software must be adapted to handle the longer data payloads. To find more CAN and CAN FD technical resources and to search for CAN and CAN FD products, visit ti.com/CAN. Also, be sure to check out our other TI Precision Labs videos for CAN, LIN, and SBC. Thank you for watching.