UDS Service TransferData with MAX_DATA (4093 bytes) length

[F.Vergnaud]

Hello,

1) You can call UDS_RemoveMapping_2013 (or PUDS_PARAM_MAPPING_REMOVE with 1.x version), then configure a new mapping.

2) You need to change PUDS_PARAMETER_SERVER_ADDRESS (or PUDS_PARAM_SERVER_ADDRESS with 1.x version) so that it matches the source address in your message.
UDS channel will discard any Rx UDS messages whose target address does not match its server address or is not listed in the allowed filter address: see parameter PUDS_PARAMETER_ADD_LISTENED_ADDRESS (or PUDS_PARAM_SERVER_Filter with 1.x version).

3) Changing target address is common, it means that you want to send messages to different ECUs. Simply define as many mapping as required.
Changing the source address is more unsual, you should either:
- add multiple filter addresses (so that the API instance knows that it must handle multiples server addresses), then configure the required mappings.
- or remove any mappings and filtered addresses, redefine your server address, and add new mappings. If you're not expecting any message, uninitializing the channel and reconfiguring it is also a possibility: this is what I would recommend in automated testing for instance.

[Shail]

Hello,

1) What's difference between them ?
PUDS_PARAM_TIMEOUT_REQUEST, PUDS_PARAM_TIMEOUT_RESPONSE
and
PUDS_TIMEOUT_REQUEST, PUDS_TIMEOUT_RESPONSE
We have not used PUDS_TIMEOUT_REQUEST and PUDS_TIMEOUT_RESPONSE while configuration in code.

2) PCAN Trace as mentioned below with timestamp
287.3567 data 29 CC 55 55 55 55 55 55 -> Last 8 bytes in chunk of data
287.3573 data 1F FF 36 AF 70 EA E2 80 -> Next Chunk data first 8 bytes
287.3591 data 02 76 AE -> Positive response from server from acknowledging the last chunk received successfully

Usually one Chunk transmit Time : 335ms average
Usually After sending one chunk time require to get response from server : 1.5 ms

We are getting next chunk first frame before getting response How to handle such cases? What configuration we should use it
currently PUDS_PARAM_TIMEOUT_REQUEST, PUDS_PARAM_TIMEOUT_RESPONSE around 8 seconds.

3) Yes We need to Change target address and we want to send messages to different ECUs.
how to define as many mapping as required?
Should we need to use this PUDS_PARAM_MAPPING_REMOVE with 1.x version to unmapped target address and mapped again for different ECU?

[F.Vergnaud]

Hello,

1) PUDS_TIMEOUT_REQUEST, PUDS_TIMEOUT_RESPONSE are respectively the default values for parameters PUDS_PARAM_TIMEOUT_REQUEST, PUDS_PARAM_TIMEOUT_RESPONSE.
Please check the documentation included in your PCAN-UDS 1.x version p.34 & 35.

2) PCAN-UDS does not send data on its own. If a UDS message is sent, that's because your application made a call to UDS_SvcTransferData or UDS_Write.
This is not a use-case to handle but a design problem to fix. Maybe if you have multiple threads using PCAN-UDS, it can help to call UDS_Reset before calling any UDS_SvcXXX functions.
Otherwise please send a sample of your code that reproduces the issue and a full trace of the CAN bus. You can send it to support [at] peak-system.com for my attention.

3) You just need to call several times UDS_SetValue(.., PUDS_PARAM_MAPPING_ADD, ...) with the different configuration you need.
You can keep previously defined mappings.

[Shail]

Hello,

1) We are using testTransferDataBigMessage API.
// UDS Service TransferData with MAX_DATA length

We need to send data more then 4096 byte in chunks, so we are using testTransferDataBigMessage API.
PCAN Trace as mentioned below with time stamp
211.1330 data 29 CC 55 55 55 55 55 55
211.1341 data 1F FF 36 AF 70 EA E2 80
211.1345 data 02 76 AE

What can be possible scenario or use cases it can send response like that?
-> Status = UDS_WaitForService(Channel, &MessageResponse, &Message);
In this case UDS_WaitForService API we are waiting to get response within 10sec.

Based on status only either it will call displayMessage(&Message, &MessageResponse);
or displayMessage(&Message, NULL); API
In code We are entering to this loop and calling displayMessage(&Message, NULL) API.

2) You just need to call several times UDS_SetValue(.., PUDS_PARAM_MAPPING_ADD, ...) with the different configuration you need.
How many UDS_SetValue(.., PUDS_PARAM_MAPPING_ADD, ...) upto 8 or max limit?

