System overview

2010-2017 Honda Accord 2.4 Gas Vehicle Network System: How Module Communication Works and How to Diagnose It

Learn how F-CAN, B-CAN, module power and grounds, reporting-module U-codes, and network diagnosis work on the 2010-2017 Honda Accord 2.4 Gas.

Article vehicle: 2010-2017 Honda Accord 2.4 Gas

Educational introductionUse this overview to understand the system before diagnosis. Confirm the exact vehicle and follow the applicable service procedure for tests, specifications, and repairs.
Abstract vehicle network illustration showing control modules, two communication domains, a central gateway, bidirectional data flow, and a diagnostic interface

Applicability basis: Exact vehicle records confirm Honda Accord 2.4-liter gasoline applications at the 2010 and 2017 endpoints used by STEP Diagnostics. Detailed system and diagnostic evidence for this overview was verified on the 2017 application. Installed modules, network branches, connector locations, wire colors, scan-tool menus, and troubleshooting steps can vary by model year, body style, trim, and equipment; use current service information for the exact Accord being repaired.

What the vehicle network system does

Modern control units do not operate as isolated boxes. The powertrain control module (PCM), gauge control module, vehicle stability assist (VSA) modulator-control unit, electric power steering (EPS) control unit, supplemental restraint system (SRS) unit, body controllers, and optional equipment exchange information over serial communication networks.

That shared communication lets one module use information measured or calculated by another. Engine status can be displayed in the gauge assembly, stability control can coordinate with the powertrain, steering and restraint warnings can reach the driver, and a scan tool can ask multiple modules for DTCs and data without a separate diagnostic wire for every function.

The 2017 service information for this Accord uses two important network families:

  • F-CAN: A high-speed controller-area network used by powertrain, chassis, steering, restraint, gauge, and other modules that need rapid data exchange.
  • B-CAN: A body network used by body-electrical and convenience systems. Equipment on this network varies with the vehicle.

The gauge control module participates in communication between vehicle systems and is a central diagnostic participant in several of the related codes. That does not mean every network fault is a failed gauge module. A reporting module can store a U-code because another module stopped communicating, because the communication path was interrupted, or because the reporting module could not interpret the expected message.

At a high level, normal communication follows a simple sequence:

  1. Each installed module powers up and joins the network in the required vehicle mode.
  2. A transmitting module places identified information on the appropriate network.
  3. Receiving modules use the messages they expect for control, coordination, and driver information.
  4. The gauge and gateway functions pass required information between network domains.
  5. The diagnostic connection lets the scan tool ask participating modules for status, DTCs, and data.

The main functional parts

  • Control modules: Each module has its own power supply, grounds, software, inputs, outputs, and network transceiver. A module cannot communicate normally if it is not awake, powered, grounded, or internally functional.
  • F-CAN communication pair: Two related network circuits carry high-speed messages between participating modules. Circuit integrity and terminal condition matter as a pair; an open, short, poor terminal, or damaged branch can affect one module or a larger part of the network.
  • B-CAN communication path: Body-network communication links the gauge control module and installed body systems. Optional equipment can change which modules should appear in the connected-unit list.
  • Gateway and gauge functions: Communication between network domains depends on the correct gateway path and module operation. Diagnosis must identify which network and which side of the communication relationship are affected.
  • Diagnostic connection and scan tool: The diagnostic link allows the Honda scan tool to identify communicating modules, retrieve DTCs stored by individual modules, preserve snapshot data, and run directed checks. Scan-tool access to one module does not prove that every module or every network segment is healthy.
  • Connectors, splices, harness routing, power, and grounds: Network data depends on ordinary electrical integrity. Water intrusion, backed-out terminals, harness damage, shared fuse or ground faults, low system voltage, or recent repair work can create communication symptoms.

How normal communication works

1. A module powers up and joins the network

When the vehicle enters the required power mode, each installed module needs the correct battery or ignition feed and a reliable ground. Its network transceiver then listens and transmits according to the vehicle's communication strategy.

If a module never powers up, other modules may report that it is missing even though both network wires are intact. This is why an offline-module diagnosis starts with identification, power, and ground rather than immediate module replacement.

2. Modules exchange identified messages

A module places information on the network, and other modules use the messages they expect. The receiving module knows which information should arrive and whether it remains plausible. If an expected message disappears long enough under the applicable conditions, the observing module can store a lost-communication or CAN-malfunction DTC.

The module that stores the code is the reporter, not automatically the cause. For example, a gauge-control-module code naming the EPS unit means the gauge module detected a communication problem involving the EPS unit. The first diagnostic question is whether the EPS unit is actually offline and why, not whether the gauge module should be replaced.

3. The scan tool builds a network picture

A complete vehicle scan shows which modules answer, which modules report communication codes, and whether several reporters point to the same missing unit. That pattern is often more useful than the wording of one U-code.

