SvcReadDataByPeriodicIdentifier_2013

[fabio.parodi@technoleader.it]

Hello

I am using the function SvcReadDataByPeriodicIdentifier_2013.
The protocol works fine and I see on the can bus the full set of identifiers thet I've defined before (SvcDynamicallyDefineDataIdentifierDBMA_2013).

Code: Select all

     7)    201381.5  Rx         07E4  8  10 19 2C 02 F2 00 13 01 	request: SvcDynamicallyDefineDataIdentifierDBMA_2013
     8)    201413.1  Rx         07EC  3  30 1F 00 
     9)    201413.4  Rx         07E4  8  21 00 00 02 01 00 04 04 
    10)    201413.5  Rx         07E4  8  22 01 00 08 04 01 00 0C 
    11)    201413.5  Rx         07E4  8  23 04 01 00 10 04 55 55 
    12)    201453.2  Rx         07EC  5  04 6C 02 F2 00 		positive ack to SvcDynamicallyDefineDataIdentifierDBMA_2013
    13)    209303.4  Rx         07E4  8  03 2A 02 00 55 55 55 55 	request: SvcReadDataByPeriodicIdentifier_2013
    14)    209353.6  Rx         07EC  8  10 14 6A 00 34 12 CD AB 	positive ack to SvcReadDataByPeriodicIdentifier_2013
    15)    209353.9  Rx         07E4  8  30 1F 00 55 55 55 55 55 
    16)    209393.7  Rx         07EC  8  21 78 56 AA 55 00 00 01 
    17)    209394.3  Rx         07EC  8  22 00 00 00 02 00 00 00 
    18)    209552.8  Rx         07EC  8  10 14 6A 00 34 12 CD AB 	ECU keep sending data at regular intervals
    19)    209553.1  Rx         07E4  8  30 1F 00 55 55 55 55 55 
    20)    209553.4  Rx         07EC  8  21 78 56 AA 55 00 00 01 
    21)    209553.9  Rx         07EC  8  22 00 00 00 02 00 00 00 
    22)    209753.0  Rx         07EC  8  10 14 6A 00 34 12 CD AB 	ECU keep sending data at regular intervals
    23)    209753.2  Rx         07E4  8  30 1F 00 55 55 55 55 55 
    24)    209753.5  Rx         07EC  8  21 78 56 AA 55 00 00 01 
    25)    209754.0  Rx         07EC  8  22 00 00 00 02 00 00 00 
    26)    209953.0  Rx         07EC  8  10 14 6A 00 34 12 CD AB 	ECU keep sending data at regular intervals
    27)    209953.4  Rx         07E4  8  30 1F 00 55 55 55 55 55 
    28)    209953.6  Rx         07EC  8  21 78 56 AA 55 00 00 01 
    29)    209954.2  Rx         07EC  8  22 00 00 00 02 00 00 00 
    ... continue ...

I have two problems.

First problem: after calling SvcReadDataByPeriodicIdentifier_2013, I call WaitForService_2013 and get the response.
I expected the response to carry all data, however, I only see the first 5 bytes (those in the first can bus message 00 34 12 CD AB); then following bytes are zeros.
This is the C# code:

