UDS-API parameter interpretation issue with x64 DLLs

A free API for the communication with control devices according to UDS (ISO 14229-1)
Post Reply
evilpaul
Posts: 3
Joined: Sat 29. Jun 2019, 16:07

UDS-API parameter interpretation issue with x64 DLLs

Post by evilpaul » Sat 29. Jun 2019, 16:40

Hi,

I've been playing around with the UDS-API and I've found an issue affecting the x64 DLLs and interpretation of parameters that differs from the x86 DLLs.

Test Scenario 1:
  • PCAN-bASIC DLL version 4.3.3.239
  • PCAN-ISO-TP DLL version 2.2.0.119
  • PCAN-UDS DLL version 1.3.2.45
  • Compile the C++ sample apps included in the PCAN-UDS package for 32bit
  • Connect CAN channels 1 & 2 of PCAN-USB Pro FD with a physical connection and termination resistor
  • Run x86 PCUServer and x86 PCUClient apps and log the CAN communication
Test Scenario 2:
  • PCAN-bASIC DLL version 4.3.3.239
  • PCAN-ISO-TP DLL version 2.2.0.119
  • PCAN-UDS DLL version 1.3.2.45
  • Compile the PCUClient C++ sample app included in the PCAN-UDS package for 64bit
  • Connect CAN channels 1 & 2 of PCAN-USB Pro FD with a physical connection and termination resistor
  • Run x86 PCUServer (from Test Scenario 1) and x64 PCUClient app and log the CAN communication
Expected Result:
Both test cases use the same application code, but are compiled for different architectures. My expectation is that the resulting CAN communication from both test scenrios should be exactly the same.

Actual Result:
When comparing the test results from both test scenarios then the CAN communication differs in some cases:
x86 log:https://gist.github.com/Evilpaul/042d45 ... b710272487
x64 log:https://gist.github.com/Evilpaul/6a6b03 ... 042f798b3c

Analysing the differences then it appears that there is parameter interpretation issues on some x64 API calls:
  • UDS_SvcReadScalingDataByIdentifier(TPUDSCANHandle CanChannel, TPUDSMsg * MessageBuffer, WORD DataIdentifier);
  • UDS_SvcDynamicallyDefineDataIdentifierDBID(TPUDSCANHandle CanChannel, TPUDSMsg * MessageBuffer, WORD DynamicallyDefinedDataIdentifier, WORD * SourceDataIdentifier, BYTE * MemorySize, BYTE * PositionInSourceDataRecord, WORD BuffersLength);
  • UDS_SvcDynamicallyDefineDataIdentifierDBMA(TPUDSCANHandle CanChannel, TPUDSMsg * MessageBuffer, WORD DynamicallyDefinedDataIdentifier, BYTE MemoryAddressLength, BYTE MemorySizeLength, BYTE * MemoryAddressBuffer, BYTE * MemorySizeBuffer, WORD BuffersLength);
  • UDS_SvcDynamicallyDefineDataIdentifierCDDDI(TPUDSCANHandle CanChannel, TPUDSMsg * MessageBuffer, WORD DynamicallyDefinedDataIdentifier);
  • UDS_SvcWriteDataByIdentifier(TPUDSCANHandle CanChannel, TPUDSMsg * MessageBuffer, WORD DataIdentifier, BYTE * Buffer, WORD BufferLength);
  • UDS_SvcInputOutputControlByIdentifier(TPUDSCANHandle CanChannel, TPUDSMsg * MessageBuffer, WORD DataIdentifier, BYTE * ControlOptionRecord, WORD ControlOptionRecordLength, BYTE * ControlEnableMaskRecord, WORD ControlEnableMaskRecordLength);
  • UDS_SvcRoutineControl(TPUDSCANHandle CanChannel, TPUDSMsg * MessageBuffer, BYTE RoutineControlType, WORD RoutineIdentifier, BYTE * Buffer, WORD BufferLength);
The highlighed parameters above are those that show differences between x86 and x64. As a workaround when using x64 versions then these parameters should be byte swapped and bit inverterted, this will then give the same CAN output as the x86 version.

The above list is not exhaustive and only covers those commands as tested in the sample app. I have also verfied the above using the C# interface and got the same results: https://github.com/Evilpaul/PCUClient

K.Wagner
Software Development
Software Development
Posts: 1080
Joined: Wed 22. Sep 2010, 13:36

Re: UDS-API parameter interpretation issue with x64 DLLs

Post by K.Wagner » Mon 1. Jul 2019, 08:36

Hello,

there was a bug with the PCAN-UDS version 1.3.2.45, in which some bytes were swapped wrong (intel/motorola format). Please download the latest version, v1.3.3.50, and try again. Here you find the history of changes: https://www.peak-system.com/PCAN-UDS-API.373.0.html

Thanks,
Best regards,
Keneth

Post Reply