CAN troubleshooting
A CAN gateway issue appears when an expected frame does not cross a network boundary, arrives with incorrect content, or is delivered on the wrong CAN network. This guide helps establish whether the fault is in the observed traffic, message definition, gateway routing, transport handling, or the underlying bus.
Start the diagnostic workflowObservable symptoms
A frame or signal can be observed on the source network but not on the expected destination network. Compare timestamps and message identifiers to distinguish a gateway omission from a message that was not transmitted by the source node.
The destination frame is present, but its payload, signal value, scaling, or update timing differs from the source behavior. Compare raw frames before relying on decoded values, because an incorrect DBC interpretation can resemble gateway modification.
A frame is observed on a network where it is not expected, while the intended destination may remain silent. Confirm the network capture location and channel assignment before treating this as a routing defect.
Single-frame CAN communication may pass while longer communication does not complete. This pattern points toward ISO-TP or CanTp handling, addressing, or timing rather than a general absence of gateway traffic.
Forwarding works in some recordings or operating conditions but fails when traffic load or message timing changes. Correlate the failure with bus activity and timestamps to separate scheduling or overload effects from a fixed route definition error.
Possible causes
The route may be missing, assigned to the wrong destination network, filtered by message identifier, or enabled under conditions that are not active during the failure. This directly produces absent or misrouted destination traffic.
If the gateway or analysis uses an incorrect message identifier, payload length, signal layout, or scaling definition, a valid frame may appear missing or modified even when the underlying forwarding path is functioning.
A mismatch between COM, PduR, CanIf, CanTp, and the configured source or destination PDU can prevent the intended data from reaching the gateway route or can associate the route with the wrong lower-layer object. RTE is relevant only when the application fails to produce or consume the signal.
Differences in CAN versus CAN-FD operation, payload handling, or network configuration can prevent a frame from being accepted or transmitted across the gateway path.
For segmented traffic, ISO-TP or CanTp addressing, flow control, or timing behavior can stop forwarding even when ordinary CAN frames cross the gateway correctly.
Bus errors, missing source traffic, or a network that is not operating can make the gateway appear defective. The gateway cannot forward a frame that it does not receive or cannot transmit successfully.
Ordered investigation
Record the source network, destination network, expected message identifier, expected timing, expected payload behavior, and the condition under which forwarding should occur. This prevents a gateway fault from being inferred from an incomplete problem description.
Use a CAN dump or recording to confirm that the source network produces the expected frame during the failure. This rules out a source-node or test-condition problem but does not establish that the gateway received or routed the frame.
Align captures by timestamp and compare identifiers, payload length, data bytes, and repetition period on both networks. This separates no-forwarding, altered-forwarding, wrong-network, and timing-related patterns.
Use the supplied DBC to check identifiers, payload lengths, signal positions, byte order, scaling, and network assignment. This rules out a decoding or database mismatch before software routing is changed.
Determine whether the failing exchange consists of ordinary frames or ISO-TP segments. If only segmented traffic fails, narrow the investigation to addressing, flow control, timing, and CanTp behavior rather than the general message route.
Identify whether the route is signal based, direct I-PDU forwarding, or transport-protocol forwarding. Review the configured source and destination PDU IDs through PduR and the applicable COM, CanIf, or CanTp modules; inspect RTE only if application signal production or consumption is the failing boundary.
Use CANoe or CANalyzer to replay or observe the relevant traffic and vary only the condition associated with the failure. If available, a Python analysis script can compare recordings consistently; this narrows timing and load-dependent behavior without proving a single root cause.
Verification gates
In the failing interval, count the expected source identifier and compare its observed period with the expected period from the problem description.
The source frame is present at the expected rate and with a stable payload length.
Investigate source-node behavior, test conditions, or the source CAN/CAN-FD network before changing gateway routing.
Search the destination capture for the expected identifier during the same timestamp interval and verify the capture channel represents the intended destination network.
The destination frame appears on the intended network within the expected forwarding delay or cycle.
Check route configuration, destination network state, filtering, and whether the gateway received the source frame.
Compare source and destination data bytes, payload length, and timestamp spacing before decoding signals.
Differences match the documented gateway behavior; otherwise the frame content and timing are preserved as expected.
Check message mapping, CAN versus CAN-FD handling, gateway transformation logic, and DBC interpretation.
Compare the captured identifier, payload length, signal positions, scaling, and network assignment with the DBC used for analysis.
The DBC describes the observed frame and assigns it to the captured network correctly.
Correct the analysis database or obtain the applicable message definition before concluding that the gateway modifies the message.
Review the recording around the failure for missing source traffic, abnormal repetition, or communication interruptions on either network.
Both networks remain active and the source and destination observations are stable during the comparison interval.
Investigate CAN or CAN-FD network operation and capture conditions; a gateway route cannot be confirmed while the bus evidence is incomplete.
Compare the configured PduR source and destination PDU IDs with the applicable COM, CanIf, or CanTp interfaces and their source and destination network assignments.
The same message path is consistently mapped from the source interface to the intended destination interface.
Review AUTOSAR communication configuration and software integration with the responsible software or integration owner.
From evidence to action
If the source and destination evidence confirms a route defect, correct the message routing, destination assignment, filtering, or activation condition, then repeat the same source-to-destination comparison.
If the traffic is correct but interpretation or mapping is not, align the DBC and gateway message definitions for identifier, payload length, signals, scaling, and network assignment. Re-run decoding before evaluating the result.
If the PduR route or its COM, CanIf, CanTp, source-PDU, or destination-PDU mapping is inconsistent, correct the applicable configuration and integration artifacts, then verify both ordinary frames and any affected transport traffic.
If the networks or gateway path disagree on CAN or CAN-FD behavior, align the applicable network and message configuration and confirm that the gateway accepts and transmits the expected frame type.
FAQ
Diagnostic support
When the evidence points to a gateway configuration, communication mapping, or decoding boundary, an engineering analysis can turn synchronized recordings and definitions into a focused finding.