Fail to receive message from ECU with 29bit CAN addressing

[element42]

Dear forum,

For a project we are using UDS with 29bit physical CAN IDs and NORMAL addressing. I am able to successfully initialize the UDS channel and send a DiagnosticSessionControl message to the ECU, to which it replies with the expected positive response as can be seen in CAN trace of PCAN-View.

However the UDS_WaitForService() function always returns the status 'PUDS_ERROR_NO_MESSAGE'... My assumption is that the ISO-TP implementation fails to make the mapping back towards the UDS layer based on the response CAN ID. So I went over the (addressing) configuration several times to check whether I have missed something obvious, but to my despair I can't find anything.

So I am hoping someone can help me figure out this issue.
Thanks in advance for any input!

I'm able to reproduce the issue with the following code:

Code: Select all

TPUDSCANHandle handle = PUDS_USBBUS1;
TPUDSStatus status = UDS_Initialize(handle, PUDS_BAUD_500K); 
PCAN::ISO_TP::checkStatus(status);

//Note: The PCAN::ISO_TP::checkStatus() function checks the status and throws an exception in case it is not PCANTP_ERROR_OK

uint32_t timeout = 2000;
UDS_SetValue(handle, PUDS_PARAM_TIMEOUT_REQUEST, &timeout, sizeof(timeout));
UDS_SetValue(handle, PUDS_PARAM_TIMEOUT_RESPONSE, &timeout, sizeof(timeout));

uint16_t address = PUDS_ISO_15765_4_ADDR_TEST_EQUIPMENT;
status = UDS_SetValue(handle,
PUDS_PARAM_SERVER_ADDRESS, &address, sizeof(address));
PCAN::ISO_TP::checkStatus(status);

TPUDSNetAddrInfo nai;
nai.SA = PUDS_ISO_15765_4_ADDR_TEST_EQUIPMENT;
nai.TA = PUDS_ISO_15765_4_ADDR_ECU_1;
nai.TA_TYPE = PUDS_ADDRESSING_PHYSICAL;
nai.RA = 0x00;
nai.PROTOCOL = PUDS_PROTOCOL_ISO_15765_2_29B_NORMAL;

uint32_t request_id = 0x17fc008f;
uint32_t response_id = 0x17fe008f;

status = CANTP_AddMapping(handle,
	request_id, response_id, PCANTP_ID_CAN_29BIT,
	PCANTP_FORMAT_NORMAL, PCANTP_MESSAGE_DIAGNOSTIC,
	nai.SA, nai.TA, PCANTP_ADDRESSING_PHYSICAL, nai.RA);
PCAN::ISO_TP::checkStatus(status);

status = CANTP_AddMapping(handle,
	response_id, request_id, PCANTP_ID_CAN_29BIT,
	PCANTP_FORMAT_NORMAL, PCANTP_MESSAGE_DIAGNOSTIC,
	nai.TA, nai.SA, PCANTP_ADDRESSING_PHYSICAL, nai.RA);
PCAN::ISO_TP::checkStatus(status);

TPUDSMsg request = {0};
request.NETADDRINFO = nai;

status = UDS_SvcDiagnosticSessionControl(handle, &request, PUDS_SVC_PARAM_DSC_ECUEDS);
TPUDSMsg response = {0};	
if (status == PUDS_ERROR_OK) {
	status = UDS_WaitForService(handle, &response, &request);
}
PCAN::ISO_TP::checkStatus(status); // In this case always PUDS_ERROR_NO_MESSAGE

[F.Vergnaud]

Hello,

The CAN IDs you are trying to map unfortunately match the "Enhanced diagnostics 29 bit" CAN identifiers defined in standard UDS on CAN (ISO 15765-3:2004) :

- Priority (bits: 28..26): any value (default is 6 or 0b110)
- Extended Data page (bit: 25): 0b1
- Data page (bit: 24): 0b1
- Type of service (bits: 23..22): 0b11 (means ISO 15765-3 defined message)
- Source address (bits: 21..11)
- Target address (bits: 10..0)

If you convert your CAN IDs, you can see it matches the above definition:
bin(0x17fc008f) = 0b10111111111000000000010001111