If many modules have lost communication with one unit, focus first on that unit's power, ground, connectors, and network branch. If one module alone reports several missing units while the rest of the vehicle communicates normally, the reporter's local network path, power, connector, or gateway relationship deserves closer attention.

4. Different network domains exchange information

F-CAN and B-CAN serve different communication needs, but driver information and vehicle functions can cross between systems through the designed gateway path. A body-network concern can therefore create a gauge or convenience-system symptom, while a high-speed network concern can affect powertrain, stability, steering, restraint, or gauge information.

Do not assume that every U-code belongs to the same wire pair. Identify the code owner, named module, network domain, and exact vehicle equipment before opening the harness.

What the related DTCs are telling you

DTCCommunication categoryWhat it directs you to prove
U0100A reporting module lost communication with the PCMWhether the PCM and reporting module are both online, whether related network codes are primary, and whether the relevant F-CAN path, power, grounds, connectors, or module communication explains the loss
U0122A reporting module lost communication with the VSA modulator-control unit on F-CANWhich module stored U0122, whether the VSA unit communicates with the scan tool, and whether its power, grounds, connectors, software state, or the relevant F-CAN path explains the missing message
U0131A reporting module lost communication with the EPS unit; the linked STEP guide presents the gauge-control-module perspectiveWhich module stored U0131, whether the EPS unit is powered and grounded, whether it appears in the network scan, and whether the relevant F-CAN path remains intact
U0151Gauge control module lost communication with the SRS unitWhether U0151 is repeatable and whether the applicable F-CAN circuits and connectors between the gauge control module and SRS unit remain intact, while following exact SRS safety procedures
U0155A reporting module lost communication with the gauge control module; the linked STEP guide presents the PCM perspectiveWhich module stored U0155, whether the gauge control module and reporter remain accessible, and whether the relevant network path or a module-side condition explains the fault
U1288Gauge/body-network fault involving the parking and back-up sensor unit when equippedWhether that optional unit should be present, is detected on B-CAN, has power and grounds, and has an intact body-network path to the gauge control module

These codes do not all have one fixed owner or failure logic. U0155, for example, has separate procedures for PCM, parking/back-up-sensor, and multipurpose-camera perspectives. Read the DTC in the module that stored it and follow that module's exact procedure.

What the driver or technician may notice

Possible observations include:

  • several warning indicators or messages appearing together;
  • ABS, stability-control, steering, restraint, gauge, camera, parking-assist, or other equipment becoming unavailable, depending on the affected modules and installed equipment;
  • abnormal or missing gauge information;
  • a scan tool that communicates with some modules but not another;
  • multiple modules storing codes that name the same missing unit;
  • intermittent codes after water intrusion, low battery voltage, jump-starting, collision work, module replacement, connector disturbance, or harness movement;
  • a stored U-code with no current driver complaint because communication has returned.

These observations do not prove a CAN wire or control module has failed. Low voltage, a blown fuse, poor ground, an unplugged connector, a module that is not configured or awake as expected, or an unrelated primary fault can produce similar results.

Safety comes before network diagnosis

Communication diagnosis can involve the SRS, ABS/VSA, EPS, and powertrain systems. A U-code does not make those systems safe to probe, disconnect, or command.

Before disconnecting an SRS unit or working near airbag or pretensioner circuits, follow the exact Honda SRS disabling, waiting, handling, and reconnecting procedure. Do not measure resistance or apply power to an SRS circuit unless current service information explicitly directs that test.

Support the vehicle correctly if wheel-speed, steering, or running tests require the wheels to move. Keep leads and tools clear of belts, fans, exhaust components, steering linkages, and rotating wheels. Do not drive while watching a scan tool; use a second technician or approved recording method.

Use the correct battery-support and module-disconnection procedure. An accidental short, an unfused jumper, the wrong terminal, or disconnecting a module in the wrong vehicle state can damage a network transceiver, create new DTCs, or disable a safety function.

Common failure categories

1. One module is offline because it lacks power or ground

A fuse, ignition feed, battery feed, ground point, connector, terminal, or internal module fault can keep one unit off the network. Other modules then report loss of communication with that unit. Prove the unit's required feeds and grounds under the directed conditions before testing an entire network branch.

2. A local network path is open or has poor terminal contact

An open wire, backed-out terminal, corrosion, water intrusion, connector damage, or poor splice can isolate a module while the rest of the network continues to communicate. Continuity alone is not a universal proof: terminal fit, loaded circuit behavior, intermittent movement, and the exact branch layout may matter.

3. The network is shorted or electrically disturbed

A short between network circuits, short to power or ground, failed transceiver, damaged harness, or electrical interference can disrupt several modules. The pattern of accessible and inaccessible modules helps determine whether the problem is local or shared.

4. Low voltage or unstable system power creates secondary U-codes

Battery discharge, poor battery connections, charging problems, jump-start events, or voltage loss during cranking can make modules reset or wake at different times. Preserve the original code pattern and check basic electrical condition before treating every stored U-code as a separate network repair.

5. The reporting module, gateway path, or software state is involved

