CAN bus engineering combines network topology, message arbitration, bit timing, firmware drivers, and fault handling. This OSFEC.009 lesson follows OSFEC.008: SPI Bus Engineering.

Learning objectives

Design a terminated CAN network, select arbitration priorities, calculate approximate bus loading, distinguish classical CAN from CAN FD, and build reliable firmware error recovery.

Architecture and arbitration

CAN is a multi-controller broadcast bus. A dominant zero wins arbitration over a recessive one, so lower numeric message identifiers generally have higher priority. Classical CAN data frames carry up to eight payload bytes; CAN FD permits up to 64 bytes and a separate faster data phase.

Topology and termination

A conventional high-speed CAN trunk has approximately 120 Ω termination at each physical end. With the system powered off, the two resistors in parallel often measure near 60 Ω. Engineers must also evaluate stub length, impedance, transceiver common-mode range, grounding, isolation, and electromagnetic compatibility.

Bit timing

At 500 kbit/s, one nominal bit takes 2 microseconds. The sample point, time quanta, synchronization jump width, oscillator tolerance, cable delay, and transceiver propagation delay must all be considered. CAN FD requires separate attention to data-phase timing and transceiver delay compensation.

Bus load and worst-case latency

Estimate periodic load by summing each frame’s worst-case transmission time divided by its period. Twenty frames every 10 ms, each taking an assumed 150 microseconds, imply 30 percent utilization. Actual timing includes stuffing, arbitration, CRC, and interframe spacing. Average utilization does not establish worst-case response time because priority interference and bursts matter.

Firmware driver architecture

Initialize hardware into a known state, configure acceptance filters, use bounded interrupt service routines, and transfer received frames into appropriately sized queues. Track queue overflow and transmit errors. Preserve diagnostic counters and avoid silent loss of messages. Define application-level freshness timeouts and safe behavior when required data stops arriving.

Error confinement and recovery

CAN controllers detect bit, stuff, form, CRC, and acknowledgment errors. Their error counters can move a node into error-passive or bus-off state. Recovery must be intentional: record the failure, apply a controlled retry policy, and investigate repeated failures rather than endlessly restarting the controller.

Verification

Measure normal and peak bus load; inspect differential waveforms; verify the intended bitrate; check error counters; and validate latency under high-priority bursts. Conduct electrical fault tests only on approved isolated laboratory fixtures. A production control network must never be used for unapproved fault injection.

Engineering exercise

A controller publishes status every 5 ms, while four other controllers publish every 10 ms. Define message priorities, queue capacity, freshness deadlines, bus-off recovery, and a measurement plan. Explain why a single average utilization number is insufficient to prove that all deadlines will be met.

Knowledge check

1. Why do lower identifier values generally win arbitration? 2. What does a 60 Ω powered-off measurement usually indicate? 3. Why does CAN FD need separate data-phase timing? 4. Why is bus-off a symptom rather than a root cause? 5. Why should receive queues report overflow?

Answer guide

1. Dominant zero bits override recessive bits. 2. Two 120 Ω end resistors in parallel. 3. The higher data rate changes timing and physical-layer requirements. 4. Many electrical and configuration problems can trigger bus-off. 5. Silent loss hides reliability problems and invalidates timing assumptions.

References and previous lessons

Primary references: Bosch CAN FD specification, Linux SocketCAN, and Kvaser CAN tutorial. Previous lessons: OSFEC.008, OSFEC.007, and OSFEC.006.

BitcoinVersus.Tech Editor’s Note:
We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support to help further secure the integrity of our research initiatives, please donate using the QR code provided