ECU unavailable or not awake
A possible cause is that the ECU is unpowered, in a sleep state, held in reset, or not participating in the network state required for diagnostics.
UDS troubleshooting
ECU Not Responding to UDS
A structured diagnostic workflow for investigating an ECU that does not respond to UDS requests over CAN and ISO-TP or over DoIP.
Start the diagnostic workflowObservable symptoms
What the failure can look like
No diagnostic response
The tester sends a request, but no response is received from the expected ECU address before the configured timeout.
Network traffic is present but UDS is silent
CAN, CAN-FD, or Ethernet communication is visible, while diagnostic requests to the target ECU remain unanswered.
Communication depends on vehicle state
Diagnostics work in one ignition, power, wake-up, or network state and stop working in another.
Diagnostic communication is intermittent
The ECU responds inconsistently or stops responding partway through a diagnostic sequence.
Functional requests work but physical requests do not
A functionally addressed request receives activity, but the expected physically addressed exchange with the target ECU fails.
Possible causes
Boundaries worth checking first
Incorrect diagnostic addressing
A possible cause is a mismatch in request and response CAN identifiers, physical or functional addressing, logical DoIP addresses, or gateway routing.
ISO-TP configuration mismatch
On CAN-based diagnostics, addressing format, padding, flow-control behavior, or transport timing may not match the ECU configuration.
DoIP route is not established
On Ethernet-based diagnostics, discovery, routing activation, TCP connectivity, or the selected logical target may be incomplete or incorrect.
Diagnostic session or state prerequisite
The requested service may depend on an active diagnostic session, security state, vehicle condition, or a preceding request in the workflow.
Request timing or tester configuration
Tester-present handling, response timeouts, inter-request timing, channel selection, or diagnostic database configuration may not match the target system.
Ordered investigation
Diagnostic workflow
- 01
Confirm ECU availability
Verify that the ECU is powered, awake, and participating in the expected vehicle network before interpreting the issue as a UDS failure.
- 02
Confirm lower-level communication
Check whether the expected CAN, CAN-FD, or Ethernet traffic is present and whether the diagnostic path reaches the relevant network.
- 03
Verify diagnostic addressing
Confirm tester and ECU addresses, request and response identifiers, physical versus functional addressing, and relevant gateway routing.
- 04
Check transport configuration
For CAN-based diagnostics, inspect ISO-TP addressing, flow control, padding, and timing. For Ethernet, verify the active DoIP communication path.
- 05
Send a minimal known request
Use a simple service known to be supported by this ECU and state to determine whether basic request and response communication functions.
- 06
Check session and state requirements
Verify whether the service requires a particular diagnostic session, security level, vehicle state, or earlier step in the request sequence.
- 07
Analyze synchronized traces
Compare request timing, transport frames, responses, network state, and surrounding ECU behavior to isolate the first broken boundary.
Verification gates
Technical checks
ECU traffic present?
Observe the target network and determine whether the ECU transmits expected application or network-management traffic.
Expected
The ECU participates in the expected network communication for the current vehicle state.
If failed
Investigate power, wake-up, network state, gateway routing, or ECU availability before continuing with UDS-level analysis.
Correct diagnostic addressing?
Compare the configured tester and target addressing with the ECU and diagnostic database definition.
Expected
Requests reach the intended ECU address and responses are monitored at the matching source address or CAN identifier.
If failed
Correct the physical or functional address, request and response identifiers, or gateway route before evaluating service behavior.
ISO-TP configuration valid?
For diagnostics over CAN, inspect addressing mode, consecutive frames, flow control, padding, and transport timing.
Expected
The request is transported completely and any multi-frame response can be received without transport errors.
If failed
Align the tester and ECU ISO-TP settings, then repeat the smallest reproducible request.
UDS request transmitted?
Confirm in the trace that the intended service identifier and parameters leave the tester on the selected channel.
Expected
The complete request appears on the expected transport path with the intended payload.
If failed
Review tester configuration, channel selection, diagnostic database mapping, and request construction.
Response present below the application layer?
Check for transport frames, acknowledgements, routing activity, or a response at an address the tester is not currently monitoring.
Expected
Any ECU response is captured and associated with the original request.
If failed
Continue at the ECU, gateway, and network boundary instead of assuming a decoder or presentation problem.
Required diagnostic session active?
Confirm the ECU is in the required diagnostic session and that timing or tester-present behavior has not allowed it to revert.
Expected
The required session remains active when the service request is sent.
If failed
Enter the supported session using the correct sequence and verify any related state or security prerequisite.
From evidence to action
Resolution paths
Restore the communication path
Correct power, wake-up, network routing, addressing, or transport configuration when the request never reaches an available ECU.
Correct the diagnostic sequence
Adjust session, security, timing, or service prerequisites when the transport works but the requested workflow is not valid in the current state.
Escalate with trace evidence
When the failure remains inside the ECU or gateway, preserve a minimal request and synchronized trace that identifies the first missing or unexpected behavior.
FAQ
Questions that shape the investigation
- Should I debug UDS before checking the vehicle network?
- No. First confirm that the ECU is available and that the lower communication layers carry the expected traffic. This prevents a power, wake-up, routing, or transport issue from being mistaken for a UDS service problem.
- Can an addressing mismatch look like an ECU timeout?
- Yes. A request can be valid in shape but sent to the wrong CAN identifier, logical address, or route, while the tester monitors a different response address.
- Does a missing response always mean the ECU rejected the service?
- No. A rejected service normally produces a negative response when communication is working. No response can also indicate ECU availability, routing, addressing, transport, or tester configuration problems.
Diagnostic support
Still not finding why the ECU is not responding?
If you have CAN traces, CANoe logs, diagnostic requests, DBC or ODX data, or a description of the failing workflow, I can help investigate the communication path.