Page 3 of 3

Re: UDS Service TransferData with MAX_DATA (4093 bytes) length

Posted: Thu 18. Feb 2021, 15:38
by F.Vergnaud
Hello,

You received the following network error PCANTP_N_TIMEOUT_Bs(0x02) : Sender side timeout while waiting for flow control frame.
This means the UDS channel didn't receive the Flow Control frame from the ECU.

There can be 2 reasons, you'll need to check your trace file:
- if the flow control frame is NOT listed in the trace, then double-check the CAN ID and network address information used to communicate with this ECU.
- if the flow control frame is listed in the trace, then you have an undefined or incorrect mapping configuration with this ECU.

Re: UDS Service TransferData with MAX_DATA (4093 bytes) length

Posted: Thu 18. Feb 2021, 19:51
by Shail
Hello,

Initially we are using default mapping.
After that in middle we are changing target address so we are changing mapping.
What are the steps to reconfigured mapping information?
if the flow control frame is listed in the trace, then you have an undefined or incorrect mapping configuration with this ECU
How to identify undefined and incorrect mapping?

Should we need to uninitialize channel and again initialize?

Re: UDS Service TransferData with MAX_DATA (4093 bytes) length

Posted: Fri 19. Feb 2021, 10:37
by F.Vergnaud
Hello,
How to identify undefined and incorrect mapping?
You have to define mappings for any communication that is not listed in the documentation §4.3 4.3 UDS and ISO-TP Network Addressing Information: page 339.
Should we need to uninitialize channel and again initialize?
No.

Here is a sample that shows how to add a 2-way communication mapping (from $4.3.3 PCAN-UDS Example - Configuration of Mappings)

Code: Select all

	TPUDSCANHandle Channel;
	TPUDSMsg Message;
	TPUDSStatus Status;
	// Note: Channel is properly initialized with UDS_Initialize(..)
	// [...]
	
	// Add mapping for physical request from External_Equipment to ECU_#X
	Message.NETADDRINFO.SA = 0xF1;
	Message.NETADDRINFO.TA = 0xXX;
	Message.NETADDRINFO.TA_TYPE = PUDS_ADDRESSING_PHYSICAL;
	Message.NETADDRINFO.RA = 0x00;
	Message.NETADDRINFO.PROTOCOL = PUDS_PROTOCOL_ISO_15765_2_11B;
	Message.LEN = 8;
	// data[0..3] holds CAN ID
	Message.DATA.RAW[0] = 0x00;
	Message.DATA.RAW[1] = 0x00;
	Message.DATA.RAW[2] = 0x03;
	Message.DATA.RAW[3] = 0x26;
	// data[4..7] holds CAN ID Response (for Flow Control) (-1 if none) 
	Message.DATA.RAW[4] = 0x00;
	Message.DATA.RAW[5] = 0x00;
	Message.DATA.RAW[6] = 0x06;
	Message.DATA.RAW[7] = 0x26;
	status = UDS_SetValue(Channel, PUDS_PARAM_MAPPING_ADD, &Message, sizeof(Message));
	// Check status
	//...

	// Add mapping for physical response from ECU_#X to External_Equipment
	Message.NETADDRINFO.SA = 0xXX;
	Message.NETADDRINFO.TA = 0xF1;
	Message.NETADDRINFO.TA_TYPE = PUDS_ADDRESSING_PHYSICAL;
	Message.NETADDRINFO.RA = 0x00;
	Message.NETADDRINFO.PROTOCOL = PUDS_PROTOCOL_ISO_15765_2_11B;
	Message.LEN = 8;
	// data[0..3] holds CAN ID
	Message.DATA.RAW[0] = 0x00;
	Message.DATA.RAW[1] = 0x00;
	Message.DATA.RAW[2] = 0x06;
	Message.DATA.RAW[3] = 0x26;
	// data[4..7] holds CAN ID Response (for Flow Control) (-1 if none) 
	Message.DATA.RAW[4] = 0x00;
	Message.DATA.RAW[5] = 0x00;
	Message.DATA.RAW[6] = 0x03;
	Message.DATA.RAW[7] = 0x26;
	status = UDS_SetValue(Channel, PUDS_PARAM_MAPPING_ADD, &Message, sizeof(Message));
	// Check status
	//...

