PEAK-System Forum

Hello,

After connecting (successfully) to an ECU, dynamically allocating one dto-entry in one dto in one daq-list and calling XCP_StartStopDAQList, I call XCP_DequeuePacket and get XCP_ERR_INSUFFICIENT_BUFFER as result.

The call of XCP_DequeuePacket looks like that: I guess the initial mistake can't be found inside that code snippet, but even though:
Do you have any ideas why this error can occur?

If that helps, here is the whole Code: http://pastebin.com/dcpUznkj. The functions get called in the order they occur in the snippet and every XCP function returns XCP_ERR_OK except XCP_DequeuePacket.

Thanks in advance!

Hello lslahrs_,

this is actually very weird. Are you sure about the error code (0x800)? Apart of the ERR_OK, the function XCP_DequeuePacket returns only one of these possible errors:

• XCP_ERR_INVALID_HANDLE: The given handle is wrong
• XCP_ERR_INVALID_PARAMETER: Length is smaller than MAX_DTO/CTO (8 bytes), or the buffer passed is empty.
• XCP_ERR_QUEUE_EMPTY: There is no packet in the DTO/CTO queue to be read.

Since you say that the other functions work properly, and I see that in your code you are defining a buffer with 8 bytes in length, the only error that could be returned should be QUEUE_EMPTY.

Hello Keneth,

Thanks for your reply!
I double rechecked the return code of XCP_DequeuePacket and it really gives me 0x800.
When would the XCP_ERR_INSUFFICIENT_BUFFER error normally occur?

Thanks for your help!

Hello,

All functions with exception of XCP_DequeuePacket and XCP_ResetQueue use XCP_ERR_INSUFFICIENT_BUFFER.

It is returned when the buffer passed to the function is smaller than MAX_CTO. Those functions using number of elements instead of bytes (XCP_Upload, XCP_ShortUpload, XCP_Download, XCP_DownloadNex, XCP_Program, XCP_ProgramNext) return this error when the buffer is smaller than [MAX_CTO * packages count].

There is no path with Within XCP_DequeuePacket that returns XCP_ERR_INSUFFICIENT_BUFFER.

Hello Keneth,

For some reason I used the wrong byte order - I set the TXCPProtocolLayerConfig::MotorolaFormat to true instead of false.
After fixing that XCP_DequeuePacket doesn't return 0x800 anymore but the program crashes due to a segmentation fault in the call of XCP_DequeuePacket.
I have no idea what I'm doing wrong.

Using XCP_SetMemoryTransferAddress and XCP_Upload I receive correct measurement data. So I guess the connection is set up correctly.

With PCANView I also checked that the ecu continuously sends packages to the master after starting the daq list using XCP_StartStopDAQList.

Do you have any ideas about what could be the problem?
Thanks again!

Best regards
Thomas

Hello Thomas,

is your app always crashing at the first time XCP_DequeuePacket is called, or the funciton works some times before crashing? It is kind of weird that just changing the byte format causes a crash...

In my opinion there are two possibilities:

1. Some allocation/deallocation actions in your app are causing a corruption in the stack.
2. There can be some multithreading issues within the XCP API, if you are accessing the API from more than a thread within your app...

If possible, please create a test app using the minimum amount of function calls needed to receive a DTO over XCP_DequeuePacket. This will help to discard and/or isolate the problem.

Hello Keneth,

I'm not really using threads. I am using the Qt-GUI-framework which produces some threads but all the xcp functions get called inside one thread. But I will write a minimalistic example without using Qt. Thanks for the tip!

In the last minutes it got even weirder. I temporarily switched to an older version of your library from 2011, just because I'm out of ideas. The call of XCP_DequeueDTO didn't crash but told me the queue is empty. I checked XCP_DequeueCTO without any reason and it returned XCP_ERR_OK and gave me a correct value from the ecu.
I thought that the daq lists would return DTOs not CTOs. Am I wrong?
I will check what happens if I call XCP_DequeuePacket with XCP_CTO_QUEUE as argument.

I'll upload a minimalistic test program soon.

Best regards
Thomas

Hello Thomas,

lslahrs_ wrote:I checked XCP_DequeueCTO without any reason and it returned XCP_ERR_OK and gave me a correct value from the ecu.

Hmmm, It is possible that the Beta version have had such a bug-behavior. I see no evidences in the current code for a queue mixing, but go ahead and try the same thing within the current release (1.0) so we can discard this problem.

lslahrs_ wrote:I thought that the daq lists would return DTOs not CTOs. Am I wrong?

No, you'r right: The CTO queue stores responses to commands issued in non blocking mode, or other kind of asynchronous CTOs as events, services, and errors reports. The DTO queue stores data acquisition messages generated by stimulation or by a running DAQ list.

Hello Keneth,

here is my "minimalistic" example: http://pastebin.com/1R4YHdep
Unfortunately it's not really short and looks ugly with all those magic numbers flying around.
But now I used pure C++ without the qt library and the code doesn't produce any threads.

I just realised that this code does not always crash. Most times it crashes due to a segmentation fault while calling XCP_DequeuePacket, but sometimes I get again 0x800 as return value.

I have no idea, what's going wrong..

Best regards
Thomas

Hello Thomas,

thanks for the code. I will try to reproduce the error and check where the problem lies. It can take a little bit of time, since I will be out of office for the rest of this week.