UDSApi.Initialize too much time?

[vddvss]

Hello Keneth,

Thank you for the quick reply!

I am a little bit afraid to just updating each API to the latest version.

I have developed my wrapper DLL in "waves", meaning I have done some work last year, and since 9 months, nothing. In another project I have started to develop a new branch of my wrapper that sits on top of the UDS API, this started 1 week ago. For this new branch I decided to use the latest of every API, DLL, etc. For the new branch, I have re-used some code of my old development branch (old: versions as listed in my first reply), and noticed, that something very basic like UDS service 0x2E (Write Data by Identifier) changed its behavior. In my old development branch I used certain IDs to be read first (service 0x22 = Read Data By Identifier) and the written back (0x2E) with different data. The ID stayed the same with both. Now, with everything updated, when I read an existing ID with 0x22, I get the expected result, and when trying to write with 0x2E service, the actual CAN trace shows that the ID part of the command sends an ID, that I did not intend to send. An actual example: I wish to send (all hex bytes): 10 09 2E F1 98 00 00 00 , but the wire capture shows (PCAN View): 10 09 2E 67 0E 00 00 00. Notice the bytes F1 and 98, this is the intended ID (MSB and LSB), the actual ID sent out is: 67 0E, which comes from 0xFFFF - 0x98F1. So a 1's complement of a byte order swapped ID, it seems. If this is something that changed in the UDS protocol standard, then I was unaware thereof. But such changes prevents me to just swap out the APIs and DLLs to the latest one, because of its risks.

Does your idea suggest that by updating to the latest APIs, DLLs, etc, my problem should go away? Or is it just a first step in clearing this issue up?

Considering the above described, how else could I approach the problem? Is that specific compiled DLL out of the question, that you sent to forum user Cappo?

Thank you and Best Regards:
Balazs

[K.Wagner]

Hello,

Does your idea suggest that by updating to the latest APIs, DLLs, etc, my problem should go away? Or is it just a first step in clearing this issue up?

yes. As I said in the post, the winsock library was being used for silly operations and the linkage of the library was taking additional time in some scenarios. The new version doesn't have any linking to this library anymore, so that the delay shouldn't happen.

Considering the above described, how else could I approach the problem? Is that specific compiled DLL out of the question, that you sent to forum user Cappo?

Even though there are several months between the modification regarding Winsock and the release date of the last version of PCAN-UDS, not to many changes were made. None of the changes done have anything to do with message sending or message addressing. You will need to re-check your code and see if you have missed something while copying code. Check if all mappings you need are configured, that the types of messages being sent and their configured protocol is also correct, etc.

[vddvss]

Hello Keneth,

Thank you again for the quick reply.

I went and copied the "old" version (Version: 1.2.1.18) of PCAN-UDS.dll next to my wrapper DLL.
I have left my wrapper code unchanged.
Now the wire capture of the 0x2E is correct (with known working DID of 0xF198):
10 09 2E F1 98 00 00 00

I have copied back the latest version (Version: 1.3.2.45) of PCAN-UDS.dll next to my wrapper DLL.
I have left my wrapper code unchanged.
Now the wire capture of the 0x2E is incorrect (with known working DID of 0xF198):
10 09 2E 67 0E 00 00 00

I can't exclude, that any part of my code plays a role here, but I do not believe so.
I include the relevant code parts of my wrapper:

The implementation of the WDBI service:

Code: Select all

public int PEAK_UDS_wdbi(ushort id, byte[] dataBuffer)
{
    int iter = 0;

    do
    {
        result = UDSApi.SvcWriteDataByIdentifier(CAN_Channel, ref request, id, dataBuffer, (ushort)dataBuffer.Length);
        if (result == TPUDSStatus.PUDS_ERROR_OK) result = UDSApi.WaitForService(CAN_Channel, out response, ref request, out requestConfirmation);
        Thread.Sleep(++iter * sleepRaster);
    }
    while ((response.LEN == 3) && (response.DATA[2] == 0x21) && (iter < iterMax)); // checking for the 0x21, "busy, repeat request" situation

    if (result == TPUDSStatus.PUDS_ERROR_OK) return 0;
    else return (int)result;
}

My channel mapping routines:

Code: Select all

