Negative response doesn't give a error on the status

[barry]

I noticed when you get a negative response from the product (0x7F) the status of the waitforservice function
is still ERROR_OK.
Is this standard behaviour and do you need to check the data of the message if you got a negative response,
or can you change a setting so negative response cause the status to generate an error ?

example :
status = UDSApi.WaitForService(canchannel, out MessageResponse, ref Message, out MessageReqBuffer);

[K.Wagner]

Hello,

yes this is normal. The PUDS_ERROR_OK means that the "wait service action" has worked, since the transmission was confirmed and a response was received (and that it was copied into the parameter MessageBuffer). At this point it doesn't matter if the response is positive or negative, only that it arrives. You need to check the MessageBuffer to see if the response was negative or positive.

[uyouu]

Hello,

yes this is normal. The PUDS_ERROR_OK means that the "wait service action" has worked, since the transmission was confirmed and a response was received (and that it was copied into the parameter MessageBuffer). At this point it doesn't matter if the response is positive or negative, only that it arrives. You need to check the MessageBuffer to see if the response was negative or positive.

status = UDSApi.WaitForService(canchannel, out MessageResponse, ref Message, out MessageReqBuffer);
status = 7(No message ) i dont know how to solve this

[K.Wagner]

Hello,

I'm not sure to understand what you want to do, or if you know what you want to do.

UDS_WaitForService is used to wait for a response to a "previous sent message". This previous message should be an UDS Service (as the function name suggests), that causes a response on the server side (e.g., an ECU). That response is a message that is sent from server to client, which is stored in the receive queue of the PUDS-API (your application). In this manner you will able to read a response-message from the function UDS_WaitForService.

An example of such a process could be to set a diagnostic session to DEFAULT:

Code: Select all

	TPUDSStatus Status;
	TPUDSMsg Message = {};
	TPUDSMsg MessageResponse = {};	

	// initialization
	Message.NETADDRINFO = N_AI;

	printf("\n\n*** UDS Service: DiagnosticSessionControl ***\n");

	// Set Diagnostic session to DEFAULT (to get session information)
	printf("\n\nSetting a DEFAULT Diagnostic Session :\n");
	Status = UDS_SvcDiagnosticSessionControl(Channel, &Message, PUDS_SVC_PARAM_DSC_DS);
	if (Status == PUDS_ERROR_OK)
		Status = UDS_WaitForService(Channel, &MessageResponse, &Message);
	printf("  UDS_SvcDiagnosticSessionControl: %i\n", (int)Status);
	if (Status == PUDS_ERROR_OK)
		displayMessage(&Message, &MessageResponse);
	else
		displayMessage(&Message, NULL);

This code uses the UDS service "PUDS_SVC_PARAM_DSC_DS (Default session)" to try to set a diagnostic session to DEFAULT, and then waits for the result of the service. You can find this code and other examples within the Project delivered together with the UDS Package (PCUClient)

[uyouu]

Yes,I use the source like the examples in c# coding progress,
like this:

Code: Select all

	Status = UDS_SvcDiagnosticSessionControl(Channel, &Message, PUDS_SVC_PARAM_DSC_DS);
	if (Status == PUDS_ERROR_OK)
		Status = UDS_WaitForService(Channel, &MessageResponse, &Message);

But the status == 7(no message), not ==0(ErrorOk)and the response is null,i want to know the reason of Error.
Thank you so much.

[K.Wagner]

Do you have any Server that can response your message? are you sure this responses well and that it is UDS conform? Coul dyou test this with other software?

[uyouu]

yes , the status in server is error ok ,and write success,but in client i have no response ,i use the
"SvcDiagnosticSessionControl(Channel, &Message, 0x03)" and status is Error OK
and there is no response,so I don't know the reason

[F.Vergnaud]

Hello uyouu,

Here are some advices to help you communicate with your ECU:
1. Ensure that the ECU is able to communicate with standardized settings (check its specifications):
- the ECU address is in the range 0x01 - 0x08,
- Supports NORMAL addressing with standardized OBD CAN IDs (functional addressing from client to ECUs is 0x7DF, physical addressing from TesterClient (0xF1) to ECU#1 (0x01) is 0x7E0 and response from ECU#1 is 0x7E8, etc.).
2. If it is not the case you have to configure the underlying ISO-TP (that is used by UDS API) to allow new communication settings. This is done by calling CANTP_AddMaping. Here is a quote from another thread that explains how mapping works:

In an ISO-TP communication, there is a client and a server, for instance: an External Test Equipment defined as 0xF1 in OBD standards and an ECU as 0x01.
When a client sends a request to a server, the source address is the client's address and the target is the server's address. When the server sends a response, it is the other way round : the source is the server address and the target is the client's address.
CANTP_AddMapping let you inform the API that a CAN frame (identified by its CAN ID) corresponds to a specific Network Addressing Information in the ISO-TP protocol and that it should be handle. Therefore to handle physically addressed request/response you need to define 2 mappings, for instance:
- one (with CAN ID 0xYYYY) where source is 0xF1 and target is 0x01,
- and another (with CAN ID 0xZZZ) where source is 0x01 and target is 0xF1.

3. Be aware that UDS API also defines a parameter called PUDS_PARAM_SERVER_ADDRESS, it defines the address of the application (by default it is 0xF1 = TesterClient). If you're developping an ECU, you'll have to change this because any received messages that are not for that address will be discarded by the API.

If you're still not able to receive messages from the ECU, you should listen to the CAN frames via PCAN-View and post them here in order to give us extra information.

[uyouu]

Thank you so much ,i solve the problem.