The Two-Node CAN Bus Problem: Error Handling, Bus Off, and Silent Mode

A JCOM1939 Engineering Note on Error Handling, Bus Off, and Silent Mode in Two-Node CAN Networks

Controller Area Network (CAN) is well known for its robustness. Arbitration prevents message collisions from corrupting data, error detection identifies damaged frames, automatic retransmission provides another opportunity to deliver a message, and error confinement can eventually remove a malfunctioning node from the network.

All of these mechanisms contribute to CAN’s reputation as an exceptionally reliable industrial and automotive communication system.

There is, however, an interesting question that receives considerably less attention:

Does a CAN network with only two nodes behave exactly like a larger CAN network?

During normal communication, the answer is generally yes. Two CAN nodes can communicate perfectly well with each other. Many development systems and laboratory test benches therefore consist of nothing more than two CAN interfaces connected through a properly terminated bus.

The situation becomes considerably more interesting when something goes wrong.

Error handling, acknowledgment, Bus-Off behavior, and Listen-Only operation can produce results on a two-node network that would either not occur or would be much less noticeable on a network containing three or more active nodes.

This is particularly important when using CAN analyzers and simulators on a development bench. A test configuration consisting of two interfaces may appear to represent a small version of a production CAN network, but under certain fault conditions it does not behave the same way.

This article examines why.

1. Does a CAN Network with Only Two Nodes Behave Exactly Like a Larger CAN Network?

Consider the simplest possible CAN network:

Node A ↔ CAN Bus ↔ Node B

Assuming correct termination, bit timing, wiring, and configuration, there is nothing inherently wrong with this arrangement.

Node A can transmit a CAN data frame. Node B receives the frame and, assuming it has been received correctly, asserts the dominant bit during the ACK slot. Node A sees the acknowledgment and considers its transmission successful.

The reverse works in exactly the same way.

It is important to understand that the ACK bit does not mean that the application running on Node B has processed or accepted the data. It confirms at the CAN protocol level that at least one other active CAN controller received the frame correctly.

In a larger network, however, the situation looks like this:

Node A ↔ Node B ↔ Node C ↔ Node D

If Node A transmits a valid frame, any correctly receiving active node can contribute to the ACK.

This redundancy usually goes unnoticed. Under normal conditions it does not matter whether one node or ten nodes acknowledge the frame.

It begins to matter when nodes fail, enter Bus Off, or are deliberately configured not to participate in normal CAN communication.

That is where a two-node network becomes a special case.

2. The Two-Node CAN Bus Problem: What Happens When Error Detection Becomes Ambiguous?

CAN implements extensive error detection and fault confinement. Each CAN controller maintains two important counters:

TEC — Transmit Error Counter
REC — Receive Error Counter

These counters do not simply increase by one whenever something goes wrong. CAN defines a series of rules that increment or decrement the counters differently depending on the type of error and the circumstances under which it occurs.

The objective is fault confinement.

A CAN controller can exist in three principal error states:

Error Active → Error Passive → Bus Off

An Error Active node participates normally and can transmit an Active Error Flag when it detects an error.

When its error counters exceed the appropriate threshold, it becomes Error Passive. It can still communicate, but its ability to disturb the network when reporting errors is restricted.

When the Transmit Error Counter reaches the Bus-Off threshold, the node is removed from active bus participation.

This is one of CAN’s major strengths.

However, it is tempting to describe CAN error confinement as the other nodes “voting” on which node caused an error. That isn’t quite correct.

There is no formal majority vote.

Instead, each CAN controller independently observes the bus and modifies its own error counters according to the CAN fault-confinement rules.

On a network with several active nodes, the behavior of the other controllers often helps isolate a malfunctioning participant. A faulty transmitter can accumulate transmit errors while correctly operating receivers continue participating normally.

With only two nodes, some error situations become less clear.

If Node A is transmitting and Node B is receiving, there is no third active controller observing the same event from another independent position on the network. Depending on the type of fault, Node A and Node B can react differently to what they observe.

The CAN error-counter rules are specifically designed to avoid unnecessarily removing healthy nodes from a network. Nevertheless, a severely disturbed two-node network can produce behavior that is less intuitive than the same disturbance on a larger network.

This is not necessarily a defect in CAN. It is a consequence of operating a fault-tolerant multi-node protocol at its practical minimum number of communicating nodes.

Texas Instruments Put This to the Test

This is not merely a theoretical consideration.

Texas Instruments investigated CAN behavior using real CAN networks in its application report SLLA109A, A System Evaluation of CAN Transceivers.

