How to read a UDS Service Response via EVENT

[awild]

Hi to all,

I trigger a service request via UDSApi.SvcReadDataByIdentifier(). The PID/LEV is 0xFD 0x54.
The reception of the response (33Bytes) workes fine with UDSApi.WaitForService().

However I want the reception to be event driven.
The event fires ok, in the eventhandler I try to pick out the right message by

a) multiple calls of UDSApi.Read() until the result is TPUDSStatus.PUDS_ERROR_NO_MESSAGE
b) checking each received message, for the appropriate type to hold my data

I think TPUDSMessageType.PUDS_MESSAGE_TYPE_INDICATION is an indicator for coming data...

However I get 4 messages with the following content:
Message 1:
MSGTYPE = PUDS_MESSAGE_TYPE_CONFIRM
LEN = 3
DATA = 0x22 0xFD 0x54

Message 2:
MSGTYPE = PUDS_MESSAGE_TYPE_INDICATION
LEN = 33
DATA = 0x62 0xFD 0x54 0xFF 0x4E 0x01 ---> the next bytes ARE NOT INITIALIZED !!!

Message 3:
MSGTYPE = PUDS_MESSAGE_TYPE_CONFIRM
LEN = 33
DATA = 0x62 0xFD 0x54 0xFF 0x4E 0x01 ---> the data is correct until the end

Message 4:
MSGTYPE = PUDS_MESSAGE_TYPE_CONFIRM
LEN = 0
DATA = not initialized

So effectivly I get 3! messages with type PUDS_MESSAGE_TYPE_CONFIRM.
What is the best way to filter out the correct message containing the data?

Thanks again for your help
Andy

[K.Wagner]

Hello,

I think TPUDSMessageType.PUDS_MESSAGE_TYPE_INDICATION is an indicator for coming data...

yes, this is a message indicating that data is pending

However I get 4 messages with the following content:

The Message 1 is the confirmation of your request.
The Message 2 is the beginning of the response; it is normal that not all data bytes are valid since not all the data is retrieved yet.
The Message 3 is the confirmation of the response; the requested data was completely received.
The Message 4 is very strange, especially with a length of 0. We cannot understand this message.

So effectivly I get 3! messages with type PUDS_MESSAGE_TYPE_CONFIRM.
What is the best way to filter out the correct message containing the data?

the filtering you mean is actually what the UDS_WaitFor... functions do. If you keep using UDS_Read, you need to check the NETADDRINFO.SA/TA to distinguish request from responses, check that the RESULT field of those is OK (0), that the message type is PUDS_MESSAGE_TYPE_CONFIRM, etc. until you get all your data. Note that you also have to take care about errors like "PUDS_NRC_EXTENDED_TIMING" that can arise when the ECU needs more time to process a request.

Instead of using the UDS_Read, you could use the function UDS_WaitForSingleMessage(). This function waits for a response to a given UDS request. You can still use your even driven approach, but instead of call UDS_Read several times on signal, you call WaitForSingleMessage once.

[awild]

Hi Keneth,

thank you for the hint, this is indeed much easier and works ok !

However there is something curious in defining the request message for the WaitForSingleMessage() function:

Code: Select all

            TPUDSMsg request = new TPUDSMsg(); 
            request.NETADDRINFO.SA = ClientAdr;
            request.NETADDRINFO.TA = ECUAdr;
            request.NETADDRINFO.TA_TYPE = TPUDSAddressingType.PUDS_ADDRESSING_PHYSICAL;
            request.NETADDRINFO.RA = 0x00;
            request.NETADDRINFO.PROTOCOL = TPUDSProtocol.PUDS_PROTOCOL_ISO_15765_2_29B_NORMAL;
            request.DATA = new byte[4095];
            request.DATA[0] = 0x22;
            request.DATA[1] = 0;
            request.DATA[2] = 0;
            request.LEN = (ushort)request.DATA.Length;
            request.MSGTYPE = TPUDSMessageType.PUDS_MESSAGE_TYPE_REQUEST;

As you can see I set DATA[1]=0 and DATA[2]=0 on purpose in order to check whether WaitForSingleMessage() is able to filter the message correct.
I expected no message reception, because the PID/LEV of the UDS Service is wrong.
But I received the response fine!
Why has DATA[1] and DATA[2] no meaning in terms of selecting the right response?
Thereafter I set DATA[0] = 0x21.
Then there was no reception, as to be expected.
It seems that only the SID is verified to detect the UDS message to receive?

Thank you very much
Andy

[K.Wagner]

Hello,

here an extract of the help that may explain what is happening:

Note: the criteria to identify if a response matches the message request is based only on the network
addressing information and the UDS service identifier: if a same service is requested multiple times with
different parameters (like service ReadDataByIdentifier with different Data IDs), the user will have to
ensure that the extra content matches the original request.