// add mapping
ISO_TP_result = CanTpApi.AddMapping(Channel, CAN_TX_ID, CAN_RX_ID, IDtype, TPCANTPFormatType.PCANTP_FORMAT_NORMAL, TPCANTPMessageType.PCANTP_MESSAGE_DIAGNOSTIC, 0xF1, 0x01, TPCANTPAddressingType.PCANTP_ADDRESSING_PHYSICAL, 0x00);
    if (ISO_TP_result != TPCANTPStatus.PCANTP_ERROR_OK) return (int)result;
    ISO_TP_result = CanTpApi.AddMapping(Channel, CAN_RX_ID, CAN_TX_ID, IDtype, TPCANTPFormatType.PCANTP_FORMAT_NORMAL, TPCANTPMessageType.PCANTP_MESSAGE_DIAGNOSTIC, 0x01, 0xF1, TPCANTPAddressingType.PCANTP_ADDRESSING_PHYSICAL, 0x00);
    if (ISO_TP_result != TPCANTPStatus.PCANTP_ERROR_OK) return (int)result;

Initialization of the request structure:

Code: Select all

// initialization of request structure
    request.NETADDRINFO.SA = (byte)TPUDSAddress.PUDS_ISO_15765_4_ADDR_TEST_EQUIPMENT;
    request.NETADDRINFO.TA = (byte)TPUDSAddress.PUDS_ISO_15765_4_ADDR_ECU_1;
    request.NETADDRINFO.TA_TYPE = TPUDSAddressingType.PUDS_ADDRESSING_PHYSICAL;
    request.NETADDRINFO.RA = 0x00;
    request.NETADDRINFO.PROTOCOL = TPUDSProtocol.PUDS_PROTOCOL_ISO_15765_2_11B;

What could cause this behavior?

Thank you and Best Regards:
Balazs

[K.Wagner]

Hello,

please repeat the test but updating "all 3" APIs (ISO-TP, UDS, and PCAN-Basic). Note that the versions you are using are 3 years old and the APIs are depending on each other. It is possible that UDS is doing a configuration that is not present in the old ISO-TP dll you have.

Note that the mappings you are doing are automatically defined by PCAN-UDS. A list of those mappings can be found in the page 338 of the (new) UDS documentation.

If the problem still persists, we will then need to check this closer.

[vddvss]

Hello Keneth,

Here are the details:

Downloaded PEAK-System_Driver-Setup.zip on the 3rd of June, 2019. Contained the file: PeakOemDrv.exe with file date of 6th of February, 2019. This installed the PCANBasic.dll in C:\Windows\System32\ with version: 4.3.2.161

I have downloaded on the same day (3rd of June, 2019), the file: pcan-basic.zip, from that, I have copied the file:
PCANBasic.dll into C:\Windows\System32\, which has version: 4.3.3.239

I have downloaded on the same day (3rd of June, 2019), the file: PCAN-ISO-TP.ZIP, this contained: PCAN-ISO-TP.dll version: 2.2.0.119
I have downloaded on the same day (3rd of June, 2019), the file: PCAN-UDS.ZIP, this contained: PCAN-UDS.dll version: 1.3.2.45

Using this setup and files, the wire capture of the 0x2E is incorrect (with known working DID of 0xF198):
10 09 2E 67 0E 00 00 00

Now copying the "old" PCAN-UDS.dll (version: 1.2.1.18) over the above listed new one next to my wrapper DLL (every other DLL, etc stays the same), produces the following, correct wire capture:
10 09 2E F1 98 00 00 00

I guess this means that we have to take a closer look.

Let me know what you need please. File versions, screen captures, you name it! I can arrange a Zoom meeting, where I can share my screen too.

Thank you for your time and effort!

Best Regards:
Balazs

[K.Wagner]

Hello,

we re-checked this now. It seems as indeed a bug was added in the last version of PCAN-UDS. Some replacements of htons and htonl were unfortunately forgotten. We are working in a fix. If you want to get a RC version to check if your problem is solved, then please write an email to support[at]peak-system.com making reference to this post.

Thanks for bringing this to our attention.

[vddvss]

Hello Keneth,

Thank you for looking into and fixing it!
I will definitely write to the support channel about the RC version to try.
What do you think, when can we check for a release version that has this fix in it?

Thank you and Best Regards:
Balazs

[K.Wagner]

Hello,

in a short time (this or next week). Our tests already corroborate that the problem is solved, but normally we wait for the confirmation from the one who found the problem, before releasing. So, send the email to our support, check that the problem is solved, and give us feedback. Then we will proceed to release this fix.

[vddvss]

Hello Keneth,

I can confirm, that the 32bit version of the RC of the fixed version of the PCAN-UDS DLL has the Write Data By Identifier service bug removed. The 64bit version I am currently unable to test myself.
I am still in the process of confirming if the "Init time delay" problem also disappeared or not with the change of the htons()... function call being made internally.

Thank you and Best Regards:
Balazs

[K.Wagner]

Hello,

thanks for your feedback. Closed.