That afternoon, I was sitting in the passenger seat as the car just left the industrial park, traveling at a speed of only 30 km/h, while the engineer was still debugging the autonomous driving test code. The entire vehicle had over 20 nodes connected to the CAN bus, including the main control unit, radar, power, and safety redundancy systems, all relying on CAN communication.
Then, the incident occurred—not a collision, but a near miss.
The car suddenly “froze,” as if it had become stiff. The steering assist failed, the electronic brakes were delayed, the dashboard went black, and all status lights turned on. The engineer’s first reaction was to disconnect the main control power and use the handbrake to slide to a stop.
We all turned pale: this was not a software bug; this was a complete disconnection of the vehicle’s CAN network, and it was a simultaneous failure of all nodes.
We got out of the car to reproduce the issue, and sure enough, everything returned to normal after a restart. However, once the speed increased and node communication became denser, the CAN bus began to experience a “cascading node failure.” The first to drop was the main control unit, followed by the radar, then the power module, and finally all nodes went Bus-Off.
This is the most dangerous state machine cascade in the CAN protocol: one node frequently fails to send, enters Error-Passive, and if it continues to fail, it goes Bus-Off, completely disconnecting. Other nodes that do not receive ACK also begin to enter error counting, causing the entire network to collapse like a domino effect.
We hurried back to the lab to capture the CAN bus waveform. The waveform looked clean, with no obvious interference and no dominant/recessive level anomalies. However, we noticed one detail:
Several nodes had ACK edges that were slightly “slow,” delayed by about 1 to 1.5 microseconds.
Normal CAN communication requires the sampling point to be at a moderate position within each bit period, typically around 75% of the Bit Time, meaning that TS1 + TS2 must be well managed to ensure the sampling point falls within a stable region.
Our system was running at 500 kbps, with a Bit Time of 2 μs. If the sampling point deviation exceeds a few hundred nanoseconds, it could miss the ACK confirmation, leading to an increase in error counts.
We began to suspect whether some nodes had inconsistent bit timing configurations. Sure enough, one main control device (using the STM32F407) had the following CAN timing configuration:
Prescaler = 3
BS1 = 12
BS2 = 1
While other nodes (using TCAN chips) were configured as follows:
Prescaler = 4
BS1 = 11
BS2 = 2
They looked similar, but when converted to sampling point positions, they differed by nearly 1 μs.
This explained why the main control unit kept dropping: its sampling point was too early, while the other nodes’ ACKs were delayed, causing it to misjudge “no response,” leading to a surge in error counts and entering Bus-Off. Once it dropped, other nodes also lost ACK and began to drop, causing the entire network to collapse.
We immediately unified the CAN bit timing for all nodes, choosing:
- BRP = 4
- TS1 = 13
- TS2 = 2
This way, the sampling point fell exactly at 87.5% of the Bit Time, which is most friendly to the ACK signal and provides the maximum fault tolerance.
At the same time, we enabled CAN Silent Mode + Loopback mode on the main control unit, adding a self-check mechanism: once it detected entering Error-Passive, it would immediately switch to Silent mode to avoid sending interference to other nodes and record detailed error frame counts for subsequent diagnosis.
CAN_InitTypeDef CAN_InitStructure;
CAN_InitStructure.Mode = CAN_Mode_Silent_LoopBack;
After updating the firmware, redeploying, and conducting real vehicle tests, stability improved immediately. We ran continuously for two days, and all nodes’ Error Counters stabilized below 10, with no further entries into Bus-Off.
The accident was avoided, but the client was already traumatized. Later, they required us to perform physical waveform consistency tests + timing tolerance tests + Bus-Off tolerance recovery tests for all CAN nodes before shipment.
I also learned a hard lesson from this experience:
- CAN bus is not just about being connected; the bit timing must be precisely consistent
- The sampling point is not chosen arbitrarily; it must be calculated based on network architecture and cable length
- A microsecond deviation may seem like a “tolerance range,” but under high-density communication, it is the starting point of an accident
Now, when training newcomers to write CAN drivers, my first question is not “Did you set the baud rate?” but:
“Do you know where the sampling point is?”
The CAN bus is not just connected by wires; it is supported by timing synchronization and fault tolerance collaboration. Once someone “misses the beat,” the whole scene will be thrown into chaos.