OBD-II troubleshooting
Generic diagnostic parameters or trouble-code data cannot be retrieved from the vehicle. This guide helps isolate whether the failure is in the connection, CAN exchange, ISO-TP transport, ECU response, or diagnostic configuration.
Start the diagnostic workflowObservable symptoms
The diagnostic application sends a request, but the CAN trace contains no corresponding ECU response. This differs from a negative response, where the ECU answers but rejects or cannot process the request.
The CAN dump contains unrelated vehicle communication, while the expected diagnostic request and response exchange is missing or does not use the configured addressing.
The ECU returns CAN frames, but the application reports unavailable data because the response is segmented, incomplete, or interpreted with the wrong ISO-TP settings.
The request completes without a transport error, but no DTC data is returned or the result differs between repeated reads. This is distinct from a communication failure because the ECU has responded.
Possible causes
The application may send a request that does not match the vehicle's expected generic diagnostic interface or addressing configuration. The ECU then produces no usable response even though CAN communication is otherwise active.
The diagnostic request does not reach the vehicle network, or responses cannot return to the application. A CAN dump with no relevant request and response exchange supports investigating the interface and bus path before ECU behavior.
A response that exceeds one CAN frame may require segmented transport. Incorrect ISO-TP handling can make valid ECU traffic appear unavailable because the complete response is not reassembled or acknowledged correctly.
The ECU may respond without the requested parameter or trouble-code content, or the vehicle configuration may not expose that data through the expected OBD-II path. This cannot be distinguished from a request mismatch without examining the response.
If communication succeeds but no DTC data is available, the diagnostic event state may not contain an active or stored record for the requested data. The ECU's diagnostic implementation and DEM behavior may need review.
A capture or interface configuration intended for CAN may not correctly represent traffic carried with CAN-FD characteristics. The resulting trace can appear incomplete or unusable even when network communication exists.
Ordered investigation
Record the requested OBD-II data, ECU context, reproduction sequence, expected result, and whether the failure is no response, a negative response, undecodable data, or an empty result. This separates communication faults from data-content faults.
Capture the request and surrounding traffic with CANalyzer or CANoe, or inspect the supplied CAN dump. Confirm whether the request is transmitted and whether any candidate response follows it. This rules out application-only assumptions but does not by itself prove that the ECU supports the request.
For a visible response, determine whether it is a complete single-frame exchange or an ISO-TP segmented exchange. Check whether all expected transport frames are present and consistently ordered before investigating decoded values.
Check the requested generic data, addressing, response interpretation, and any application configuration against the observed CAN exchange. This narrows the issue to request construction, response selection, or unsupported data rather than general bus availability.
If the exchange is complete, inspect the response content for DTC or parameter data and compare repeated reads under the same conditions. An empty valid response shifts attention from transport to ECU diagnostic state, DEM behavior, or supported data scope.
Package the problem description, CAN dump, request and response timing, transport observations, and tool configuration as an engineering analysis. Involve the ECU supplier or OEM when the exchange is valid but the expected OBD-II data is absent or the implementation behavior is undocumented.
Verification gates
Read the CAN dump and confirm that the diagnostic application transmits the intended OBD-II request during the reproduction sequence.
The expected request appears at the time of the test and uses the configured CAN communication path.
Investigate the diagnostic application, CAN interface configuration, and physical communication path before changing ECU interpretation.
Compare the request timestamp with subsequent CAN frames and identify whether a response associated with the request is present.
A response appears consistently after the request, or the capture provides a documented reason why no response is expected.
A missing response points toward addressing, interface, CAN communication, unsupported request behavior, or ECU availability; the trace alone cannot select one cause.
Verify that the capture and analysis configuration uses the intended CAN or CAN-FD interpretation for the observed traffic.
Frames are decoded consistently without unexplained changes in frame format or missing portions of the exchange.
Review CAN/CAN-FD configuration and repeat the capture before diagnosing OBD-II data content.
For a multi-frame response, compare the CAN dump with the expected ISO-TP sequence and verify that the diagnostic application reassembles the complete payload.
The complete response is present and delivered to the decoder as one valid diagnostic payload.
Investigate ISO-TP addressing, segmentation, flow handling, and capture completeness; do not treat an incomplete payload as an ECU data failure.
Read the decoded response and determine whether it contains the requested generic parameter or DTC information, rather than only confirming that some response frame exists.
The response contains the requested data in a form the application can interpret.
Compare the request and decoder configuration, then determine whether the ECU supports or has populated the requested data.
Repeat the same request under the same vehicle and diagnostic conditions and compare the CAN exchange and decoded result.
The request, response structure, and result are repeatable.
Variable results suggest an intermittent communication, timing, ECU state, or diagnostic-event condition; retain captures from both outcomes for comparison.
From evidence to action
Align the requested generic data, addressing, response selection, and decoding configuration with the observed vehicle exchange. Re-test with a CAN trace and retain evidence that the request and response now correspond.
Correct the CAN interface configuration or communication path when the request is absent, malformed, or not followed by a usable response. Validate the repair by repeating the same capture and comparison.
Correct ISO-TP segmentation, reassembly, addressing, or flow handling when the response is present but incomplete or undecodable. Confirm that the full diagnostic payload reaches the application before evaluating its contents.
When communication and transport are valid but requested data remains empty, review the ECU's OBD-II behavior, DTC handling, and DEM-managed diagnostic state. This may require an ECU software change or supplier/OEM clarification rather than a local application fix.
FAQ
Diagnostic support
If the evidence still leaves the fault boundary unclear, request an engineering analysis or diagnostic application review based on the captured ECU exchange.