The report describes an experimental two-node CAN network using TI CAN transceivers and controllers. The test methodology included sending one million messages from Node A to Node B and then from Node B to Node A, unless a node reached Bus Off first.

The researchers examined the CAN controllers’ error registers to evaluate bus performance. They tested different cable lengths and bit rates and deliberately explored conditions approaching the electrical limitations of the network.

The significance for our discussion is that TI specifically recognized the unusual nature of a two-node network once one participant enters Bus Off.

Their conclusion was essentially that the bus could become silent, or the remaining node could continue retransmitting while waiting for a valid ACK. TI characterized such a condition as a heavily disturbed bus and not one recommended for an actual application.

A second TI paper goes even further.

SLLA123, Using CAN Arbitration for Electrical Layer Testing, was presented by Sam Broyles and Steve Corrigan of Texas Instruments at the 8th International CAN Conference in Las Vegas in February 2002.

This work used arbitration itself as an experimental tool for evaluating CAN electrical-layer performance. The researchers constructed networks in which multiple nodes were deliberately made to respond simultaneously so that arbitration occurred repeatedly. Controller status and error registers were monitored during the experiments.

The paper explicitly distinguishes between two-node and larger CAN networks when a node enters Bus Off. With two nodes, the surviving node may repeatedly attempt transmission because nobody remains to supply the ACK. With three or more active nodes, another participant can provide that acknowledgment.

That distinction is fundamental to understanding the two-node problem.

3. What Happens When One Node Goes Bus Off on a Two-Node CAN Network?

Suppose we start with two normally functioning nodes:

Node A ↔ Node B

Now assume that some fault causes Node A’s Transmit Error Counter to increase until Node A reaches Bus Off.

The CAN fault-confinement mechanism has done exactly what it was designed to do.

Node A is no longer permitted to influence the CAN bus.

From CAN’s perspective, this is desirable. A malfunctioning controller should not be allowed to continuously corrupt communication for every other participant.

But our network now effectively contains:

Node B ↔ nobody

If Node B merely listens, this may not immediately produce another obvious problem.

If Node B attempts to transmit a CAN data frame, however, there is nobody left to acknowledge it.

Node B transmits the frame and monitors the ACK slot.

No dominant ACK bit appears.

Node B therefore detects an ACK error.

CAN provides automatic retransmission, so the controller may attempt to transmit the frame again.

Again there is no ACK.

This can result in repeated transmission attempts that look very different from the intended application-level transmission rate.

There is an important technical qualification here.

It would be incorrect to say that every missing ACK simply increases the TEC indefinitely until the remaining node inevitably reaches Bus Off. CAN’s fault-confinement rules include special handling for ACK errors, particularly once a transmitter becomes Error Passive.

The original Bosch CAN specification even discusses the single-active-node situation. A node transmitting without any other node available to acknowledge its frames can become Error Passive due to the missing acknowledgment, but the fault-confinement rules prevent that condition alone from necessarily driving it into Bus Off.

This detail is important because it demonstrates how carefully CAN’s fault-confinement mechanism was designed.

Nevertheless, from the application’s perspective, communication has failed.

Now Add a Third Node

Consider instead:

Node A ↔ Node B ↔ Node C

Node A goes Bus Off.

We still have:

Node B ↔ Node C

If Node B transmits a valid frame, Node C can acknowledge it.

Node A’s failure therefore does not inherently prevent Node B and Node C from continuing normal CAN communication.

This is precisely the distinction highlighted in the TI experiments.

4. CAN Bus Off Protects the Network—but Who Detects the Missing ECU?

This leads to another interesting limitation of CAN.

Bus Off is often described as one of CAN’s major reliability features, and rightly so.

Suppose an ECU develops a hardware problem and begins producing errors. Without some means of fault confinement, one defective device could potentially make the entire network unusable.

CAN protects against this.

As the malfunctioning node accumulates transmit errors, its error state deteriorates:

Error Active → Error Passive → Bus Off

Once Bus Off, the controller is no longer allowed to influence the bus. The remaining network can continue operating.

But CAN itself does not answer another important question:

Who notices that the ECU disappeared?

At the CAN data-link level, there is no list of ECUs that are supposed to be present.

CAN does not inherently know that the engine controller, transmission controller, ABS controller, instrument cluster, or any other particular ECU should exist.

CAN identifiers primarily identify message content and priority, not the physical identity of the transmitting device.

Consequently, Bus Off can work perfectly from CAN’s perspective while producing a serious problem at the application level.

Imagine an ECU controlling an important vehicle function.

The ECU experiences a fault.

CAN detects repeated transmission errors.

The ECU eventually enters Bus Off.

The rest of the CAN network continues communicating normally.

