CAN TP
Once you understand classic CAN and CAN FD, the next natural thought is: if one frame cannot hold the data, why not just split it in application code and send multiple frames? That can work in the simplest experiments, but once a real system is involved, problems appear quickly: how does the receiver know where the long message starts and ends, what happens if one frame is missing, what if the sender transmits too fast for the receiver to keep up, and what if both directions have large messages at the same time?
The most important judgment about CAN TP is this: it is not there to replace CAN arbitration. It adds the smallest necessary transport order on top of a small-frame broadcast bus so that long messages can be split, delivered, and reassembled without turning the receiver and the bus into a mess. It is not about who wins first; it is about how one logical long message gets divided, delivered, and reconstructed.
Why “Just Split the Frames Yourself” Stops Being Enough Quickly
At a glance, splitting 40 bytes into five classic CAN frames does not sound hard. What is hard is treating those five frames as one message again, and making sure the sender, receiver, and capture analysis all recognize that relation consistently.
Without a shared transport-layer convention, several kinds of problems show up immediately.
First, message boundaries are unclear. The receiver sees a stream of CAN frames but does not know which frame is the start, what the total length is, or whether this frame belongs to the previous message or the next one. Second, the pacing gets out of control. If the sender blasts all fragments onto the bus at once, the receiver buffer may not keep up, and other traffic will be squeezed out. Third, exceptions become impossible to judge. If a frame is lost, out of order, or times out, the application has no shared sequence or timeout meaning and can only say “the data is wrong,” without knowing where the failure happened.
That is the background for CAN TP. It optimizes first for reassembly, controlled rate, and diagnosability, not for the lowest possible overhead.
The Smallest CAN TP Mental Model
Think of CAN TP as “a segmentation and flow-control layer stacked on top of CAN frames.”
It has to do at least four things:
- tell the receiver where a long message starts and what its total length is
- deliver the following fragments in order and let the receiver know whether it is falling behind
- let the receiver tell the sender how much more it can accept and at what pace
- if any step times out, is missing, or has the wrong sequence number, stop this transfer quickly instead of handing bad data to the upper layer
As long as those four things are clear, the frame types and parameters start making sense. Otherwise CAN TP just looks like a vocabulary quiz about frame headers.
The Main Path Is Actually Simple
The easiest way to understand CAN TP is to follow one successful path from beginning to end.
When the sender sees that a message does not fit in one frame, it does not just start spamming frames. It first sends a First Frame. That frame is not there to carry a lot of useful payload; it tells the receiver: “this is not a single-frame message, and the total length is this much, so get ready.”
If the receiver is willing to continue, it sends back a Flow Control frame. That frame says at least two things: I am allowed to receive more now, and this is the pace you should use. Common control values include the block size, meaning how many consecutive frames are allowed in one burst, and the minimum separation time, meaning how much gap must exist between consecutive frames.
Only after that permission does the sender start a stream of Consecutive Frames. These frames are not just “later chunks.” They also carry a growing sequence number so the receiver can detect missing, reordered, or duplicate fragments.
If everything succeeds, the receiver reassembles the full message and the transfer ends.
The main idea is simple: a long message is not just “send whenever you can.” It is first declared by length, then paced by the receiver, and finally protected by sequence numbers and timeouts.
What Each Key Mechanism Is Covering
First Frame solves the boundary problem. Without it, the receiver does not know how many frames are coming or how much buffer to reserve.
Flow Control solves the backpressure problem. Classic CAN ACK only says a frame arrived at the link layer. It does not say the receiver’s upper-layer buffer, reassembly state, or processing capacity can absorb the whole long message. CAN TP lets the receiver explicitly participate in pacing so the sender does not overrun it.
Consecutive Frame plus sequence numbers solve the ordering problem. Once fragmentation gets large, “all the frames seem to be here” is not enough. The receiver must know exactly which fragment it is looking at.
Timeouts solve the hanging problem. If the sender waits too long for Flow Control, or the receiver waits too long for the next fragment, the transfer should end. Otherwise both sides can sit in a half-open state, holding buffers without producing a clear result.
Where It Sits Relative to Classic CAN and CAN FD
This is where layers are easy to mix up.
Classic CAN and CAN FD solve link-layer questions: how the bus arbitrates, how frames are sent, and how errors are detected. CAN TP solves transport-layer questions: how a long message crosses multiple frames and still gets delivered as a coherent object.
That means several things must stay separate.
First, CAN TP does not decide who gets bus access first. Arbitration priority is still governed by CAN IDs and the underlying bus rules. Second, CAN TP does not guarantee business success. It only guarantees whether a long message was delivered according to transport rules. Third, the arrival of CAN FD changes CAN TP’s practical boundary, but it does not make CAN TP disappear automatically.
That last point is easy to misjudge. Once CAN FD expands a single frame to as much as 64 bytes, many messages that previously had to be segmented can be sent in one frame. So CAN TP use may drop. But as long as messages can still exceed the single-frame limit, or a system is built around a diagnostic/calibration stack that already relies on ISO-TP, CAN TP still has real value.
The Most Common Field Problems
When diagnosing CAN TP, do not only look at whether data arrived.
First, do not look only at consecutive frames and ignore flow control. Many “the transfer stops halfway” cases are not caused by a bad sender. The receiver may not have responded with Flow Control, may have responded too slowly, or may have chosen a block size and minimum separation time that force the sender into a different rhythm.
Second, do not look only at bus load and ignore the receiver buffer. The bus may look calm while the receiver still cannot reassemble fast enough. Some problems are really MCU buffer, task scheduling, or driver-copy speed issues rather than physical-layer bandwidth issues.
Third, do not treat timeouts as random network jitter. CAN TP timeouts are often highly informative. They do not just mean “things were a little slow.” They suggest that the sender and receiver state machines have already diverged. Before retrying, figure out whether the problem is “no Flow Control after First Frame” or “the Consecutive Frame sequence stopped halfway.”
Fourth, do not treat it as an application-private convention. You can invent your own fragmentation format for a while, but over time analysis tools, gateways, diagnostic stacks, and cross-team collaboration all get worse. One of CAN TP’s values is that it pulls this common problem out of business code.
When CAN TP Should Be Considered First
If your messages frequently exceed the single-frame limit, and the receiver’s processing speed, buffer capacity, or diagnostic tool chain all need a clear segmentation rule, CAN TP is worth considering first.
Typical cases include:
- diagnostic requests and responses that often exceed one frame
- calibration, flashing, or large parameter transfers that need stable segmentation
- systems that want to unify long-message timeout, sequence, and pacing rules
- capture, debugging, and cross-team interface definition that need a shared transport meaning
On the other hand, if all messages fit in one frame, or only a tiny fraction ever exceeds the limit, the value of introducing CAN TP is much smaller. In that case you should first ask whether CAN FD single-frame support is enough.
Three Final Judgments
To understand CAN TP, the most important thing is not to memorize frame abbreviations first. It is to remember three points.
First, CAN TP solves the order of long-message transfer across multiple frames, not the arbitration problem of the underlying bus. Second, First Frame, Flow Control, and Consecutive Frame are respectively handling boundary declaration, receiver backpressure, and fragment order. Third, when you debug in the field, the most informative signals are often not payload content, but length declaration, flow-control rhythm, sequence continuity, and timeout points.
If you use those three judgments when looking at diagnostic logs, captures, and implementation code, you will build a stable model faster than by memorizing the first-byte encoding table. Field tables can always be looked up later. If the state machine never becomes clear, debugging costs go up quickly.