ISO 15765-2:2016: Large Payload Extensions

Two escape sequences that push classic ISO-TP past its original limits

What's on this page? Classic ISO-TP (ISO 15765-2, published 2003) tops out at 4 095 bytes per message and 7 bytes per single frame. The 2016 revision adds two escape sequences for bigger payloads, mostly to keep up with CAN FD (Flexible Data-Rate), which lets a single CAN frame carry up to 64 bytes. Neither escape touches the FC/CF handshake. They only change how the first frame's header is encoded.

Quick recap: classic ISO-TP frame headers

Before the extensions, a quick reminder of the four classic frame types and how their first byte(s) encode the frame type and length.

Single Frame (SF) - up to 7 data bytes

Classic SF Normal addressing, 3-byte payload example

PCI
SF, len=3

data[0]

data[1]

data[2]

pad

Upper nibble 0 = SF, lower nibble = payload length. Max 7 on classic CAN, 6 with extended addressing.

First Frame (FF): 12-bit length, up to 4 095 bytes total

Classic FF Normal addressing, total length = 200 bytes (0x0C8)

PCI hi
FF, len hi

PCI lo
len lo

data[0]

data[1]

data[2]

data[3]

data[4]

data[5]

Two-byte header: 0x1 (FF) plus a 12-bit length, max 0xFFF = 4 095. Six data bytes ride along in the FF itself, the rest follows in Consecutive Frames.

Extension 1: CAN FD Single Frame escape (SF_DL = 0)

Classic SF stores its length in the lower nibble of the PCI byte, which caps it at 15, but only 7 bytes are ever valid on classic CAN since the rest of the byte has to be data. CAN FD frames can carry up to 64 bytes, so a single frame needed a way to carry more than 7 bytes of payload.

The fix: when the lower nibble is 0, the next byte carries the real length instead. That's the SF escape sequence.

Classic CAN only matters here in theory. The SF escape is meaningless on classic 8-byte CAN: a payload over 7 bytes can't fit in one frame regardless of how the length is encoded. This extension only does anything on CAN FD hardware.

SF escape frame format

New in 2016 SF escape - 12-byte payload on CAN FD (frame size = 16 bytes)

PCI
SF escape

SF_DL
length=12

data[0]

data[1]

data[2]

data[3]

data[4]

data[5]

data[6]

data[7]

data[8]

data[9]

data[10]

data[11]

pad

Byte 0 (0x00) signals the SF escape, byte 1 (0x0C = 12) gives the actual payload length. The remaining 12 bytes are data, padded out to the next CAN FD frame size (16 bytes here). Still a single frame, so no FC exchange needed.

Classic SF vs FD SF escape, same 12-byte payload

Tester7E1

ECU7E9

Classic CAN: the 12-byte request needs 3 frames (FF, FC, CF):

0 µs

10 0C D0 D1 D2 D3 D4 D5

→ ECU

310 µs

30 00 00

← Tester

620 µs

CF #1

21 D6 D7 D8 D9 DA DB CC

→ ECU

vs.

CAN FD: the same 12-byte request fits in one single frame, no FC needed:

0 µs

SF (FD)

00 0C D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB CC CC CC

→ ECU

Extension 2: 32-bit First Frame escape (FF_DL = 0)

The classic FF header stores total message length in a 12-bit field, capping it at 4 095 bytes. The 2016 revision repurposes 0x000 as an escape: when that 12-bit field reads zero, the next four bytes carry the real length as a 32-bit big-endian integer, pushing the limit out to roughly 4 GB (4 294 967 295 bytes).

This one works on classic CAN too. Unlike the SF escape, it isn't tied to CAN FD. An 8-byte classic CAN frame can fit the 6-byte header (10 00 plus 4 length bytes) and still carry 2 data bytes, with the rest following in normal Consecutive Frames. Handy for large firmware transfers over classic CAN.

32-bit FF escape frame format

New in 2016 FF escape - total length = 5 000 bytes (0x00001388), classic CAN

PCI hi
FF type

PCI lo
escape=0

len[3]
MSB

len[2]

len[1]

len[0]
LSB

data[0]

data[1]

10 00 is an FF with a 12-bit length of zero, so it's escape mode. The next 4 bytes give the total length, big-endian: 0x00001388 = 5 000. Only 2 data bytes fit in the classic CAN FF itself; the remaining 4 998 bytes follow in 714 Consecutive Frames of 7 bytes each.

Full exchange: 5 000-byte transfer, classic CAN (BS=0, STmin=0)

Sender7E1

Receiver7E9

0 µs

FF (escape)

10 00 00 00 13 88 D0 D1

→ Receiver

310 µs

FC (CTS)

30 00 00

← Receiver

620 µs

CF #1

21 D2 D3 D4 D5 D6 D7 D8

→ Receiver

930 µs

CF #2

22 D9 DA DB DC DD DE DF

→ Receiver

1 240 µs

CF #3

23 E0 E1 E2 E3 E4 E5 E6

→ Receiver

… CF #4 through CF #713 (same pattern, SN wraps 0–F) …

222 ms

CF #714 (last)

2A F6 F7 F8 F9 FA FB FC

→ Receiver

SN=0xA on the last CF because 714 mod 16 = 10 = 0xA. Timing assumes 500 kbps and no STmin delay. Everything else, FC, CF structure, SN wrap-around, works exactly like classic multi-frame.

How a receiver tells the two FF types apart

It just reads the first two bytes of the FF:

Upper nibble 0x1 with the lower 12 bits non-zero: classic FF, length is those 12 bits.
Bytes 0-1 exactly 10 00: escape FF, read the next 4 bytes as a 32-bit big-endian length. Data starts at byte 6.

Summary comparison

Property	Classic SF	FD SF escape	Classic FF/CF	32-bit FF escape
Defined in	ISO 15765-2:2003	ISO 15765-2:2016	ISO 15765-2:2003	ISO 15765-2:2016
PCI trigger	`0x01`–`0x07`	`0x00` + length byte	`0x10`–`0x1F`, low 12 bits ≠ 0	`0x10 0x00` + 4-byte length
Max payload	7 bytes	62 bytes (CAN FD)	4 095 bytes	4 294 967 295 bytes (~4 GB)
FC exchange needed	No	No	Yes	Yes
Works on classic CAN	Yes	No (pointless)	Yes	Yes
Works on CAN FD	Yes	Yes	Yes	Yes
Typical use case	Short diagnostic requests/responses	Medium responses on CAN FD ECUs	Most multi-frame UDS services	Firmware transfers, large data uploads

Practical note: most automotive ECUs on classic CAN buses still only implement the 2003 standard. You'll mainly find the 32-bit escape and FD SF escape on ECUs with CAN FD hardware, newer body control modules, gateway ECUs, ADAS controllers and the like. Check the ECU's communication spec before assuming either escape is supported.