CAN has successfully protected the network.

But the vehicle has lost an ECU.

CAN itself provides no general mechanism that tells the remaining applications:

“An expected ECU is missing.”

That responsibility belongs to a higher protocol or to the application.

Missing-Node Detection Must Be Implemented Above CAN

An application can detect missing communication in several ways.

Common techniques include periodic heartbeat messages, expected-message timeouts, request-and-response supervision, watchdog mechanisms, and monitoring the arrival interval of cyclic messages.

For example, suppose an ECU is expected to transmit a particular message every 100 ms.

The receiving application might define a timeout of 500 ms.

If the message is not received during that interval, the application concludes that the information—or potentially the ECU producing it—is no longer available.

The application can then determine the appropriate response.

That might involve displaying a diagnostic warning, storing a fault code, switching to substitute values, entering a degraded operating mode, disabling a function, or initiating another safety response.

CAN itself does not make that decision.

A useful way of summarizing the distinction is:

CAN protects the network from a malfunctioning node. The application must protect itself from a missing node.

SAE J1939 Adds Another Layer

SAE J1939 provides additional mechanisms above CAN that can assist with node and message supervision.

For example, the J1939 Address Claim procedure provides information about devices participating on the network. Applications can also monitor expected periodic PGNs and determine whether the corresponding information has disappeared.

However, even J1939 does not magically determine the correct application response to every missing ECU.

Ultimately, the system designer must define which devices or messages are required and what should happen when they disappear.

5. CAN Listen-Only Mode: Why a Two-Node Test Bench Can Behave Unexpectedly

The two-node issue becomes particularly visible when using CAN analyzers and development tools.

Consider a practical laboratory setup containing:

PEAK PCAN — General-Purpose CAN Bus Analyzer ↔ JCOM1939 — SAE J1939 Simulator & Monitor

Both devices are initially operating as active CAN/J1939 nodes.

Suppose the PEAK interface is configured to transmit a CAN frame periodically—perhaps once every second.

JCOM1939 receives the message and participates normally in CAN communication.

Everything works as expected.

Now JCOM1939 is switched into Listen-Only, or Silent Mode.

The intention seems simple:

JCOM1939 should listen to the bus without transmitting anything.

That is exactly what a true CAN Listen-Only mode does.

But “doesn’t transmit data frames” is not the complete description.

A truly silent CAN controller must avoid influencing the bus. Among other things, it does not provide the ACK bit for a correctly received frame.

That changes our two-node network dramatically.

Before Silent Mode:

PCAN → Data Frame → JCOM1939 → ACK

After JCOM1939 enters Silent Mode:

PCAN → Data Frame → JCOM1939 listens silently → No ACK

From the JCOM1939 perspective, Silent Mode is working correctly.

From the PCAN controller’s perspective, however, its transmission has failed.

The Apparent “Runaway” CAN Frame

This can produce a particularly confusing observation on a CAN analyzer.

Suppose the PCAN application has been configured to transmit a particular message once per second.

The user expects:

Frame → 1 second → Frame → 1 second → Frame

Instead, after the other CAN node enters Silent Mode, the analyzer may suddenly display the frame repeatedly and at a much higher apparent frequency.

It can look as though the configured transmission rate is accelerating or has somehow become corrupted.

We jokingly refer to this observation as the “runaway” CAN frame.

But the application has not necessarily changed its periodic transmission rate.

What the user may actually be observing is CAN’s automatic retransmission mechanism.

The sequence is approximately:

Transmit frame → No ACK → ACK error → retransmit → No ACK → error handling → retransmit

Those CAN-controller retransmissions are fundamentally different from new periodic transmission requests generated by the PCAN application.

This distinction explains why looking only at the CAN traffic can be misleading.

The application may still be requesting one message every second while the CAN controller is attempting multiple transmissions of that message because it cannot complete a successful transmission.

Silent Mode Is Passive—but It Can Change the Network

This leads to an important observation:

Silent Mode is passive from the perspective of the CAN interface, but enabling it can have an active effect on the behavior of a two-node CAN network.

That sounds contradictory, but it is not.

JCOM1939 in Silent Mode is doing exactly what it should do: observing without influencing the bus.

The problem is that before entering Silent Mode, JCOM1939 was the only other active participant capable of acknowledging PCAN’s transmissions.

Removing that participation changes the operating conditions of the network.

This is why Listen-Only mode can be misleading on a development bench.

On a vehicle or industrial CAN network containing many active ECUs, putting one analyzer into Listen-Only mode generally has no effect on acknowledgment because numerous other nodes remain available to provide the ACK.

On a two-node bench, it can make all the difference.

