ISO-TP Frame Calculator
How many CAN frames does a UDS message need? Enter the payload length, pick classic CAN or CAN FD and flow control: first, consecutive and flow-control frames and timing.
Updated This page as Markdown
In short
This calculator shows how ISO 15765-2 (ISO-TP) segments a diagnostic message: whether it fits a single frame, how many consecutive frames and flow-control frames a segmented transfer needs on classic CAN (8 bytes) or CAN FD (64 bytes), with normal or extended addressing, and the minimum transfer time implied by the separation time STmin. It also flags the escape sequence for payloads above 4095 bytes.
The UDS message, for example 300 bytes of TransferData.
0 = no further flow control after the first.
0 to 127 = ms; 241 to 249 = 100 to 900 µs.
Segmentation
Segmented transfer
- First frame
- 1
- Consecutive frames
- 42
- Flow-control frames
- 1
- Frames in total
- 44
- Bytes on the bus
- 347
- Minimum time from STmin
- 0 ms
First frames
- First frame112C + 6 B
- Consecutive frames 121 + 7 B
- Consecutive frames 222 + 7 B
- Consecutive frames 323 + 7 B
- Consecutive frames 424 + 7 B
- … 38 more consecutive frames
How it works
ISO 15765-2 puts a protocol control information (PCI) byte in front of the payload. A single frame (PCI 0x0L) carries the whole message; a first frame (0x1LLL) announces the length and carries the first bytes; consecutive frames (0x2N) carry the rest with a 4-bit sequence number; and the receiver answers the first frame with a flow-control frame (0x3S BS STmin) that sets block size and separation time. The calculator applies those rules for 8-byte classic frames and 64-byte CAN FD frames, subtracts one byte per frame for extended or mixed addressing, and counts flow controls from the block size.
The minimum time is consecutive frames minus one, times STmin. It ignores bus arbitration, the time of the frames themselves and the P2 timing of the application layer, so it is a lower bound.
How to read the result
Use it to sanity-check traces and to size tests. A 300-byte TransferData block on classic CAN takes 1 first frame plus 42 consecutive frames; with STmin 10 ms that is at least 410 ms per block, which explains why programming a 1 MB image over CAN takes minutes and why CAN FD matters for flashing. If a trace shows fewer consecutive frames than the calculator predicts, the transfer was aborted; if the receiver sent more flow controls than expected, its block size is smaller than advertised.
Limits
The tool models the standard, not an implementation. It does not know the ECU’s actual block size and STmin, nor whether it supports CAN FD single frames above 7 bytes or the escape sequence. Those are exactly the transport-layer behaviours AutoST exercises in its fuzzing stage: wrong sequence numbers, oversized first frames, flow control with impossible parameters and frames after the announced length.
FAQ
Frequently asked questions
What do block size and STmin mean?
Both come from the receiver in the flow-control frame. Block size (BS) is how many consecutive frames the sender may transmit before waiting for the next flow control; 0 means all of them. STmin is the minimum gap between consecutive frames: 0x00 to 0x7F are milliseconds, 0xF1 to 0xF9 are 100 to 900 microseconds. An ECU that advertises STmin 0 and then drops frames is a finding.
Why does CAN FD change the single-frame limit?
With classic CAN a single frame carries up to 7 payload bytes (one PCI byte). CAN FD frames hold 64 bytes, and for payloads above 7 bytes ISO 15765-2 uses a two-byte PCI (0x00 followed by the length), so a single frame carries up to 62 bytes. Many ECUs implement only the classic rules even on FD buses; the calculator lets you compare.
What is the escape sequence?
A classic first frame encodes the length in 12 bits, so 4095 bytes is the maximum. For longer messages the first frame carries 0x10 0x00 and a 32-bit length in the next four bytes. Not every ECU supports it; sending it is one of the first things a transport-layer fuzzer tries.
Sources
Related pages
- GlossaryISO-TP (ISO 15765-2)ISO-TP (ISO 15765-2) splits UDS messages into CAN frames: single, first, consecutive and flow-control frames. How it works and why malformed frames crash ECUs.
- GlossaryCAN FD (CAN with Flexible Data Rate)CAN FD extends classic CAN to 64 data bytes and a faster data phase. How the DLC, BRS bit and bit timing work and what changes for diagnostics and fuzzing.
- GlossaryCAN Bus (Controller Area Network)CAN (ISO 11898) is the broadcast bus most ECUs share: identifiers, arbitration, error handling. Why any node can send any frame and what that means for security testing.
- PlatformBreak it on the bench, not in the field.AutoST fuzzes ECUs over UDS and CAN with reproducible seeds and live crash detection via TesterPresent and DTC monitoring. Built for benches, never for the road.
- PlatformSpeaks the buses your ECUs speak.AutoST supports CAN, CAN FD, ISO-TP, UDS, XCP, CCP, DoIP and SOME/IP, with SocketCAN, Vector XL and comma.ai Panda adapters on Windows and Linux.
