UDS TransferData (0x36) — PCAN-UDS does not transmit full ISO-TP multi-frame payload

A free API for the communication with control devices according to UDS (ISO 14229-1)
Post Reply
prashanth
Posts: 6
Joined: Wed 26. Nov 2025, 12:57

UDS TransferData (0x36) — PCAN-UDS does not transmit full ISO-TP multi-frame payload

Post by prashanth » Mon 8. Dec 2025, 13:43

Hello,
I am implementing UDS firmware update using PCAN-UDS API and I faced an issue with the **0x36 – TransferData** service.

**My expected block format (this works on another CAN analyzer):**

For each 3840-byte block of firmware:

```
ISO-TP frame data (sent on the wire):
[ SID = 0x36 ]
[ BSC = blockSequenceCounter ]
[ payload = 3840 bytes ]
[ CRC16 (2 bytes) ]
[ CRC32 (4 bytes, only on last block) ]
```

Total last block size = **3844 bytes**.

My ECU correctly receives this structure and verifies:

* CRC16 = CRC over: SID (0x36) + BSC + payload
* CRC32 matches full firmware

This format works perfectly on our other analyzer and firmware update succeeds.

---

**Problem with PCAN-UDS**

When I call:

```cpp
UDS_SvcTransferData_2013(
channel,
config,
&request,
blockSequenceCounter,
tprBuffer,
tprSize
);
```

PCAN correctly creates the UDS message and starts ISO-TP multi-frame transmission.

However:
❌ Even though the PCAN trace shows multiple ISO-TP frames going out,
❌ the ECU only receives **≈125 bytes** of data in total.

It looks like only the **First Frame** and **one Consecutive Frame** reach the ECU.
The rest of the payload is never delivered to the application layer on the ECU side.

There is **no NRC response** and no flow control error.
The ECU simply receives truncated data.

---
**My questions:**

1. **Does PCAN-UDS automatically include SID (0x36) and BSC when calculating the ISO-TP payload?**
Or should my `transfer_request_parameter_record` include SID/BSC explicitly?

2. **Is there any max payload limit imposed by PCAN-UDS for TransferData?**
My blocks are 3844 bytes total — inside ISO-TP max of 4095 bytes.

3. **Is it valid to send full 3844-byte TransferData blocks using PCAN-UDS?**
Or does PCAN require smaller TPR sizes?

4. **Is there any known issue in PCAN-UDS where only the first FF + 1 CF is transmitted to the ECU application layer?**

5. Could you provide a minimal example of `UDS_SvcTransferData_2013` that sends a multi-frame payload around **4 KB**?

---

**Additional notes:**

* I verified that the ECU works correctly with our other proprietary analyzer.
* Only PCAN-UDS transfers are truncated.
* My CAN FD configuration is correct and works for all other UDS services.

---

Thank you,
Prashanth

F.Vergnaud
Software Development
Software Development
Posts: 310
Joined: Mon 9. Sep 2013, 12:21

Re: UDS TransferData (0x36) — PCAN-UDS does not transmit full ISO-TP multi-frame payload

Post by F.Vergnaud » Tue 9. Dec 2025, 09:52

Hello,

Please find below the answers to your questions:
  1. UDS_SvcTransferData_2013(..) builds the UDS request for you with the provided parameters. You don't need to include SID or block_sequence_counter in the transfer_request_parameter_record.
  2. There is no max payload limit.
  3. TransferData has been validated with ECUs accepting 4093 data bytes. There is actually no restriction: if an ECU implements fully ISO15765:2016, then maximum payload could reach the ~4 giga Bytes limitation.
  4. There are no known issue. Actually it is the first time someone states that a single consecutive frame is sent and not the next ones of its block size: a bus error feels more likely.
  5. In order to better understand what is going on please provide a trace file of your UDS communication.
    You can find a usage sample of UDS_SvcTransferData_2013 in our documentation page 740.
Best regards,
Fabrice

prashanth
Posts: 6
Joined: Wed 26. Nov 2025, 12:57

Re: UDS TransferData (0x36) — PCAN-UDS does not transmit full ISO-TP multi-frame payload

Post by prashanth » Tue 9. Dec 2025, 11:22

Hello,

I am debugging a UDS TransferData (0x36) issue and want to confirm whether the problem is on the ECU side or PCAN side.

**Observed Behavior:**

* On the PCAN side, the CAN Trace shows that **PCAN successfully transmitted all Consecutive Frames**, totaling **3840 bytes** of payload (plus CRC).
* But on my ECU (server) side, the ISO-TP receive function only reports **1574 bytes received** before the transfer stops.
* When I debug the incoming frames on the ECU, the **first Consecutive Frame that the ECU receives contains Sequence Number = 3**, but according to ISO-TP rules, the **first CF after First Frame must have SN = 1**.

So my ECU receives:

```
FF → CF with SN = 3
```

This causes ISO-TP to reject the frame with **WRONG_SN**, which stops the transfer.

**What I don't understand:**

I cannot determine whether:

1. **PCAN is not transmitting CF #1 and CF #2**,
or
2. **PCAN is transmitting them but the ECU hardware never receives them**,
or
3. **PCAN transmits frames too fast (STmin=0) and ECU misses the first two frames**,
or
4. **PCAN-UDS / PCAN-ISO-TP internally buffers/splits frames in a way that changes the sequence order**.

**My Flow Control parameters:**

From ECU after receiving FF:

```
FS = Continue
BS = 0
STmin = 0
```

My Question:

Why is PCAN sending or my ECU receiving the first CF with SN = 3 instead of SN = 1?
And why does the ECU only receive 1574 bytes even though PCAN shows that it transmitted all 3840 bytes?**

Is there any known behavior in PCAN-ISO-TP or PCAN-UDS where:

* early consecutive frames may be dropped?
* STmin=0 causes frames to be sent faster than some ECUs can receive?
* block sizes or buffering affect how CFs are delivered?

I can provide trace logs if needed.

Thank you.

F.Vergnaud
Software Development
Software Development
Posts: 310
Joined: Mon 9. Sep 2013, 12:21

Re: UDS TransferData (0x36) — PCAN-UDS does not transmit full ISO-TP multi-frame payload

Post by F.Vergnaud » Tue 9. Dec 2025, 12:15

Hello,

I can confirm that PCAN automotive APIs are used by many customers against various ECUs, there are currently no known behaviour regarding invalid communications or implementations.

On a CAN bus, when a frame is written, it is available for every connected node. So if you observe that "PCAN successfully transmitted all Consecutive Frames" then all the frames are also available to read on your ECU's side.
An easy way to debug and assert what is going on on your CAN bus is to connect a PCAN device with PCAN-View in listen-only mode and record a trace. If you only have a single device, you can connect PCAN-View to the channel intialized by your application. You can share your trace file here.

If the trace shows all the frames, then the CAN controller of you ECU must also have received all the frames.
The next step for you will be to debug your ECU and understand why it is not reading all those frames:
- check if the CAN controller of your ECU warns you that frames are lost.
- check the implementation of ISOTP on your ECU.
- Not all ECUs are able to handle a STMin value of 0, if not increase the STMin value of your flow control frame.
Please note that we can't provide support on development of your ECU as it is out of the scope of PCAN automotive APIs.
Best regards,
Fabrice

Post Reply