6. Why a Third CAN Node Can Make a Test Bench More Reliable

The solution to many of these confusing test conditions is remarkably simple:

Add another active CAN node.

Instead of:

PCAN ↔ JCOM1939

use:

PCAN ↔ JCOM1939 ↔ Third CAN Node

or:

PEAK PCAN — CAN Analyzer ↔ JCOM1939 Starter Kit (Two Active CAN/J1939 Nodes)

Now place one JCOM1939 node into Silent Mode.

PCAN transmits its frame.

JCOM1939 receives it silently and does not acknowledge it.

But the third active node receives the same valid CAN frame and supplies the ACK.

PCAN therefore considers the transmission successful.

No missing-ACK condition is created merely because JCOM1939 is operating in Listen-Only mode.

The same principle applies to Bus-Off testing.

If one node goes Bus Off on a three-node network, two active participants remain. Those nodes can continue acknowledging each other’s transmissions.

This makes a three-node test bench much more representative of many real-world CAN networks when investigating error handling, Bus Off, Listen-Only operation, and automatic retransmission.

The Third Node Does Not Need to Understand the Application

There is another important point.

For ACK purposes, the third CAN controller does not necessarily need to understand the application data.

It does not need to recognize the J1939 PGN or perform a meaningful application-level function with the message.

At the CAN level, a correctly operating active controller that successfully receives the frame can participate in acknowledgment.

This makes it possible to use a relatively simple CAN interface as the additional active node during laboratory testing.

Physical Presence Is Not the Same as Active Participation

This distinction also helps explain why simply attaching another CAN transceiver is not sufficient.

TI’s SLLA123 experiments, for example, used networks containing numerous dummy load nodes consisting of powered transceivers without CAN controllers or processors. These devices were useful for electrically loading the network, but they were not active CAN protocol participants.

For solving the ACK problem, what matters is not merely another transceiver connected to CAN_H and CAN_L.

There must be another active CAN controller capable of correctly receiving the frame and participating in the ACK mechanism.

Two Nodes Are Valid—but They Are a Special Test Environment

None of this means that a two-node CAN network is inherently incorrect.

Two properly configured CAN nodes can communicate reliably for an indefinite period.

The problems discussed here emerge when we begin testing abnormal conditions:

one node enters Listen-Only mode,
one node reaches Bus Off,
communication errors are deliberately introduced,
acknowledgment disappears,
or error confinement is being investigated.

Under those conditions, a two-node network can behave differently from a larger CAN system.

This is especially important when using CAN analyzers, simulators, development boards, and ECU test systems. An engineer may interpret unusual behavior as a software problem, CAN-controller problem, or analyzer malfunction when the actual cause is simply the topology of the test setup.

The apparent “runaway” transmission observed when testing JCOM1939 in Silent Mode is a good example.

Nothing necessarily changed in the application’s requested transmission interval.

Instead, placing the only receiving participant into true Listen-Only mode removed the only available ACK source. CAN’s error-handling and retransmission mechanisms then became visible in a way they normally would not on a larger network.

The Texas Instruments experiments described in A System Evaluation of CAN Transceivers (SLLA109A) and Using CAN Arbitration for Electrical Layer Testing (SLLA123) demonstrate that the distinction between two-node and larger CAN networks has practical consequences. TI deliberately used real CAN networks, controller error registers, repeated transmissions, different network configurations, and Bus-Off conditions to explore these behaviors.

The lesson is not that CAN is unreliable.

Quite the opposite.

Many of the surprising effects occur precisely because CAN is doing what it was designed to do: detecting errors, retransmitting unsuccessful frames, restricting faulty nodes, and ultimately isolating a transmitter when necessary.

The important lesson for CAN developers is simpler:

A two-node CAN test bench is not always a miniature version of a multi-node CAN network.

When testing error handling, Bus Off, or Listen-Only operation, the number of active CAN nodes matters.

SAE J1939 Starter Kit and Network Simulator

Our JCOM.J1939 Starter Kit and Network Simulator is designed to allow the experienced engineer and the beginner to experiment with SAE J1939 data communication without the need to connect to a real-world J1939 network, i.e., a diesel engine. It may sound obvious, but you need at least two nodes to establish a network. That fact applies especially to CAN/J1939, where the CAN controller shuts down after transmitting data without receiving a response. Therefore, our jCOM.J1939 Starter Kit and Network Simulator consists of two J1939 nodes, namely our jCOM.J1939.USB, an SAE J1939 ECU Simulator Board with USB Port.

The jCOM.J1939.USB gateway board is a high-performance, low-latency vehicle network adapter for SAE J1939 applications. The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP). More Information…