Re: UDS Service TransferData with MAX_DATA (4093 bytes) length

Posted: Fri 19. Feb 2021, 10:58
by Shail
Hello,

We are using configuration of 29bit identifier : 18DAxxxx
#define PUDS_PROTOCOL_ISO_15765_2_29B 0x03 // using PCAN-ISO-TP with 29 BIT CAN ID, FIXED NORMAL addressing and diagnostic message

Mapping NA in this protocol
Page 342 user manual 4.3.2
Normal fixed addressing 11 bits Addressing is invalid
PCANTP_FORMAT_FIXED_NORMAL 29 bits ‐

1) Is it require to use PUDS_PARAM_MAPPING_REMOVE to remove when we are using PUDS_PROTOCOL_ISO_15765_2_29B?
status = UDS_SetValue(Channel, PUDS_PARAM_MAPPING_REMOVE, &Message, sizeof(Message));

2) Is it require to reconfigure timeout value in when we are using PUDS_PROTOCOL_ISO_15765_2_29B? and
How to change target address when we are using PUDS_PROTOCOL_ISO_15765_2_29B?

3)
There can be 2 reasons, you'll need to check your trace file:
- if the flow control frame is NOT listed in the trace, then double-check the CAN ID and network address information used to communicate with this ECU.
- if the flow control frame is listed in the trace, then you have an undefined or incorrect mapping configuration with this ECU.
Flow control define in out trace So only problem might be incorrect mapping or undefined mapping but is it valid for protocol PUDS_PROTOCOL_ISO_15765_2_29B?

4)
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...)
How to differentiate between request confirmation and read response ?
Can u explain this with example in more details?

Re: UDS Service TransferData with MAX_DATA (4093 bytes) length

Posted: Fri 19. Feb 2021, 12:00
by F.Vergnaud
If you are using PUDS_PROTOCOL_ISO_15765_2_29B, you don't have to configure extra mappings: it is handled automatically by the API as the CAN IDs used to communicate are standardized.
1) Is it require to use PUDS_PARAM_MAPPING_REMOVE to remove when we are using PUDS_PROTOCOL_ISO_15765_2_29B?
No
2) Is it require to reconfigure timeout value in when we are using PUDS_PROTOCOL_ISO_15765_2_29B?
No
How to change target address when we are using PUDS_PROTOCOL_ISO_15765_2_29B?
Target address is defined in Message.NETADDRINFO.TA where Message is a TPUDSMessage and NETADDRINFO is a TPUDSNetAddrInfo.

3) The analysis was based on the information that you are configuring your own mappings.. other explanations are available like source address not being 0xF1.
Please provide a full CAN trace (with all the information CAN ID, DLC, etc.) or at least an excerpt showing:
- the 5 last frames of the previous UDS request message,
- the ECU's response frame(s),
- the new UDS request with the first frame,
- the ECU's flow control frame,
- the next CAN frame(s) showing network timeout.

4)
How to differentiate between request confirmation and read response ?
Documentation page 269: parameter IsWaitForTransmit  States whether the message to wait is a transmit confirmation or a UDS response.

Code: Select all

TPUDSMessage messageRequestConfirmation, messageResponse;

// wait for transmission confirmation
status = UDS_WaitForSingleMessage(canChannel, &messageRequestConfirmation, messageRequest, true, 1, 10000);		
// if transmission is OK: wait for the response message
if (status == PUDS_ERROR_OK) 
{
	// check if Request is valid
	if (messageRequestConfirmation.RESULT == PUDS_RESULT_N_OK)
	{
		// wait for response confirmation 
		Status = UDS_WaitForSingleMessage(canChannel, &messageResponse, messageRequest, false, 1, 10000);
		// ...
	}
}