[F.Vergnaud]

Hello,

1)

What can be possible scenario or use cases it can send response like that?

It is not possible to achieve this behaviour using the sample function testTransferDataBigMessage.
In the following example, I have added a "for" loop to simulate and test your need:

Code: Select all

// UDS Service TransferData with MAX_DATA length
void testTransferDataBigMessage(TPUDSCANHandle Channel, TPUDSNetAddrInfo N_AI)
{	
	TPUDSStatus Status;
	TPUDSMsg Message = {};
	TPUDSMsg MessageResponse = {};	
	BYTE lBuffer[4095] = {};
	WORD buffLen = 4093;
	// initialization
	Message.NETADDRINFO = N_AI;

	CLEAR_CONSOLE
		printf("\n\n*** UDS Service: TransferData with MAX_DATA ***\n");

	// 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.
	printf("\n\nSends a Physical TransferData Message (LEN=%d): \n", buffLen);
	for (int i = 0 ; i < buffLen ; i++) {
		lBuffer[i] = 'A' + i;
	}
	
for (int j = 0; j < 10; ++j) {	
	
	Status = UDS_SvcTransferData(Channel, &Message, 0x01, lBuffer, buffLen);
	if (Status == PUDS_ERROR_OK)
		Status = UDS_WaitForService(Channel, &MessageResponse, &Message);
	printf("  UDS_SvcTransferData: %i\n", (int)Status);
	if (Status == PUDS_ERROR_OK)
		displayMessage(&Message, &MessageResponse);
	else
		displayMessage(&Message, NULL);

}		
		
	waitGetch();
}

2)

How many UDS_SetValue(.., PUDS_PARAM_MAPPING_ADD, ...) upto 8 or max limit?

There is no known limit.

3) Btw I do not recognize the timestamp format in your trace. Timestamp in PEAK trace file format are expressed in milliseconds.
But 211.1330 seems to be 211 seconds...If that's the case (211.1341 - 211.1330) is only 1.1ms!

[Shail]

Hello,

In our case we are collecting the status from display message also and based on status we are sending next frame in spite response not received
Status = UDS_SvcTransferData(Channel, &Message, 0x01, lBuffer, buffLen);
if (Status == PUDS_ERROR_OK)
Status = UDS_WaitForService(Channel, &MessageResponse, &Message);
printf(" UDS_SvcTransferData: %i\n", (int)Status);
if (Status == PUDS_ERROR_OK)
status = displayMessage(&Message, &MessageResponse);
else
status = displayMessage(&Message, NULL);

If it enters displayMessage(&Message, NULL); loop then there is no response received in from ECU inspite sending data in chunk.
Status = PUDS_ERROR_NO_MESSAGE Should we need to wait for more timeout or debounce we need to implement?

Que:

Btw I do not recognize the timestamp format in your trace. Timestamp in PEAK trace file format are expressed in milliseconds.
But 211.1330 seems to be 211 seconds...If that's the case (211.1341 - 211.1330) is only 1.1ms.

Ya PEAK Trace in milliseconds only PUDS_PARAM_SEPERATION_TIME is deafault 10 sec but it depends on ECU.
ECU sending flow control frame with data 30 00 00 : In that 00 indicate client can send data as fast as it can.

[F.Vergnaud]

Ya PEAK Trace in milliseconds only PUDS_PARAM_SEPERATION_TIME is deafault 10 sec but it depends on ECU.
ECU sending flow control frame with data 30 00 00 : In that 00 indicate client can send data as fast as it can.

I agree with STMin=00 and BS=00, the sender will transmit the data as quickly as possible, but the trace you mentioned shows something else:

Code: Select all

211.1330 data 29 CC 55 55 55 55 55 55 <-- Last Consecutive frame
211.1341 data 1F FF 36 AF 70 EA E2 80 <-- First Frame 
211.1345 data 02 76 AE                        <-- ECU response

If the first frame is sent in such a short time then this request was already in the transmit queue and was waiting for the pending request to be complete.
You should assert that at some point UDS_SvcTransferData was not called too many time or simply call UDS_Reset before calling UDS_SvcTransferData as proposed earlier.

Should we need to wait for more timeout or debounce we need to implement?

Obviously the trace shows that the UDS response was received. There is no reason to wait longer.
You could try to call UDS_Read instead to check if the message is in the UDS receive queue (UDS_WaitForService may have failed to retrieved the message due to what we see in the trace).

