bug(XCP Master Plugin - CCP): WORD (2-byte integer) values read incorrectly with Motorola (big-endian) byte order

I am using the XCP Master plugin in CCP mode. As the topic title states, 2-byte integers with byte order set to "Motorola" are not read correctly. "Intel" byte order appears to work as expected.

Example:

I have one channel with configuration shown in the attached picture, key values being a 2-byte integer with Motorola (big-endian) byte order. The value at the memory address is set externally to a value of 900.

The XCP event viewer log shows the received CCP DAQ bytes being:

00 03 84 FF FF FF FF FF

The (2) bytes corresponding to this channel are: 03 84

With Motorola (big-endian) mode, the received bytes are correct and as expected --> 0x0384 = 900.

Unfortunately, DEWESoft outputs a channel value of 0.

But DEWE appears to be looking at the correct bytes... If I switch the byte order from Motorola to Intel (little-endian), the DEWE output becomes 33795.

Which is correct, 0x8403 = 33795.

So something is buggy with DEWE's handling of 2-byte Motorola values.

As another test, I also externally changed the ECU memory address value to 0xFFFF = 65535 = UWORD max

The DEWE digital meter UI widget reading for this channel shows:

Motorola: Every second switching between 0 and -1.71465219159396E38

Intel: 65535

...where these output values should obviously both be 65535.

This appears to only be a problem for 2-byte integers. I tried with a ULONG (4-byte) Motorola, for example, and it output correctly.

Without source code, I am unable to pinpoint if the problem lies in the XCP plugin itself or the main DEWE program.

----------------------------------------------------------

DewesoftX

Version: 2021.2 (RELEASE-210430) (64-bit)

Build: Release

xCP            Plugin   4.0.1   Dewesoft       Active XCP64.dll

Hello Dane,

Thank you for reaching out to us.

We would appreciate to get your definition of the signal (.a2l file), for us to reproduce and look into the problem to find the source of the issue you are facing.

Best Regards.

@Matjaž Strniša

Attached is the .a2l file which only contains an "Engine Speed" measurement (identical to the channel in the screenshot I originally posted).

Hello Dane,

This issue will be solved in V4.0.2 of the XCP plugin. The version will be available with the next release of DewesoftX which will be probably in September this year.
We could get some Beta version prepared for you before that if needed.

Please let us know if that would be needed.

Best regards,
Matjaž

@Matjaž Strniša

 Thank you for looking into the issue and I am glad to hear a fix has been identified.



I would very much like to test a beta version of the plugin to validate the fix.

Please let me know when it is available, and thanks again.

Hello Dane,


I attached a beta version below.
This issue should be resolved.

Best regards.

@Matjaž Strniša

Thank you for the beta version. Upon testing, I can confirm the bug is NOT fixed. At least not fully fixed and it looks like another bug has been introduced.

First, back to the above example with only one 2-byte integer CCP channel enabled with it's value set to 900 (0x0384).

With byte order set to Intel (little endian), a constant value of 33795 (0x8403) is recorded, which is expected.

Now changing the byte order to Motorola (big endian), the value is not constant at 900 but is fluctuating often between 900 and 0. As was demonstrated with Intel byte ordering (and confirmed by the XCP log), the value is not actually fluctuating at all, so DEWE should be outputting a constant horizontal line at 900.

It's good to at least see the correct value of 900, but the crazy jumps from 900 -> 0 --> 900 -> 0 is an obvious issue. See attached screenshot.

----

Now for a second test, which raises a new bug report.

Introduce a second CCP channel, of type Float_IEEE (4-byte) with Motorola byte order. This float channel is externally set to a value of 759.669.

CCP DAQ bytes from the log are as follows:

00 44 3D EA E1 03 84 FF

Separating the bytes from the message:

0x00 = packet ID (PID)
0x443DEAE1 = 759.669...
0x0384 = 900

So the transferred bytes look good. The recorded float channel is properly displaying 759.669 in the DEWE recorder.

The 2-byte integer (Motorola) channel is still jumping to 0, but it is no longer going to 900 and is instead jumping to 17469.

17469 = 0x443D --> so clearly, this integer channel is reading the wrong bytes from the CCP DAQ message; reading the first two bytes following the data packet ID that are actually a part of the float variable.

Please pass along a new beta release for testing when these two issues are addressed.

----------------------

DewesoftX

Version: 2021.2 (RELEASE-210430) (64-bit)

Build: Release

xCP      Plugin  4.0.2_b5  Dewesoft    Active XCP64.dll

HI Dave,


I'm sorry for the late reply, our development team has prepared a new Beta version of xCP plugin.

For secure operation, we recommend using v3.0.3 found on Drive.

Thank you for your feedback which will be taken into account by our development team.

Kind regards

@Matjaž Strniša

All the above mentioned bugs in my last post appear to still be evident in the latest beta plugin provided (4.1.2b2)

The screenshot below shows the 2-byte motorola integer channel still bouncing around between 900 and 0. The bytes logged in the event viewer clearly show it should be constant at 900 (0x384).

DewesoftX

Version: 2021.3 (RELEASE-210621) (64-bit)

Build: Release

Dear Dane,

Thank you for your feedback.
Find below attached latest Beta version of xCP.
Those issues should be resolved here.

@Matjaž Strniša

Regarding 4.1.2b7 -

With a single 2-byte motorola integer channel used, I see the channel values no longer jumping back to 0, which is good.

The other issue I mentioned a few posts up still remains - if I enable multiple CCP channels, the wrong bytes are read for the 2-byte integer channel.

Please see the GIF in the attached zip file, where simply enabling a second CCP channel makes the "rpm" channel value change from 900 (expected) to 17469. An explanation of the misread bytes can be found from my post in this thread on 23.06.2021.

We appreciate the feedback and GIF you made.
Could we please get the xCP log file made with Beta for analysis purposes?

@Matjaž Strniša

Please see the log in the attached zip file. To create the log, I opened up DEWE and then duplicated the actions seen in the GIF.

@Matjaž Strniša

FYI - I was forwarded beta 4.2.0 of the XCP plugin from Ben Koskinen and the last mentioned problem still persists.

Hello Dan


Unfortunately, our developers till now didn't manage to reproduce this issue here. We would deeply appreciate getting an XCP log + data file with this 2-byte motorola integer and a2l file or only the definition of this signal in a2l file. That is the only way for our developers to see and dig into the problem.

Many thanks for your collaboration.
Best regards.

@Matjaž Strniša

Attached is the a2l file, XCP log, and data file for a very short test.

Hello,

Thank you so much for your collaboration.
I attached below the latest beta version of the plugin.

If the issue persists then we would kindly ask you to connect to you via TeamViewer and look into the problem on your side.
I can arrange to get the xCP plugin developer to be present and maybe gets the idea about the issue

I hope that the problem will be fixed with this beta version and thank you again for your patience.
Best regards.

@Matjaž Strniša

I tried the v4.2.1b1 plugin and the problem still exists. I may not be able to connect via TeamViewer due to network access restrictions, but I could setup a web call with desktop sharing.

Please contact me via the email attached to this account, and we'll figure something out.

Thanks for continuing to look into this.

Dear Dane,
I attached a version of xCP on Drive in which the problem regarding the data order in the motorola byte type should be fixed.

Please give us feedback regarding the fix.

Best regards.

@Matjaž Strniša

I just did a quick check with v4.2.1b5 and it looks like the problem is resolved. Thanks for the support!
Now that this problem is fixed, I'll be doing some further testing here soon and I'll report back if I notice any other issues.