UDS troubleshooting
An ECU returns a negative response when a diagnostic request should succeed, or returns a code inconsistent with the expected flow. This guide helps establish whether the deviation comes from diagnostic state, security access, request interpretation, transport handling, or ECU behavior.
Start the diagnostic workflowObservable symptoms
The ECU answers with a negative response code instead of the expected positive response for a DID read, routine control request, or another UDS operation. Compare the exact request and response bytes with the expected diagnostic flow before treating the code as an ECU defect.
An identical request produces different negative response codes, or changes after a session change, security access sequence, delay, or ECU restart. This distinguishes state-dependent behavior from a consistently malformed request.
The ECU reports a condition such as unavailable service or incorrect state even though the test believes the required setup was completed. Check whether the request reached the intended ECU and whether the ECU retained the diagnostic session and security state.
The request shown by the diagnostic application does not match the request captured in the BLF recording, or the response is decoded differently from the raw communication. This points toward data-description, addressing, or transport interpretation issues rather than an immediate ECU logic conclusion.
Possible causes
The requested service is restricted to a diagnostic session that was not entered, was not accepted, or was lost before the request. Session changes can also alter service availability and timing, producing a negative response that appears inconsistent when the preceding exchange is omitted.
A protected service can remain unavailable when the required security access sequence was not completed, was performed at an unsuitable point in the flow, or is no longer valid. The resulting response must be interpreted against the ECU's current diagnostic state, not only the final request.
An invalid service parameter, DID, routine-control parameter, or data length can cause the ECU to reject a request that is otherwise valid in concept. An ODX or PDX mismatch can make the diagnostic application construct or decode the exchange incorrectly.
Incorrect addressing or endpoint selection can produce a valid-looking negative response from an unintended ECU, or cause the expected ECU's response to be interpreted against the wrong diagnostic description. This is especially important when the same service is available on multiple ECUs.
An ISO-TP or DoIP exchange can be assembled, filtered, timed, or decoded incorrectly. The application may then associate a response with the wrong request or interpret incomplete diagnostic data as an unexpected negative response.
The ECU or its Diagnostic Communication Manager may enforce a precondition, timing rule, or service restriction that differs from the available diagnostic description or expected flow. This requires evidence from the complete exchange and may need software-owner investigation.
Ordered investigation
Use the problem description and a BLF recording, where available, to document the triggering request, the complete negative response, preceding session and security access traffic, repetition, and timing. This separates an observed protocol result from an application display or decoding artifact.
Verify that the request and response belong to the intended ECU and that the selected transport path is the one used by the test. This rules out a wrong endpoint, filtered traffic, and basic ISO-TP or DoIP association errors without changing ECU state.
Read the exchange in order and identify the active diagnostic session, any security access exchange, and the interval between setup requests and the failing request. This narrows whether the response is consistent with an unestablished or expired state, but does not by itself prove ECU nonconformance.
Compare the raw request and response with the applicable ODX or PDX data and the intended UDS operation. Check service parameters, DID or routine-control data, lengths, and response decoding. This rules out data-description and application mapping errors before deeper ECU debugging.
Repeat the smallest diagnostic sequence that establishes the required session and security state, then issue the failing request while recording every exchange. Compare repeated outcomes and state transitions to distinguish a deterministic precondition from timing-sensitive or intermittent behavior.
If endpoint, transport, state, and request data are consistent but the response remains unexpected, compare the result with the ECU diagnostic implementation and DCM configuration. The evidence can support an engineering analysis or supplier/OEM investigation rather than a local correction.
Verification gates
Read the complete response in the BLF recording and identify the negative response structure and its associated service request. Compare it with the value displayed by the diagnostic application.
The raw exchange and application interpretation identify the same request and negative response code without missing or merged transport data.
Investigate response decoding, transport assembly, filtering, and endpoint association before diagnosing ECU behavior.
Compare the addressing and endpoint information for the request and response with the intended ECU entry in the ODX or PDX data.
The request reaches the intended ECU and the response is associated with that same ECU and diagnostic description.
Correct endpoint selection or diagnostic-data mapping and repeat the capture.
Inspect whether the expected session transition was requested, accepted, and still active immediately before the failing service.
The required diagnostic session is accepted and no intervening exchange or timeout indicates that the ECU returned to another state.
Repeat the defined session sequence and investigate session timing or DCM configuration if the state is not retained.
Review the security access exchange and its position relative to the protected request, without assuming that a prior successful exchange remains valid indefinitely.
The required security state is established before the protected operation and remains applicable when the request is sent.
Repeat the required security access flow according to the approved diagnostic definition, or involve the ECU software owner if the state changes unexpectedly.
Compare the service identifier, DID or routine-control parameters, data length, and encoded values in the recorded request with the ODX or PDX definition.
The request matches the diagnostic-data definition and the operation's required parameters.
Correct the diagnostic application, CAPL script, or diagnostic data mapping before attributing the response to the ECU.
Inspect the complete ISO-TP or DoIP exchange for segmentation, missing parts, ordering, and timing relevant to the request and response.
The request and response are complete, correctly associated, and decoded without transport-level gaps.
Investigate transport configuration, capture filtering, and request/response correlation in CANoe or the diagnostic application.
From evidence to action
If the response is caused by missing or misplaced setup, update the test or diagnostic application to establish the required diagnostic session and security access state before issuing the protected request. Preserve the complete exchange in regression evidence.
If ODX or PDX data does not match the ECU behavior, correct the diagnostic-data version or the request construction and verify the resulting raw exchange. Update the CAPL script or diagnostic application only after the intended request is clear.
If the request is sent to the wrong ECU or the ISO-TP or DoIP exchange is misassembled or misinterpreted, correct addressing, transport configuration, filtering, or response correlation, then repeat the controlled reproduction.
If the request, state, endpoint, and transport are consistent but the ECU still returns an unexpected code, document the complete evidence and compare it with the ECU and DCM diagnostic configuration. Resolution may require an ECU software correction or supplier/OEM investigation rather than a local test change.
FAQ
Diagnostic support
If the exchange remains inconsistent after the basic checks, an engineering analysis can organize the recording, diagnostic data, state sequence, and findings into a reproducible technical investigation.