Incorrect ISO-TP addressing
The diagnostic application or CanTp configuration uses an incorrect source or target addressing configuration, so valid CAN traffic is ignored or transmitted where the receiving transport endpoint does not expect it.
ISO-TP troubleshooting
ISO-TP communication failure
A segmented UDS exchange over CAN stops, times out, or produces an incomplete message. This guide helps establish whether the fault is in CAN communication, ISO-TP addressing, flow-control handling, or timing behavior.
Start the diagnostic workflowObservable symptoms
What the failure can look like
A multi-frame request stops after the first frame
The trace contains an initial ISO-TP frame, but no subsequent consecutive frames are sent or received. This differs from a rejected UDS request, where a complete diagnostic response is still visible.
The sender waits indefinitely or times out after a flow-control frame
A flow-control frame is present, but the next consecutive frame does not arrive within the expected timing. This points toward flow-control interpretation, timing, or transport state handling rather than an absent ECU response alone.
A diagnostic response is truncated or marked incomplete
The receiver observes only part of a segmented UDS response, with the declared message length not reached. A single-frame response that contains a negative response is a different condition because its transport exchange completed.
Traffic appears on CAN but the diagnostic application reports no response
CAN traffic is visible in a BLF recording or ASC recording, but the application does not associate it with the expected ISO-TP exchange. This commonly distinguishes addressing or configuration problems from a silent ECU.
Repeated requests produce inconsistent transport results
The same request sometimes completes and sometimes stops at different points in the exchange. Intermittent behavior is more consistent with timing, state-reset, or bus communication conditions than with a permanently incorrect request format.
Possible causes
Boundaries worth checking first
Flow-control parameters are not accepted or applied correctly
The receiving side does not send the expected flow-control behavior, or the sender misinterprets the flow-control information. The segmented transfer then pauses, overruns the permitted timing, or terminates before completion.
Transport timing mismatch
The interval between transport messages exceeds the receiving side's permitted timing, or the implementation starts its timeout at the wrong transport event. This can make an otherwise valid exchange appear incomplete.
CAN communication is missing or unreliable
The required CAN messages are not transmitted, are not received by the intended endpoint, or are disrupted by bus communication conditions. ISO-TP then cannot maintain its segmented exchange even when its own state handling is correct.
CanTp transport state is not reset between exchanges
A previous incomplete transfer leaves the transport module in an active or blocked state. A later UDS request can then be ignored, rejected internally, or associated with the wrong exchange state.
The UDS exchange is being interpreted as an ISO-TP failure
The transport exchange may complete, but the diagnostic service response is negative or not the response expected by the application. Separating transport completion from UDS service interpretation prevents a service-level issue from being diagnosed as ISO-TP.
Ordered investigation
Diagnostic workflow
- 01
Define the failing exchange
Record the request, expected response, reproduction conditions, and the exact point where the exchange stops. Use this to distinguish a transport interruption from a completed exchange with an unexpected UDS result.
- 02
Inspect the raw CAN evidence
Review the relevant interval in the BLF recording or ASC recording and determine whether the expected CAN traffic exists in both directions. This rules out an application-only observation before transport behavior is analyzed.
- 03
Reconstruct the ISO-TP sequence
Identify the transport message sequence, declared message length, flow-control behavior, and consecutive-message progress. This narrows the failure to missing traffic, addressing, flow control, or timing without changing the vehicle configuration.
- 04
Compare addressing and transport configuration
Compare the observed CAN traffic with the configured source and target addressing and with the CanTp configuration used by the diagnostic application. This can rule out an endpoint mismatch but cannot prove that the ECU implementation is correct.
- 05
Check timing and state transitions
Measure the intervals between the relevant transport messages and repeat the exchange after a clearly completed or reset state. This separates a repeatable timing problem from stale transport state or intermittent CAN behavior.
- 06
Separate transport completion from UDS interpretation
After confirming that the complete transport exchange is present, inspect whether the payload is a positive or negative UDS response. If transport completes, continue the investigation at the UDS service level rather than changing ISO-TP parameters.
Verification gates
Technical checks
Verify both CAN directions
In the BLF recording or ASC recording, compare the expected request direction with the expected response direction and confirm that the relevant CAN messages occur during the same exchange.
Expected
The request and response-side transport messages are present in the expected order and direction.
If failed
Missing traffic points first to CAN availability, endpoint configuration, or ECU behavior; inspect the CAN evidence and ECU before changing UDS interpretation.
Verify the declared segmented length
Compare the length declared by the initial ISO-TP message with the total payload reconstructed from the received transport messages.
Expected
The reconstructed payload reaches the declared length without extra or missing consecutive messages.
If failed
A short payload indicates interrupted transport, flow-control, timing, or CAN loss; an inconsistent declared length indicates an addressing or transport implementation issue.
Verify flow-control handling
For a segmented transfer, read whether the receiving side sends the expected flow-control response and whether the sender continues according to that response.
Expected
The flow-control exchange is present, consistently associated with the transfer, and followed by the permitted consecutive-message transmission.
If failed
No flow-control response suggests an endpoint, addressing, or receiver-state problem; an incorrect continuation suggests sender or CanTp handling.
Measure inter-message timing
Measure the time between the relevant initial, flow-control, and consecutive transport messages in the recording and compare repeated exchanges.
Expected
The intervals remain within the configured and expected transport timing for the exchange.
If failed
Excessive or variable intervals indicate timing handling, scheduling, CAN availability, or transport load concerns; inspect the responsible endpoint and CanTp state.
Confirm transport state after an interrupted exchange
Repeat the request after the failed exchange has ended and compare the first transport response with a clean exchange.
Expected
A subsequent exchange starts normally and is not affected by the previous interruption.
If failed
Failure only after an interruption suggests transport state was not cleared or the endpoint remains occupied; inspect CanTp reset and error-handling behavior.
Distinguish a complete UDS response from a transport failure
After reconstructing the payload, determine whether the complete payload is a UDS positive response or a UDS negative response.
Expected
The complete payload is classified separately from transport status, with no missing ISO-TP data.
If failed
If the payload is complete but unexpected, investigate the UDS request, diagnostic session, or service behavior rather than treating it as an ISO-TP interruption.
From evidence to action
Resolution paths
Correct endpoint and transport configuration
Align the diagnostic application and CanTp configuration with the addressing and CAN traffic observed in the failing exchange. Re-run the same request and verify the complete segmented sequence rather than relying only on an application status.
Fix flow-control and timing handling
Correct the sender or receiver behavior that fails to process flow-control information or maintain the required timing. Validate with repeated segmented exchanges and retain recordings showing both successful and failed cases.
Repair CAN-side communication conditions
Resolve the missing or unreliable CAN communication identified in the trace, then repeat the ISO-TP exchange. If the required traffic is absent from the available ECU, the ECU integration or vehicle-side team may need to investigate the cause.
Reset and harden transport state handling
Ensure that interrupted transfers leave CanTp in a usable state and that a later request cannot inherit stale exchange state. Add repeatable tests covering interruption followed by a new segmented request.
FAQ
Questions that shape the investigation
- How can an ISO-TP failure be distinguished from an ECU not responding?
- Check the raw CAN evidence first. If no expected response-side traffic exists, the issue may involve CAN communication, addressing, ECU behavior, or endpoint configuration. If partial transport traffic exists, the ECU is communicating but the segmented exchange is failing at a specific transport stage.
- Does a UDS negative response prove that ISO-TP failed?
- No. A complete negative UDS response shows that transport may have completed while the diagnostic service rejected or could not perform the request. Classify the reconstructed transport exchange before analyzing the UDS result.
- What does a missing flow-control response indicate?
- It indicates that the receiving transport endpoint did not provide the expected flow-control behavior, or that the message was not received or associated with the active exchange. Check CAN direction, addressing, receiver state, and CanTp handling before assigning a single cause.
- Why can the same request work once and fail later?
- Intermittent results can arise from timing variation, CAN communication conditions, or transport state that was not cleared after an earlier interruption. Compare successful and failed recordings and check whether the failure begins at the same transport stage.
- What evidence is most useful for this diagnosis?
- A problem description establishes the reproduction and expected behavior, while a BLF recording or ASC recording shows the timestamped CAN exchange. The ECU and relevant transport configuration are needed to compare observed behavior with the intended endpoint and CanTp handling.
Diagnostic support
Discuss an ISO-TP Project
If the transport trace needs a focused engineering analysis, diagnostic application, or repeatable test coverage, provide the failing exchange and available recording.