Code: Select all

        Byte[] periodic_data_identifier = { 0 };
        result = UDSApi.SvcReadDataByPeriodicIdentifier_2013(
            canport, config, out uds_msg request,
            uds_svc_param_rdbpi.PUDS_SVC_PARAM_RDBPI_SAMR,
            periodic_data_identifier, (uint)periodic_data_identifier.Length);
        if (UDSApi.StatusIsOk_2013(result)) {
            uds_msg response = new uds_msg();
            result = UDSApi.WaitForService_2013(canport,
                ref request, out response, out request_confirmation);
            for (int i = 0; i < 0x14; i++) {
                UDSApi.GetDataParameter_2013(ref response, i, out byte x);
                Console.Out.WriteLine($"x = {x:X2}");
            }

Second problem: the ECU keeps sending data at regular intervals.
How to use the UDS API to get this data?
For sure I cannot call SvcReadDataByPeriodicIdentifier_2013 again.


Thanks and regards

Fabio

[F.Vergnaud]

Hello Fabio,

First problem: after calling SvcReadDataByPeriodicIdentifier_2013, I call WaitForService_2013 and get the response.
I expected the response to carry all data, however, I only see the first 5 bytes (those in the first can bus message 00 34 12 CD AB); then following bytes are zeros.

Regarding the data you received, please assert that the UDS message returned by the function WaitForService is OK:
- WaitForService returns OK if a message is available, but it does not mean that the message is valid!
- you must check the network result of that message and its ISOTP message's type.
If you get zeros, I'd say you are reading a message's indication (first frame) and a network error occured during the communication.

About UDS ReadDataByPeriodicIdentifier: when calling this service, you should get 2 responses from your ECU, as stated in ISO-14229-1:2020 §11.5:

There shall be a distinction between the initial positive response message, which indicates that the server accepts the service and subsequent periodic data response messages, which include periodicDataIdentifier data.

In your case, the data of the first response should be something like "01 6A" and the periodic message should not include the positive response service ID (0x6A = 0x40+0x2A).

How to use the UDS API to get this data?

You should call UDS_Read to get those messages.
You can find a sample for this service in our UDS package, please check example "12_client_request_ReadDataByPeriodicIdentifier".

[fabio.parodi@technoleader.it]

Thanks Fabrice for answering.
You are right, there was a mistake in the server protocol. Now the trace should be correct:

Code: Select all

    17)    110204.2  Rx         07E4  8  03 2A 02 00 55 55 55 55 	PC calls SvcReadDataByPeriodicIdentifier_2013 with sid = 00 
    18)    110241.8  Rx         07EC  2  01 6A 				device responds OK
    19)    110262.0  Rx         07EC  8  10 2B 00 CD AB 34 12 AA 	device sends periodic data with sid = 00
    20)    110263.1  Rx         07E4  8  30 1F 00 55 55 55 55 55 	PC flow control
    21)    110302.0  Rx         07EC  8  21 55 01 00 00 00 02 00 	device sends the rest
    22)    110302.5  Rx         07EC  8  22 00 00 03 00 00 00 04 
    23)    110303.1  Rx         07EC  8  23 00 00 00 05 00 00 00 
    24)    110303.7  Rx         07EC  8  24 06 00 00 00 07 00 00 
    25)    110304.2  Rx         07EC  8  25 00 08 00 00 00 09 00 
    26)    110304.6  Rx         07EC  3  26 00 00 
    27)    110462.1  Rx         07EC  8  10 2B 00 CD AB 34 12 AA 	device sends periodic data with sid = 00
    28)    110463.3  Rx         07E4  8  30 1F 00 55 55 55 55 55 	PC flow control
    29)    110502.2  Rx         07EC  8  21 55 01 00 00 00 02 00 	device sends the rest
    30)    110502.7  Rx         07EC  8  22 00 00 03 00 00 00 04 
    31)    110503.3  Rx         07EC  8  23 00 00 00 05 00 00 00 
    32)    110503.8  Rx         07EC  8  24 06 00 00 00 07 00 00 
    33)    110504.3  Rx         07EC  8  25 00 08 00 00 00 09 00 
    34)    110504.7  Rx         07EC  3  26 00 00 

Now I am able to receive the periodic messages by using UDSApi.Read_2013. This function gives me two messages:
- the first one, contains just the 5 initial bytes, the rest is zero
- the second one is good, it contains all the data
However, both messages have type == uds_msgtype.PUDS_MSGTYPE_USDT.
This is the c# code I am using to receive:

Code: Select all

                uds_status result = UDSApi.Read_2013(canport, out out_msg_buffer);
                Debug.WriteLine($"read --> {result}");
                if (result == uds_status.PUDS_STATUS_OK)
                {
                    Debug.WriteLine($"out_msg_buffer.type: {out_msg_buffer.type}");
                    if (out_msg_buffer.type == uds_msgtype.PUDS_MSGTYPE_USDT)
                    {
                        UDSApi.GetDataServiceId_2013(ref out_msg_buffer, out byte sid);
                        Debug.WriteLine($"sid = {sid:X2}h");
                        for (int i = 0; i < 0x2a; i++)
                        {
                            UDSApi.GetDataParameter_2013(ref out_msg_buffer, i, out byte x);
                            Debug.WriteLine($"data[{i}] = {x:X2}h");
                        }
                    }
                }

[F.Vergnaud]

Hello,

When you check "out_msg_buffer.type" you check a uds_msgtype: it contains information related to the UDS message type (USDT, UUDT, with Flag no response, etc.).
In your case, if you want to identify the type of the ISOTP message encapsulated in the UDS message you need to access "out_msg_buffer.msg.msgdata.isotp.netaddrinfo.msgtype"

[fabio.parodi@technoleader.it]

Thanks. Now it works.