Memory access violation

[XTOCON]

Dear Mr Zaiser,

First of all thank you so much for making publicly available this very nice implementation of the XCP protocol.

I'm a developer mostly using the Mathworks / dSpace toolchain combining Simulink for modelling and code-generation with ControlDesk for debugging and visualisation.

The code compiled without any issues on my Windows 64bit machine.

Using a demo version of CANape I was also able to visualize the different measurements and instances of the XCP objects.

However, when connecting with the ControlDesk client from dSpace, XCP Slave application crashes with a memory access violation on line 754 of src/xcpLite.c

            memcpy((uint8_t*)d, &base[OdtEntryAddr(e)], n);

I'm no expert at all in writing or understanding this type of C++ software but after a few days of trial-and-error debugging I was able to find a workaround for the issue:

            uint8_t addr = OdtEntryAddr(e);
            uint8_t *src = &base[addr];
            memcpy((uint8_t*)d, src, n);

I cannot explain why this piece of code, which as far as I can see is identical to the original, does work, and the original does not, but it seems to solve the issue.

Would you be able to shed some light on this issue?

Thank you very much for your time and effort

Kind regards

Christophe

[RainerZ]

Hi Christophe,

the code you pointed out is the inner loop of measurement data aquisition. An access violation there is most probably caused by incorrect addresses in the A2L file. Are you sure, you are using an up to date (the generated) A2L file in control desk?

Regards Rainer

[XTOCON]

Hi Rainer,

Thank you for your quick answer.

The problem is 100% reproducible in the sense that the original code always results in an access violation, and the adjusted code never does, with exactly the same A2L file in both cases.

My feeling is that the compiler somehow generates different (optimized?) machine code in both cases explaining the different behavior, but I cannot prove this assumption.

Would you or one of your colleagues be able to reproduce this behavior with an installation of ControlDesk?

Regards

Christophe

[RainerZ]

Hi Christophe,

sorry, I have overseen one detail in your code, which indeed changes the behaviour compared to the original code:

uint8_t addr = OdtEntryAddr(e);

XCP addresses are 32 bit values. You casted to 8 bit. Normally, you should have got a compiler warning from this. As a result, the access violation disapears, but it will measure garbage read from a wrong address. Note that XCPlite constructs pointers from A2L addresses by adding the module load address to the A2L address.

So I still guess, there is a problem with wrong addresses in your A2L.

Please make sure that controldesk really uses the address from the A2L file. Try to reduce your measurement setup to a single signal that fails. Increase the debug output level to see what happens. In higher levels, the DAQ lists are dumped.

Regards

[XTOCON]

Hi Rainer,

Thank you for your clear explanation. Unfortunately I was not able to figure out more about this issue.

The good thing is I have code now that works so the issue is no longer blocking but it would be interesting to know from other ControlDesk users if they're facing the same problem.

If you would know any other users that are open to discuss about this issue please let me know.

Regards

Christophe