If you change the CAN IDs (for instance to 0x14FC008F) you'll be able to communicate. For now mappings do not supersede 29bit standard ISO-TP CAN IDs (like FIXED_NORMAL and ENHANCED addressing).

[element42]

Hi Fabrice,

Thank you for your input.

However unfortunately we are not able to change the communication addresses as these have been assigned to our ECU in order to be part of a bigger CAN network. Additionally CAN tools from other vendors have no problem communicating with our device over UDS.

So what I fail to understand correctly is why the PEAK ISO-TP layer still tries the interpret the address of the response messages as anything different then what the dynamic mapping is configured to. To further illustrate my question, in the code I have mapped the response address as a 'NORMAL 29bit Physical CAN ID' towards the TA/SA addresses of the UDS channel. Then why would the lookup mechanism still try to interpret the address as a 'Enhanced diagnostics 29 bit' identifier which it obviously can't map to a channel. Can I not simply disable this addressing format in the ISO-TP layer?

[F.Vergnaud]

Indeed I understand your concern. Actually with the current ISO-TP API, when a CAN frame is read it needs to be decoded as an ISO-TP frame based on the CAN ID (and on some cases the first data byte).
When your response is received, the mechanism first checks if the CAN ID matches one of the standardized 29 bit CAN ID (corresponding to FIXED_NORMAL, MIXED or ENHANCED addressing), if there is no match it will check for user-defined mappings.

When the API was first designed, the main purpose was to strictly match the standards that is why the user-defined mappings are checked after the standardized 29 bit CAN IDs. In your case there is a match.. so your mapping is not checked. Afterwards the ISO-TP message is discarded by UDS API as the identified target address does not match the address you set with PUDS_PARAM_SERVER_ADDRESS.

To conclude, your problem could indeed be solved by disabling the Enhanced format addressing. Unfortunately this feature is not yet available, but a new release could be made soon. If you wish I can send you a beta version when it is ready.. if so please send a request to the support team (support[at]peak-system.com).

[element42]

Again thanks for your quick and clarifying reply I will contact the official support team in order to get the issue either solved or 'worked-around' as soon as possible.

[horibamira]

Hi, I think I may have the same problem with receiving 29 bit IDs. My ECU is responding but the UDS API is reporting no data. Is there a beta version of the API that resolves this issue available? Many Thanks.

Code: Select all

	// 29 bit can ID, normal format addressing (diagnostic message mandatory) - 
	Status = CANTP_AddMapping(Channel, 0x1CDA93F9, 0x1CDAF993,
		PCANTP_ID_CAN_29BIT, PCANTP_FORMAT_FIXED_NORMAL, PCANTP_MESSAGE_DIAGNOSTIC,
		N_AI.SA, N_AI.TA, PCANTP_ADDRESSING_PHYSICAL, 0x00);
	printf("TP Mapping status 1: %i\n", (int)Status); 

	CANTP_AddMapping(Channel, 0x1CDAF993, 0x1CDA93F9,
		PCANTP_ID_CAN_29BIT, PCANTP_FORMAT_FIXED_NORMAL, PCANTP_MESSAGE_DIAGNOSTIC,
		N_AI.TA, N_AI.SA, PCANTP_ADDRESSING_PHYSICAL, 0x00);
	printf("TP Mapping status 2: %i\n", (int)Status); 

[F.Vergnaud]

Hello,

You can download the latest version of PCAN-ISO-TP API on our website (v2.0.1.82), it fixes the problem as user's mappings now supersede standardized 29 bits CAN IDs.

[horibamira]

Hi, many thanks for your reply. I am using that this version already. I have modified the PCUClient sample app (x64) to work with my setup. Perhaps I done something wrong. I can see the UDS requests from the client are correct and my ECU sends a reply (I can see it in PCAN-View). Below is the code I have modified to work with my setup. Is there something wrong here?