[Shail]

Hello,

Thanks for your reply.

Will try what u suggested. Meanwhile once for question.

if (Status == PUDS_ERROR_OK)
Status = UDS_WaitForService(Channel, &MessageResponse, &Message);
printf(" UDS_SvcTransferData: %i\n", (int)Status);
if (Status == PUDS_ERROR_OK)
status = displayMessage(&Message, &MessageResponse);
else
status = displayMessage(&Message, NULL);

1) we are getting status of UDS_WaitForService(Channel, &MessageResponse, &Message) as PUDS_ERROR_NO_MESSAGE.
Should we need to consider PUDS_ERROR_NO_MESSAGE as negative response or NRC or how to decode status ?

2)

If the first frame is sent in such a short time then this request was already in the transmit queue and was waiting for the pending request to be complete.
You should assert that at some point UDS_SvcTransferData was not called too many time or simply call UDS_Reset before calling UDS_SvcTransferData as proposed earlier.

Yes we are sending more chunk consecutively so we are calling UDS_SvcTransferData API multiple time.
Is any way we can see what data there in transmit or receive queue ?

2) While using UDS_Reset is it require to reconfigure parameter of mapping once again?

3) UDS_Reset should we need to call every time before UDS_SvcTransferData API or only once after multiple call?
UDS reset full channel so we need to again initialize using UDS_Initialize ?

[F.Vergnaud]

Hello,

1) With version 1.x, the status is not precise enough to tell if you didn't receive the request confirmation or a response.
You need to use the function with 4 parameters:

Code: Select all

 Status = UDS_WaitForService(Channel, &MessageResponse, &Message, &RequestConfirmation);

In any case it is a recommended practice to:
- provide a RequestConfirmation buffer,
- you will be able to check its RESULT member in case of PUDS_ERROR_CAN_ERROR status (thus identifying if the error occured during Transmission or Receival),
- check RequestConfirmation content (NETADDRINFO and RESULT) if Status is PUDS_ERROR_NO_MESSAGE to see if the transmission succeeded.


Nevertheless, as already told before, you should upgrade to the latest version of PCAN-UDS (currently version 2.1.0): there are new status that help you on this matter.

Should we need to consider PUDS_ERROR_NO_MESSAGE

=> ...as negative response: no. it only means that the API didn't read any message: either no request confirmation was read or no response matching the request was found.
=> ...or NRC: no. Reminder, the user has to check if the message is negative response based on the Service ID value.
=> ...or how to decode status ? there is nothing to decode, you have to analyze as mentioned above the RequestConfirmation buffer.
The function you are using is only a demo, the code is not meant to precisely take care of all possible use-cases..

2)

While using UDS_Reset is it require to reconfigure parameter of mapping once again?

No, it only resets the receive and transmit queues of a PUDS Channel.

3)

UDS_Reset should we need to call every time before UDS_SvcTransferData API or only once after multiple call?

To be safe, you can call it every time before UDS_SvcTransferData API.

UDS reset full channel so we need to again initialize using UDS_Initialize ?

No! Please check the documentation... It will avoid making assumptions on what a function does based only on its name.
UDS_Reset "resets the receive and transmit queues of a PUDS Channel." (§ 3.7.8).
It has nothing to do with UDS_Uninitialize.

[Shail]

Hello,

1) Yes. we are using version 1.x PCAN UDS

In any case it is a recommended practice to:
- provide a RequestConfirmation buffer,
- you will be able to check its RESULT member in case of PUDS_ERROR_CAN_ERROR status (thus identifying if the error occured during Transmission or Receival),
- check RequestConfirmation content (NETADDRINFO and RESULT) if Status is PUDS_ERROR_NO_MESSAGE to see if the transmission succeeded.

Now we are using the below mentioned API with RequestConfirmation
Status = UDS_WaitForService(Channel, &MessageResponse, &Message, &RequestConfirmation);

We are getting UDS_WaitForService Status = PUDS_ERROR_CAN_ERROR 0x80000000 // Global CAN error, use following macros to merge/fetch PCAN error

RequestConfirmation = RESULT = 0x02 : Sender side timeout while waiting for flow control frame
TA_TYPE = 0x1
RA = 0
PROTOCOL =0x3

PUDS_ERROR_CAN_ERROR : A network error occured either in the transmit confirmation or the response message

->May I know How we can solve PUDS_ERROR_CAN_ERROR error?