UDS SID2E & SID22 - service

Question

In SID2E and SID22 is there a condition where the length of the entire frame will exceed 7 bytes?
If yes then how it will send or write tha data bytes?

Answer 1

Yes, it is a common use-case in UDS that the response to SID 0x22 (ReadDataByIdentifier) or the request to SID 0x2E (WriteDataByIdentifier) exceeds 7 bytes in length. For this purpose a message consisting of multple CAN frames is
sent, utilizing the Transport-Layer (ISO-TP, ISO 15765-2).
Consider a normal single frame message, where the high-nibble of the first byte is 0x0 i.e.
0x7E0 0x03 0x22 0xF1 0x90
0x7E8 0x04 0x62 0xF1 0x90 0x01
Here the payload is within 7 bytes (in both request and response), so the low-nibble of the first byte tells us the exact length (0x03 in the request, 0x04 in the response). As the complete message fits within a single CAN frame, nothing else is required. But to send a longer diagnostic message, it needs to be splitted across multple CAN frames (segmentation). For this 3 different types of messages are required:
A first frame is sent to the receiver to start the transmission.
This contains the length (up to 4095 bytes) of the complete payload
data and the first 6 bytes of the message. The high-nibble 0x1 of
the first byte indicates that the message is a first frame.
A flow control frame confirming receiving of the first frame is
replied to the sender of the first frame. It contains additional
information like expected STmin timing and block-size. The
high-nibble 0x3 of the first byte indicates that the message is a
flow control frame.
One or more consecutive frames are sent to the receiver, which
contain up to 7 bytes of the remaining payload - together with a
counter to ensure the data can be desegmented in the correct order.
The high-nibble 0x2 of the first byte indicates that the message is
a consecutive frame.
Now consider the following scenario: The tester application sends the single frame 0x7E0 0x03 0x22 0xF1 0x90 as request. The ECU may want to send the response 0x62 0xF1 0x90 0x01 0x02 0x03 0x04 0x05 (8 bytes payload) to the tester application.
So the ECU will first send the first frame:
0x7E8 0x10 0x08 0x62 0xF1 0x90 0x01 0x02 0x03
And wait for a flow control frame from the tester application:
0x7E0 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Then the ECU will continue to send consecutive frames until the
complete message is transmitted:
0x7E8 0x21 0x04 0x05 0x00 0x00 0x00 0x00 0x00
For the SID 0x2E (WriteDataByIdentifier) it will be very similar, just the roles are reversed as typically the tester application wants to send the long message in the request and the ECU will reply with the flow control message. i.e.
0x7E0 0x10 0x08 0x2E 0xF1 0x90 0x01 0x02 0x03
0x7E8 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7E0 0x21 0x04 0x05 0x00 0x00 0x00 0x00 0x00
0x7E8 0x03 0x6E 0xF1 0x90 0x00 0x00 0x00 0x00
If more than one consecutive frame is required, the first byte will simply be increased from 0x21 up to 0x2F and then start again from 0x20 to count up.
0x7E0 0x10 0x76 0x2E 0xF1 0x90 0x01 0x02 0x03
0x7E8 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7E0 0x21 0x04 0x05 0x06 0x07 0x08 0x09 0x0A
0x7E0 0x22 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11
...
0x7E0 0x2F 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0x7E0 0x20 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF