UDS Service TransferData with MAX_DATA (4093 bytes) length

[Shail]

Hello,

We are using testTransferDataBigMessage function from PCAN Example.
which basicaly use UDS Service TransferData with MAX_DATA 4093 bytes of length

// Sends a Physical TransferData Message with the maximum data available.
// The goal is to show that UDS_WaitForService doesn't return a TIMEOUT error
// although the transmit and receive time of all the data will be longer
// than the default time to get a response.

1) How to make sure UDS_WaitForService doesn't return a TIMEOUT error incase transmit and receive time of all the data will be longer than the default time to get a response?
2) In between sending data in chunks of 4093 bytes we are not getting response from server sometime due to that it invoke displayMessage(&Message, NULL) How to handle such case?
3) Should we need to increase timeout as mentioned below?
ulBuffer = 2000;
Status = UDS_SetValue(Channel, PUDS_PARAM_TIMEOUT_REQUEST, &ulBuffer, sizeof(ulBuffer));
4) What can be reason server not responding NRC for transferData[DS0] #n Request ?

Thanks and Regards,
Shail

[F.Vergnaud]

Hello,

You're using UDS_WaitForService, please let me know the version of the API you use.
PCAN-UDS 2.x was released, it supports previous API version entries but I recommend to use the new UDS_WaitForService_2013: in your case it would state more easily and precisely if you have an error during transmission or reception.

1) In any case, as long as the indication of a message is received (whether it is a transmission or reception), UDS_WaitForService will wait until it receives the complete message.
The message's network result can be successful or not, but a message must and will be read (of course, this is not true if you call UDS_Reset or UDS_Uninitialize on another thread: as it will abort the WaitForService function).
PUDS_ERROR_TIMEOUT status is quite exceptionnal and hard to get, it is more common to have a PUDS_ERROR_NO_MESSAGE (if MessageReqBuffer is provided it will let you know if transmission was successful).

2) PCUServer sample is not designed to be used in production or time-critical use-cases. You should modify it and not use the function "displayMessage" for instance.

3) Default value for PUDS_PARAM_TIMEOUT_REQUEST/RESPONSE is 10s (check PUDS_TIMEOUT_REQUEST, PUDS_TIMEOUT_RESPONSE).. you would be actually reducing the value.
By analyzing your CAN bus, you can estimate the required time as it must be greater than the time for the First Frame of your Tx/Rx message to show up on the CAN bus.

4) ECU implementations are constructor dependant and outside the scope of PCAN-UDS support. if you're refering to PCUServer, it is only a sample and does not implement this feature.

[Shail]

Hello,

Thanks for the response.

We are using PCAN UDS file from $Date: 2019-10-11 14:05:33 +0200 (ven., 11 oct. 2019) Author : Thomas Haber
1) Yes we are getting PUDS_ERROR_NO_MESSAGE as response and due to that it invoke displayMessage(&Message, NULL) How to handle such case?

2) IS below mentioned configuration indicate 10sec timeout for request and response?
ulBuffer = 2000;
Status = UDS_SetValue(Channel, PUDS_PARAM_TIMEOUT_REQUEST, &ulBuffer, sizeof(ulBuffer));
2000 value indicate 10sec PUDS_PARAM_TIMEOUT_REQUEST/RESPONSE ?
Can u tell us the formula to calculate 2 sec timeout value?

Thanks

[F.Vergnaud]

Hello,

I'd recommand to upgrade to the latest PCAN-UDS, version 2.1.0.

1)

Yes we are getting PUDS_ERROR_NO_MESSAGE as response and due to that it invoke displayMessage(&Message, NULL) How to handle such case?

In between sending data in chunks of 4093 bytes we are not getting response from server sometime due to that it invoke displayMessage(&Message, NULL) How to handle such case?

I can't help you if you are not precise enough, try to analyze the trace on your CAN bus to see what exactly is going on:
- you need to assert that the response from the server was effectively written on the CAN bus.

2)

ulBuffer = 2000;
Status = UDS_SetValue(Channel, PUDS_PARAM_TIMEOUT_REQUEST, &ulBuffer, sizeof(ulBuffer));

2000 indicates 2sec. There is no formula, value is in milliseconds as indicated in the manual page 34.

[Shail]

Hello,

We are sending the 4093 bytes of chunks after sending data we are getting response from server as mentioned below.

29 A6 55 55 55 55 55 55 -> Last 8 bytes in chunk of data
1F FF 36 8B 67 00 70 E1 -> Next Chunk data first 8 bytes
02 76 8A -> Positive response from server from acknowledging the last chunk received successfully

==========================
We send the data in 4093 byte of chunks. IN between we are not getting server response before next chunks
As you can see we are sending next chunk data before receiving the positive response from server

What we should do avoid problem?
Should we need to increase timeout PUDS_PARAM_TIMEOUT_REQUEST/RESPONSE ? currently we are using 8 sec.
We have comment waitGetch after service since time consuming every request user press may not required.
Should we need to put delay between two service if so how?

Thanks,

[F.Vergnaud]

Hello,

Could you precise the timestamps of the CAN frames?

Code: Select all

Time         29 A6 55 55 55 55 55 55 -> Last 8 bytes in chunk of data
Time + 8s    1F FF 36 8B 67 00 70 E1 -> Next Chunk data first 8 bytes
Time > 8s    02 76 8A -> Positive response from server from acknowledging the last chunk received successfully

I'll assume that the next chunk of data is starting after the WaitForService's timeout (~8s).
The timestamp of the positive response from the server should tell you what to do:
1) if it is written on the CAN bus as soon as the next first frame is sent, you should check your ECU: it would seem that it waited for something before sending its response (more data?).
2) if there is no correlation (for instance Timestamp is "Time + 12s"), then I'd say the ECU is taking time to compute the chunk.
Unfortunately it is not sending the standardized response "PUDS_NRC_EXTENDED_TIMING" which would tell the client to wait longer.
You should increase PUDS_PARAM_TIMEOUT_RESPONSE.

If you need to analyze more precisely what is going on with the ECU response, I'd advise to manually handle the WaitForService process:
- comment the UDS_WaitForService function,
- use UDS_WaitForSingleMessage to read the confirmation of the request,
- on success, use UDS_WaitForSingleMessage to read the response: you can specify exactly the timeout (or use a loop to retry or even send a frame to force the ECU send its response...)

Code: Select all

// wait for response confirmation (timeout is in ms)
Status = UDS_WaitForSingleMessage(CanChannel, MessageResponseBuffer, MessageRequest, false, 1, 20000);

[Shail]

Hello,

TImeout details as mentioned below.
TIme Frame
210.0571 || 29 A6 55 55 55 55 55 55
210.0577 || 1F FF 36 8B 67 00 70 E1
210.0594 || 02 76 8A

Will check for UDS_WaitForSingleMessage function to find out single chunk time

[Shail]

Hello,

We need to reconfigure the network address information multiple time.

should we need to define timeout again if Network Address Information (Source and target address) used for all the tests change multiple time?
For example:
// Define TimeOuts
ulBuffer = 2000;
Status = UDS_SetValue(Channel, PUDS_PARAM_TIMEOUT_RESPONSE, &ulBuffer, sizeof(ulBuffer));
printf(" Set TIMEOUT_REQUEST: %i (%d)\n", (int)Status, ulBuffer);

2) If we UnInitializing of the UDS Communication session by using below mention API after that
Status = UDS_UnInitialize(Channel, PUDS_BAUD_250K, 0x1, 0x0, 0x0);
to restart UDS Communication what are steps we need to follow?

[F.Vergnaud]

Hello,

1) You don't need to reconfigure the parameter unless the channel is uninitialized: the scope of PUDS_PARAM_TIMEOUT_RESPONSE is channel wide.

2) When you uninitialize a channel, everything is resetted (no information is retained). You should redo all the initialisations that were made after the first UDS initialization (mapping definitions, parameters modifications, etc.)

[Shail]

Hello,

If we want to change Source and target address frequently is it require to call API UDS_Uninitialize(Channel) and mapped again?
N_AI.SA = PUDS_BDS_SERVER_SOURCE_ADDR;
N_AI.TA = PUDS_ISO_15765_4_ADDR_ECU_1;
N_AI.TA_TYPE = PUDS_ADDRESSING_PHYSICAL;
N_AI.RA = 0x00;

2) If we want to change Source and target address frequently is require to define address again?
// Define Address
iBuffer = PUDS_SERVER_ADDR_TEST_EQUIPMENT;
Status = UDS_SetValue(Channel, PUDS_PARAM_MAPPING_ADD, &iBuffer, 1);

// Define TimeOuts
ulBuffer = 8000;
Status = UDS_SetValue(Channel, PUDS_PARAM_TIMEOUT_REQUEST, &ulBuffer, sizeof(ulBuffer));
printf(" Set TIMEOUT_REQUEST: %i (%d)\n", (int)Status, ulBuffer);
Status = UDS_SetValue(Channel, PUDS_PARAM_TIMEOUT_RESPONSE, &ulBuffer, sizeof(ulBuffer));
printf(" Set TIMEOUT_REQUEST: %i (%d)\n", (int)Status, ulBuffer);

3) How to handle If we want to change Source and target address frequently?