DTC troubleshooting
The same diagnostic trouble code reappears after a clear operation, a restart, or a repeat drive condition. This guide helps establish whether the monitored fault is still present, the ECU is evaluating the event as expected, or the diagnostic path is misreading or failing to clear the record.
Start the diagnostic workflowObservable symptoms
A diagnostic application clears the record, then reads the ECU again and finds the same DTC without reproducing the vehicle condition. This points toward an active event, an unsuccessful clear operation, or a readback and interpretation issue rather than proving that the physical fault is continuously present.
The record is absent directly after clearing but reappears after the ECU restarts or the relevant operating condition occurs. This distinguishes a condition evaluated during initialization or operation from a record that was not actually cleared.
The code reappears when the same vehicle state, input condition, or routine is exercised. Reproduction tied to a defined condition increases the likelihood that the monitored event remains detectable, but the event definition and supplied diagnostic data still need verification.
A diagnostic application, OBD-II view, or separate UDS readout shows different code values or status information for what appears to be the same fault. This can result from different data mappings, diagnostic descriptions, or communication paths rather than a change in the underlying event.
Possible causes
The ECU continues to detect the condition that caused the DTC, so clearing the stored record does not prevent the event from being recorded again. The return may be immediate or may wait until the condition is evaluated during operation.
The diagnostic request may target the wrong ECU, use an unsuitable diagnostic session, lack required security access, or be interrupted before the ECU commits the clear. A subsequent read can therefore expose the original record again.
The Diagnostic Event Manager can retain diagnostic event information while the event remains failed or until its configured status handling allows the record to change. A visible DTC can therefore reflect event-management behavior rather than a failed clear transport.
Incorrect or mismatched ODX or PDX data can associate a response with the wrong DTC, interpret status incorrectly, or present a stale-looking record. The ECU may be behaving consistently while the diagnostic application presents an inaccurate result.
Incomplete ISO-TP communication, a disrupted DoIP path, or an ECU communication reset can prevent the clear request or its response from being handled as intended. A later read may then show the record still present or leave the result ambiguous.
A diagnostic application, CAPL automation, or routine control sequence may immediately execute the condition that causes the event again, or may repeat a clear-and-read sequence against the wrong target. The timing of requests and DTC appearance is needed to separate this from a vehicle fault.
Ordered investigation
Record the ECU, DTC value, time of the clear request, response, ECU restart state, diagnostic session, and condition under which the code returns. This separates immediate readback from return after operation and prevents different records from being treated as one failure.
Verify that the diagnostic application addresses the intended ECU and that the associated ODX or PDX data identifies the expected DTC and status fields. This rules out a target, mapping, or interpretation error before deeper vehicle investigation.
Run one controlled clear followed by a read of the same ECU, preserving the request, positive or negative response, timing, and returned DTC information. The result distinguishes a completed clear from a rejected, interrupted, or ambiguous exchange.
Repeat the controlled exchange in the diagnostic session required by the ECU and verify whether security access is needed for the operation. This can rule out access and session restrictions but cannot prove that the physical event is absent.
After a confirmed clear, monitor the DTC while changing one relevant operating condition at a time and while avoiding unrelated routine control actions. A return synchronized with a condition supports an active monitored event; a return without that condition shifts attention toward event handling or diagnostic interpretation.
Compare the same ECU record through the available UDS and OBD-II views, and correlate the result with the captured exchange. If paths disagree, investigate descriptions and transport handling before concluding that the ECU has a persistent vehicle fault.
If the problem remains reproducible, analyze the ECU event handling and diagnostic communication implementation, including DEM status changes and DCM request processing. Use CANoe or CAPL only to reproduce and timestamp the exchange without treating a test trace as proof of the physical root cause.
Verification gates
Compare the ECU identity and addressing in the clear request and response with the ECU that reports the DTC.
The response comes from the intended ECU and indicates that the requested operation was accepted or completed.
A wrong target, unsupported operation, session restriction, or communication failure remains possible; verify ECU selection, diagnostic session, and the captured exchange.
Issue one read against the same ECU without restarting it or running another routine, then compare the returned DTC and status with the pre-clear record.
The targeted record is absent or its status reflects the ECU's documented post-clear behavior.
The clear may not have completed, the event may still be active, or the diagnostic application may be interpreting the response incorrectly.
Check that the diagnostic application uses the intended ODX content and that the PDX package contains the matching diagnostic description for the ECU and DTC.
The DTC identifier, text, status interpretation, and applicable operation agree across the loaded diagnostic data.
A data-version or mapping problem can make a correct ECU response appear to be a returning DTC; correct the description source or escalate the data mismatch.
Record the active diagnostic session and whether security access was completed before the clear operation.
The ECU is in the required session and the required access state is established before the operation.
The ECU may reject, ignore, or limit the operation; review the ECU diagnostic definition and the recorded responses rather than repeating clears blindly.
Timestamp the clear, ECU restart, relevant operating condition, routine control activity, and first subsequent DTC appearance.
A healthy diagnostic path shows no unaccounted request interruption, and a genuine event return is correlated with the condition that causes the ECU to evaluate the event.
An immediate uncorrelated return shifts attention to event status handling, automation, target selection, or diagnostic data interpretation.
Review the full ISO-TP or DoIP exchange for completed requests, complete responses, interruptions, and communication resets.
The complete clear and read exchanges are present and associated with the intended ECU.
Incomplete transport or a disrupted path can leave the clear result unknown; repeat with controlled capture before assigning the cause to the vehicle condition.
From evidence to action
If controlled reproduction shows that the ECU reliably detects the condition, repair or correct the responsible vehicle or ECU behavior, then repeat the clear-and-read verification across the condition that previously recreated the DTC.
If the clear was rejected or incomplete, use the required diagnostic session, security access, target ECU, and diagnostic sequence defined for that ECU. Confirm completion from the response and a subsequent read rather than relying on the application display alone.
If the physical condition is absent but DEM or DCM behavior recreates or retains the record incorrectly, review event status transitions, clear handling, request processing, and reset behavior in the ECU software. This normally requires the ECU software owner or supplier to implement and verify the change.
If ODX or PDX content maps the DTC or status incorrectly, align the diagnostic application with the approved diagnostic description and retest the same ECU exchange. The data owner or OEM may need to provide the authoritative diagnostic package.
FAQ
Diagnostic support
Need a documented engineering analysis or root-cause report for a DTC that keeps returning? The evidence can be organized around the ECU exchange, event timing, and diagnostic data.