Successful communication between devices is key to having a properly functioning embedded system. Embedded systems rely on and function using protocols, or a set of rules that govern the transmission, synchronization, and error checking of data sent and received between devices. Because the protocol is an essential component to a working embedded system, it is crucial that it operates properly. Because communication errors do occur, many protocols, including USB, CAN, and A2B, include error checking mechanisms such as a Cyclic Redundancy Check, or a CRC.
A CRC is used to flag corrupt data and prevent it from being sent over the bus. With today’s protocols often supporting higher bandwidths and speeds, the CRC is fundamental to keeping data clean and reliable within an embedded system. In this article, we’ll cover the different ways the CRC is used in various protocols and how Total Phase tools help spot communication errors in such events.
CRC in Communication Protocols
Communications protocols often use two CRCs in a packet - one to protect the header of the packet and another to protect the data portion of the packet. While the implementation of the CRC varies between protocols, the purpose remains the same – to create a method for the system to detect errors and initiate a request to retransmit the data or ignore it.
How does the CRC get generated and how does it work? It is all based on an algorithmic calculation that is used to detect inconsistencies between the data being transmitted and received. Essentially, the CRC is a value calculated from a number of data bytes to form a unique polynomial key which is appended to the outgoing message. The same process is performed on the receiving end. The receiver then divides the message by the same polynomial the transmitter used and if the result of this division is zero, then the transmission was successful. However, if the result is not equal to zero, this would indicate that an error occurred.
CRC in the USB Protocol
The USB protocol, or Universal Serial Bus, uses Cyclical Redundancy Checks during transmission to protect all non-PID fields in token and data packets from errors. In USB 2.0, the token and start-of-frame (SOF) packets include a 5-bit CRC (CRC5), while the data packet includes a longer 16-bit CRC (CRC16) to provide adequate support for data payloads reaching up to 1024 bytes.
In USB 3.1 packets, the CRC can be found in the header packet, which consists of the header packet framing, packet header, and link control word. The header is protected by a 16-bit CRC (CRC16) and the link control word is protected by a 5-bit CRC (CRC5). The Data Payload Packet includes a 32-bit CRC (CRC32) to accommodate the large data payloads. Additionally, the Link Command Packets that are used to control various link-specific features also include a 5-bit CRC (CRC5).
USB 2.0 data packet including a 16-bit CRC
USB 2.0 Start-of-Frame packet including a 5-bit CRC
USB 2.0 token packet including a 5-bit CRCCRC in the CAN Protocol
The CAN protocol, or Controller Area Network, is known for its robust and reliable communication, as it contains multiple error checking mechanisms, including bit error detection, format error detection, fill error detection, response error detection, and CRC error detection. The CRC fields are contained within the data and remote frames.
The CRC error detection works by including a 15-bit CRC in the data frame to verify that messages are properly sent over the bus. Like discussed previously on how CRC operates, the transmitting node calculates a 15-bit CRC value and then transmits this value in the CRC field. All nodes will receive this message, calculate a CRC reciprocally, and compare the values to determine if they are indeed the same. If not, the receiving nodes will send an Error Frame over the bus. Additionally, the CAN protocol includes a recessive CRC Delimiter at 1-bit which helps prevent form errors and ensures that the bits are properly broadcasted on the bus and received correctly on the receiving end.
CRC in the A2B Protocol
The A2B protocol, or Automotive Audio Bus, is another protocol that uses error checking mechanisms to verify proper communication. One of the measures includes CRC that is used within specific frames to help detect errors over the bus.
A2B Superframe including Synchronization Control and Response FramesThe Synchronization Control Frame (SCF) acts as the control frame for nodes, or the control header, and the Synchronization Response Frame (SRF) acts as the response frames from nodes, or the response header. The entire A2B frame structure is known as a Superframe, which starts with an SCF, includes optional data slots, and ends with an SRF. These frames both include cyclic redundant codes (CRC) to help detect upstream and downstream data errors.
For the downstream data error detection, a 16-bit CRC is used within the SCF where it determines any SCF data errors occurring during transmission on the receiving side. The SCF includes a preamble that indicates the start of a Superframe and provides a bit pattern used by slaves for clock and frame synchronization. If the slave does not detect a frame sync, the slave will indicate a CRC error.
For the upstream data error detection, a 16-bit CRC is also used within the SRF to determine any SRF data errors occurring during transmission on the receiving side. The interrupt request fields have an additional CRC inside the SCF to avert false interrupts from being triggered. The SRF also has a preamble to indicate the start of a response frame, and provides a bit pattern used by upstream nodes for clock and frame synchronization. If the upstream node does not detect the frame sync, CRC errors will be indicated.
Detecting CRC Errors with Total Phase Tools
Total Phase offers numerous debugging tools for I2C, SPI, USB, CAN, eSPI, and A2B protocols that can be used in conjunction with the Data Center Software to capture, decode, and analyze data occurring on the bus in true real time. The USB, CAN, and A2B protocols that incorporate Cyclic Redundancy Checks can benefit from our tools to capture and analyze data and bus errors in a variety of ways.
Our line of Beagle USB protocol analyzers, Komodo CAN Interfaces and the A2B Bus Monitor used in conjunction with the Data Center Software allows users to detect, flag, and filter data errors, making it easy to evaluate errors detected by CRC.
The Data Center Software also incorporates numerous ways to interact with USB data specifically, including performing advanced triggers using USB CRC conditions. Depending on the Beagle USB Protocol Analyzer tool, users can perform simple and complex USB 2.0 and USB 3.0 triggers. Simple triggers for USB 2.0 and USB 3.0 can trigger on high-level packet types (including header packets, data payload packets), data patterns, and CRC errors, while complex triggers for USB 2.0 and allow users to match on specific state-based transactions, errors, events, and timers. Complex triggers for USB 3.0 include triggering on a specific packet type or data pattern, in addition to bus events and timers.
Below are examples of the Complex Data Match Configurations for USB 2.0 and USB 3.0 data that are based on Error Packet Types.
 USB 2.0 Error Match Action Unit |
 USB 3.0 Error Data Match Action Unit |
This allows users to match on any packet type which exhibits an error. For USB 2.0, this can match on specific error types on any packet that appears on the bus, including matching criteria include CRC errors, corrupted PIDs, jabber, and general PHY receive errors. For USB 3.0, the errors which can be matched are a CRC error, framing error, or any unknown packet.
For more information on how our tools can help analyze data and bus errors, including CRC errors, please contact us at sales@totalphase.com.