A communication code tells you that a message or communication function failed. It does not, by itself, identify a defective control unit. On the Honda Civic, a module that has lost its power supply, a damaged communication circuit, and a module-side fault can lead to similar missing-message complaints. The useful starting question is not "Which module should I replace?" but "Who reported the problem, who is missing, and what else stopped communicating?"
This overview introduces network diagnosis for the 2010-2015 Honda Civic 1.8 Gas. The model and gasoline-engine combination is supported throughout that range. The architecture and diagnostic examples below were reviewed against a 2015 Civic Sedan 1.8-liter configuration. Earlier years, markets, transmissions, and equipment can differ. Use the service information for the actual vehicle to identify its installed modules, network layout, test conditions, and repair requirements. This is an introduction, not a replacement for a wiring diagram or a complete diagnostic procedure.
What the network does
Electronic control units need information from one another as well as from their own sensors. Network messages let powertrain, chassis, instrument, and body systems exchange information without a separate dedicated wire for every shared function. A receiving module can recognize that expected communication is absent even when the original fault lies elsewhere.
In the reviewed 2015 example, Honda separates powertrain and chassis communication on F-CAN from body-system communication on B-CAN. The gauge control module provides a gateway between those networks. The vehicle also uses LIN for communication involving the engine controller, alternator, and battery sensor. These names describe different communication paths, not interchangeable test points. Do not apply a CAN test to a LIN circuit merely because both carry data.
Body-system operation also includes sleep and wake behavior. Some functions remain available with the ignition off, while power-saving states reduce standby consumption. Ignition state, installed equipment, and the scan tool's current connection status therefore matter when deciding whether a module is genuinely missing. A module marked unavailable may not be fitted to that vehicle; verify the equipment before diagnosing its absence.
Read a U-code from the reporting module's perspective
The same code family can appear in different control units. Record the reporting module as well as the code and its status. The following STEP guides illustrate four related but distinct diagnostic paths:
| STEP guide | What the linked example concerns | What it does not prove |
|---|---|---|
| U0029: F-CAN bus-off at the ECM/PCM | A bus-off communication fault reported at the engine controller; the reviewed procedure separates repeatable from intermittent behavior before its software/module verification branch. | Every network code needs the same software update, or the engine controller is automatically defective. |
| U0100: lost communication with the ECM/PCM | The keyless-access power control unit's communication path to the engine controller, where that equipment is fitted. | The module named after "lost communication with" is the failed part. |
| U0122: lost communication with the VSA modulator-control unit | The keyless-access power control unit's missing VSA communication; the reviewed path includes the VSA power feed and communication wiring. | A brake hydraulic fault, or a defective VSA unit based on the code alone. |
| U0131: gauge control module lost communication with EPS | Communication between the instrument system and electric power steering, with attention to the EPS ignition feed and F-CAN wiring. | Mechanical steering failure or a need to replace the steering unit without testing. |
These are specific reporting-module examples, not universal definitions for every appearance of those codes. The full vehicle scan and applicable Honda diagnostic index determine which procedure belongs to the complaint.
How faults can appear
Communication problems may accompany warning indicators, abnormal instrument behavior, keyless-access or starting complaints, or other system messages. Intermittent faults may leave stored codes while the vehicle behaves normally during inspection. A warning about a system can be a consequence of missing information, so separate the customer's actual symptom from the list of modules that noticed it.
The main diagnostic categories are:
- Power supply and connections. A control unit cannot communicate normally without the feeds and grounds its circuit requires. The reviewed U0122 and U0131 paths specifically check an ignition supply before judging communication wiring or modules.
- Communication wiring and connectors. An open circuit or poor connection can interrupt the path between otherwise serviceable modules. Check the actual circuit rather than assuming two units with a related code share a direct connection.
- Intermittent operating conditions. Preserve when the fault occurred and whether it can be reproduced. A code that does not return is not proof that a historical complaint never happened.
- Module or software faults. These remain possible, but the relevant diagnostic branch and repair verification must support the conclusion. The U0029 example contains a controlled software/substitution path; it is not a general instruction to reprogram every module.
A practical diagnostic approach
Preserve the evidence first. Record the complaint, vehicle configuration, a complete module scan, code status, and available freeze-frame or snapshot information before clearing anything. Keep track of which units communicate and which units report a missing neighbor. This makes a group of codes more informative than a list of isolated labels.
Follow the applicable diagnostic priority. In the reviewed Honda guidance, ECM/PCM and F-CAN loss-of-communication concerns take priority before the B-CAN routine. Within that body-network routine, supply-voltage and internal-error categories are considered before missing-message and signal-error categories. This illustrates why the first code displayed by a scan tool is not necessarily the first fault to diagnose; follow the priority for the actual vehicle and reporting system.
Establish what is current. After saving the evidence, use the applicable verification conditions to see which faults return. Compare the communication pattern with the installed equipment. Do not confuse a stale scan-tool module list with a fresh post-repair check.
Separate supply faults from network-path faults. Verify the specified power, ground, fuse, and connector conditions before condemning a module. Then use the applicable wiring diagram and circuit test to examine the communication path. A continuity result answers a limited question under the conditions of that test; it does not independently demonstrate that every module exchanges valid messages during operation.
Escalate only on evidence. If a documented branch calls for a software update, controlled substitution, or replacement, confirm applicability and follow the required setup. Do not use random module disconnection or replacement as a substitute for the diagnostic sequence.
Repair categories, safety, and verification
Repairs may involve restoring a power feed, correcting the cause of a fuse failure, repairing an approved wiring or connector fault, or completing a supported software/module repair. Preserve the specified communication-circuit construction and follow the vehicle's connector and wiring repair requirements. Module replacement may have configuration or initialization requirements; consult the applicable procedure rather than assuming a replacement is ready to use.
Treat electrical tests as controlled workshop work. Follow the specified ignition, battery-disconnection, and waiting requirements before unplugging components; some checks require power and others do not. Never measure airbag inflator resistance or perform other electrical tests directly on an airbag. Do not treat SRS wiring as an ordinary network test point. Work near restraint-system components requires the specific SRS precautions. Assess braking and steering warnings before any road test, and do not road-test a vehicle whose safe operation is in doubt.
After repair, refresh the scan-tool session as required, confirm the expected installed modules communicate, repeat the applicable fault-verification check, and confirm the original complaint is resolved. Review remaining codes rather than treating a cleared warning lamp as the only completion criterion. A successful network repair restores the relevant communication and system behavior, not just an empty code list immediately after clearing.