If the named module is online and its local circuits pass, the reporting module's connector, local branch, gateway relationship, software level, setup, or internal communication function may require the directed test. Software update or module replacement is a conclusion reached after the prescribed checks, not a first step.

6. The fault is intermittent

Heat, vibration, moisture, harness position, connector tension, or a momentary voltage event can interrupt communication and then disappear. A code that does not reset is evidence to preserve, not permission to replace a module. Use snapshot data, module lists, controlled harness inspection, and repeatable operating conditions to narrow the event.

A practical system-first diagnostic strategy

Step 1: Confirm the exact vehicle and installed equipment

Verify model year, engine, body style, trim, installed options, recent repairs, module replacements, programming history, and battery events. Do not expect an optional parking sensor, camera, or other controller to appear on a vehicle that was not built with it. Obtain the correct network diagram and DTC procedure for that exact configuration.

Step 2: Preserve the complete network evidence

Before clearing anything, perform a full vehicle scan. Record every communicating module, every module that does not respond, the owner of each U-code, confirmed/pending/history status, snapshot or freeze information, warning indicators, and system voltage. Save the original pattern because clearing codes or cycling power can make an intermittent network topology look normal.

Step 3: Group codes by the missing module and network

Ask who stored each code and which module or message it names. Several reporters naming one missing unit point toward that unit or its shared local conditions. Many missing modules on one network suggest a common network, power, ground, gateway, or splice problem. A lone reporter with otherwise normal communication suggests a more local relationship.

Follow Honda's multiple-code and related-code priorities. Resolve low-voltage, power-supply, and broader network faults before a single module-to-module U-code when the exact procedure directs that order.

Step 4: Decide whether the named module is online

Try to communicate directly with the named unit and inspect the connected-control-unit list when the procedure uses one. If the module is offline, verify that it should be installed, then test its specified fuses, power feeds, grounds, connector engagement, and wake conditions. If it is online, compare its own DTCs and network view with the reporter's evidence.

Step 5: Inspect the affected path

With the vehicle in the specified safe state, inspect accessible connectors, terminals, grounds, harness retainers, chafe points, moisture paths, collision areas, and recent service locations. Document connector position before disturbing it. Avoid disconnecting many modules at once because that can erase the original pattern and create additional codes.

Step 6: Perform the directed network tests

Use the exact wiring diagram and Honda procedure to test the correct F-CAN or B-CAN branch. Depending on the fault, the procedure may call for communication checks, circuit continuity, short checks, signal evaluation, terminal inspection, or isolation of a suspected branch or module.

Use the specified vehicle state, breakout method, and meter or scope. Do not publish or borrow a universal resistance value, connector pin, or network waveform from another year. A passing static check does not reproduce an intermittent fault unless the test is designed to monitor it under the failure condition.

Step 7: Make a module decision only after the supporting paths pass

If power, grounds, connectors, network circuits, related-code priorities, and applicable software or setup checks all pass, follow the directed substitution or replacement decision. A known-good-module step can require immobilizer, calibration, variant coding, idle learn, or other setup; it is not a casual swap.

Step 8: Verify the entire repair

Reconnect and secure every disturbed connector, ground, shield, and harness retainer. Restore any SRS, steering, stability-control, powertrain, or body-system setup required by current service information. Clear codes when directed, cycle the vehicle through the specified states, repeat the complete network scan, and confirm that every expected module communicates and the original DTC does not return.

Also verify the affected function and warning indicators. One module responding once after a battery cycle is not enough to close an intermittent network repair.

Match the repair to the proven failure

The supported repair may be a fuse or power-feed repair, restored ground, corrected terminal fit, connector or harness repair, water-intrusion correction, repaired network branch, corrected battery or charging condition, module software/setup work, or module replacement only after the directed tests support it.

Avoid common shortcuts:

  • replacing the module named in a U-code without checking whether it is powered, grounded, and online;
  • replacing the module that stored the code without understanding that it is the reporter;
  • clearing codes before recording the full module and DTC pattern;
  • treating every U-code as a separate failure when several share one offline unit or voltage event;
  • using a generic CAN resistance check as the only network test;
  • condemning a module from a code that does not reset and cannot be duplicated;
  • disconnecting SRS, EPS, VSA, or PCM connectors without the exact safety and setup procedure.

Final takeaway

On the 2010-2017 Honda Accord 2.4 Gas, network diagnosis starts by separating the reporting module from the module it says is missing. Build a complete communication map, preserve the original DTC pattern, identify whether the fault belongs to F-CAN or B-CAN, and decide whether the named module is actually online.

Then prove the basics in order: correct application and installed equipment, battery condition, module power and grounds, connector integrity, the relevant network branch, and only then software or module function. The linked STEP DTC guides provide model-specific educational paths; current Honda service information for the exact Accord controls connector references, electrical limits, scan-tool functions, safety procedures, module setup, and final verification.

Continue diagnosing

Vehicle network and module communication system DTC guides for this vehicle