How to configure Controller Area Network (CAN) bit timing to achieve optimal system performance?
The Controller Area Network (CAN) provides powerful communication capabilities between multiple network stations, supporting a wide range of data rates and distances. CAN is widely used in industrial, instrumentation, and automotive applications due to its features such as data link layer arbitration, synchronization, and error handling. Protocols such as DeviceNet and CANopen define implementations for the physical and data link layers within the ISO 11898 standard, using distributed multi-master differential signaling and built-in fault handling. This article aims to describe how to optimize the setup for a given application while taking into account hardware limitations such as controller architecture, clocks, transceivers, and isolation of logical interfaces. The article will focus on network configuration issues—including data rates and cable lengths—and explain when it is necessary to reconfigure a CAN node and how to optimize the configuration of the node from the beginning.
For harsh industrial and automotive environments, system robustness can be further enhanced by isolating the logic interface of the CAN transceiver, allowing for large potential differences between ground nodes while providing immunity to high voltage transients. An isolated CAN node can be formed by integrating a CAN transceiver with a digital isolator. The ADM3052, ADM3053, and ADM3054 isolated CAN transceivers offer a variety of interface powering options. For DeviceNet networks, the isolated side can be powered by the bus; therefore, the ADM3052 integrates a linear regulator to provide a 5 V supply from the 24 V bus supply. The ADM3053 (shown in Figure 1) integrates an isoPower dc-to-dc converter to drive the bus side of the transceiver and digital isolator. Systems that already have an isolated dc-to-dc converter capable of providing power across the isolation barrier can use the ADM3054, which only integrates the digital isolator and CAN transceiver.
Deploying a CAN node requires an isolated or non-isolated CAN transceiver and a CAN controller or processor with the appropriate protocol stack. Standalone CAN controllers can be used, or even controllers without a standard protocol stack, but microprocessors used in CAN applications may already include a CAN controller. In either case, the CAN controller must be configured to coordinate the data rate and timing on the bus, and a hardware oscillator is used for the controller.
As the cable length increases, the high frequency components of the signal are attenuated, so the data rate is limited over long distances. The bus is multi-master, so all nodes can attempt to transmit simultaneously, and arbitration depends on physical layer signaling. Propagation delays also increase with cable length, which can interfere with synchronization and arbitration between nodes.
The differential signal on the CAN bus can be in one of two states: active (logic 0, a differential voltage between the signal lines CANH and CANL) or passive (logic 1, no differential voltage, all CAN transceiver outputs are high impedance). If two nodes try to transmit at the same time, the active bit transmission will overwrite the simultaneous passive bit transmission, so all nodes must monitor the bus state when transmitting and stop transmitting if an overwrite occurs when transmitting a passive bit. In this way, the node transmitting the active bit wins the arbitration, as shown in Figure 2.
CAN 2.0b defines how the data link layer is implemented and specifies the CAN frame structure used for transmission. An arbitration field containing a message ID starts the message transmission. Lower message IDs (more leading zeros) will have a higher priority, so the corresponding node has a greater probability of winning arbitration when transmitting a message.
Although CAN nodes are synchronized to the bus transmission, they are not completely synchronized due to the propagation delay between two nodes transmitting at the same time. For arbitration to work effectively, the propagation delay cannot be too large, otherwise the faster node may sample the bus before detecting the bit state transmitted by the slower node. The worst-case propagation delay is twice the delay between the two farthest nodes. In Figure 3, if nodes A and B are the farthest nodes on the bus, the critical parameter is the sum of the round-trip propagation time PropBA and TPropBA.
The total propagation delay consists of the round-trip propagation time through the cable, the two CAN controller I/Os, and the two CAN transceivers. The CAN controller I/Os are not a major contributor to the propagation delay and can often be ignored, but must be considered for a thorough evaluation. The cycle time consists of the propagation delay from TxD to CANH/CANL and back to RxD. The cable propagation delay depends on the cable and distance, with a typical value of 5 ns/m.
At lower data rates, the allowed bit time is longer, so the propagation delay (and therefore the cable distance) may also be longer. At the highest standard CAN data rate (i.e. 1 Mbps), the allowed propagation delay is more limited, although the ISO 11898-2 standard specifies that a data rate of 1 Mbps can be supported with a bus length of 40 meters.
In isolated conditions, additional factors must be considered when calculating the bidirectional propagation delay. Digital isolators reduce the propagation delay compared to optocouplers, but even the fastest isolated CAN transceivers are comparable to slower non-isolated transceivers in this respect. If the total allowed propagation delay remains the same, the maximum cable length is shorter in an isolated system, but the CAN controller can be reconfigured to increase the total allowed propagation delay.
To compensate for the added propagation delays due to longer buses or isolation, specific parameters related to timing and synchronization must be set for the CAN controller. When configuring the controller, you do not simply select a data rate, but rather set variables that determine the bit time used by the controller. The baud rate prescaler (BRP) for the oscillator or internal clock sets the time quantum (TQ), and the bit time is a multiple of the TQ. The hardware selection of the oscillator, and the software configuration of the BRP and the number of TQs per bit time set the data rate.
The controller's bit time is divided into three or four time segments, as shown in Figure 3. The total TQ per bit time includes a synchronization and a set number of propagation delays (PROP), phase segments 1 (PS1), and phase segments 2 (PS2). Sometimes, PROP and PS1 are added together. The configuration adjusts the sampling point to allow for propagation delays and resynchronization.
Placing the sample point later in the bit time can accommodate longer propagation delays, but like the overall data rate, the sample point depends on other timing variables, which have their own limitations. For example, the internal clock/oscillator may be fixed and only integer BRP and TQ numbers can be used. Therefore, the ideal data rate required for a specific cable length may not be achievable at all, so the cable must be shortened or the data rate must be reduced.
Resynchronization will lengthen PS1 and shorten PS2 by the number of TQs specified by the synchronization jump width (SJW). Therefore, PS2 must not be shorter than SJW. The number of TQs required for SJW depends on the clock tolerance of the CAN controller. For SJW and PS2, the crystal oscillator generally supports the minimum number of TQs.
In order to achieve a robust network with reliable timing and synchronization between nodes, the system must be able to tolerate the propagation delays at the selected data rate and CAN controller clock. If this is not possible, options include reducing the data rate, shortening the bus, or using a different CAN controller clock rate. The configuration process consists of the following three steps.
Step 1: Check the clock and prescaler - match the data rate
First check what configurations are possible given the target data rate and CAN controller clock. The TQ interval must be calculated based on the clock and various BRP values, and the possible combinations are only those where the TQ interval is an integer multiple of the bit time. Other CAN controller clock rates may also be considered, depending on the stage of system design. In the calculation example shown in Table 1, a maximum data rate of 1 Mbps is given, using a Microchip® MCP2515 standalone CAN controller and an ADSP-BF548 Blackfin processor with an internal CAN controller. The MCP2515 fOSC depends on the external hardware oscillator used, while the ADSP-BF548 fSCLK depends on the hardware CLKIN and internal PLL settings (CLKIN multiplier for VCO, VCO divider for SCLK). Only certain combinations of CAN controller clock and BRP (integer TQ) support a data rate of 1 Mbps, as shown in bold. This limits the bit timing settings, so once a bus data rate is selected, only a few options are available.
Table 1. TQ numbers at 1 Mbps for given f and BRP
Step 2: Determine the bit segment configuration
The next step is to determine the number of TQs required for each bit segment. The most difficult case is to support the maximum propagation delay at a data rate of 1 Mbps, for example, a 40-meter cable length and an isolated node. Ideally, the bit time segment should be configured so that the sampling point is as late as possible in the bit. In Table 1, for each integer total number of TQs, one TQ must be provided for the SYNC segment, and the PS2 (or TSEG2) segment must be large enough to accommodate the CAN controller information processing time (2 TQs for MCP2515 and less than 1 TQ for ADSP-BF548 as long as BRP is greater than 4). In addition, PROP and PS1 can have up to 8 TQs each for the MCP2515 and up to 16 TQs for the ADSP-BF548.
Figures 4 and 5 show possible total TQ configurations for the MCP2515 and ADSP-BF548, respectively, to support the closest sample point for valid clock and BRP combinations at 1 Mbps. The optimal total TQ for the MCP2515 is 19, requiring a 38 MHz hardware oscillator and a BRP of 1. For the ADSP-BF548, all configurations are at least 85% sample point except for the total TQ of 5, but the optimal setting is 10 TQ, requiring fSCLK = 50 MHz and BRP = 5.
Step 3: Match transceiver/isolation delays and bus lengths to your configuration
After helping the CAN controller achieve the best sampling point, the last step is to compare the allowed propagation delay with the CAN transceiver/isolator used and the bus length. Assuming the ADSP-BF548 is optimally configured for 10 TQ (fSCLK = 50 MHz, BRP = 5), the maximum achievable propagation delay is 900 ns. For the ADM3053 isolated CAN transceiver with integrated isolated power supply, the maximum loop delay (TxD off, receiver inactive) in the data sheet is 250 ns. It must be doubled (500 ns) to support both the transmit and receive delays at the two nodes at the farthest ends of the bus.
Assuming a cable propagation delay of 5 ns/m, the ADSP-BF548 can support a bus length of 40 meters (maximum at 1 Mbps according to the ISO 11898 specification), with a total bit time of 10 TQ for the ADSP-BF548 and only 1 TQ for the TSEG2 bit segment. In practice, a slightly earlier sampling point is sufficient, since extreme transceiver propagation delays at one node may even result in a simple retransmission (automatically handled by the data link layer CAN controller), but, due to the small delay between the CAN controller I/O and the CAN transceiver, it is recommended to configure the sampling point as late as possible.
Isolation improves robustness but also increases the propagation delay in both transmit and receive directions. This delay must be doubled to allow two nodes to participate in arbitration. If the propagation delay allowed in the system is fixed, the cable length or data rate can be reduced after adding isolation. Another approach is to reconfigure the CAN controller to support the maximum propagation delay to ensure that the required data rate and bus length are supported, even when the nodes are isolated.
????Click here to explore the ADI "chip" world