Code: Select all

	// Set the PCAN-Channel to use (PCAN-USB Channel 1)
	Channel = PUDS_USBBUS1;
	// Initializing of the UDS Communication session 
	Status = UDS_Initialize(Channel, PUDS_BAUD_500K, 0, 0, 0);
	printf("Initialize UDS: %i\n", (int)Status);

	// Define Address
	iBuffer = 0x93;
	Status = UDS_SetValue(Channel, PUDS_PARAM_SERVER_ADDRESS, &iBuffer, 1);
	printf("  Set ServerAddress: %i (0x%02x)\n", (int)Status, iBuffer);
	// Define TimeOuts
	ulBuffer = 2000;
	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);
	

	
	// Define Network Address Information used for all the tests
	N_AI.SA = 0xF9;
	N_AI.TA = 0x93;
	N_AI.TA_TYPE = PUDS_ADDRESSING_PHYSICAL;
	N_AI.RA = 0x00;
	N_AI.PROTOCOL = PUDS_PROTOCOL_ISO_15765_2_29B;
	
	//Transport configuration - Allied Motion
	//Priority set to 7
	iBuffer = 0x07;
	CANTP_SetValue(Channel, PCANTP_PARAM_J1939_PRIORITY, &iBuffer, 1);
	// Data paddding byte value
	iBuffer = 0x55;
	CANTP_SetValue(Channel, PCANTP_PARAM_PADDING_VALUE, &iBuffer, 1);
	

	// 29 bit can ID, normal format addressing (diagnostic message mandatory) - using VCI ID from SCANIA DBC
	Status = CANTP_AddMapping(Channel, 0x1CDA93F9, 0x1CDAF993,
		PCANTP_ID_CAN_29BIT, PCANTP_FORMAT_FIXED_NORMAL, PCANTP_MESSAGE_DIAGNOSTIC,
		N_AI.SA, N_AI.TA, PCANTP_ADDRESSING_PHYSICAL, 0x00);
	printf("TP Mapping status 1: %i\n", (int)Status); 

	CANTP_AddMapping(Channel, 0x1CDAF993, 0x1CDA93F9,
		PCANTP_ID_CAN_29BIT, PCANTP_FORMAT_FIXED_NORMAL, PCANTP_MESSAGE_DIAGNOSTIC,
		N_AI.TA, N_AI.SA, PCANTP_ADDRESSING_PHYSICAL, 0x00);
	printf("TP Mapping status 2: %i\n", (int)Status); 	

	CANTP_AddMapping(Channel, 0x1CDBFFF9, CAN_ID_NO_MAPPING,
		PCANTP_ID_CAN_29BIT, PCANTP_FORMAT_FIXED_NORMAL, PCANTP_MESSAGE_DIAGNOSTIC,
		N_AI.SA, N_AI.TA, PCANTP_ADDRESSING_FUNCTIONAL, 0x00);

	waitGetch();

[F.Vergnaud]

You are trying to define a mapping with a format addressing (PCANTP_FORMAT_FIXED_NORMAL) that does not require a mapping. You must use PCANTP_FORMAT_NORMAL instead:

Code: Select all

	// 29 bit can ID, normal format addressing (diagnostic message mandatory) - using VCI ID from SCANIA DBC
	Status = CANTP_AddMapping(Channel, 0x1CDA93F9, 0x1CDAF993,
		PCANTP_ID_CAN_29BIT, PCANTP_FORMAT_NORMAL, PCANTP_MESSAGE_DIAGNOSTIC,
		N_AI.SA, N_AI.TA, PCANTP_ADDRESSING_PHYSICAL, 0x00);
	printf("TP Mapping status 1: %i\n", (int)Status);

	Status = CANTP_AddMapping(Channel, 0x1CDAF993, 0x1CDA93F9,
		PCANTP_ID_CAN_29BIT, PCANTP_FORMAT_NORMAL, PCANTP_MESSAGE_DIAGNOSTIC,
		N_AI.TA, N_AI.SA, PCANTP_ADDRESSING_PHYSICAL, 0x00);
	printf("TP Mapping status 2: %i\n", (int)Status);

	Status = CANTP_AddMapping(Channel, 0x1CDBFFF9, CAN_ID_NO_MAPPING,
		PCANTP_ID_CAN_29BIT, PCANTP_FORMAT_NORMAL, PCANTP_MESSAGE_DIAGNOSTIC,
		N_AI.SA, N_AI.TA, PCANTP_ADDRESSING_FUNCTIONAL, 0x00);

[horibamira]

Thank you. I have tried this but still no uds response is reported.