internal driver error on wclClient.Write from thread

[cgklein]

Hello,
I'm using WCL Lite .NET 6.14.11 on Win7 x64, and get 'Internal driver error' when calling wclClient.Write() from a thread.

The write functionality is within a static class which is being called from a thread (only one).
It works if I insert delay eg 100ms between the calls, but with little or no delay it generates errors.
I read about using WCL in a threading app, and about message loop etc. Reading seems to work fine (application is full duplex).
Is this maybe some buffering issue?

on a side note: I'm actually developing embedded software, and on my ARM microcontroller (which shall receive the Bluetooth messages via a BT module) I can see messages coming in 2-3seconds after the thread (doing the writing on PC side) finished. So there is quite a delay, but i doubt it's caused by WCL, more likely by MS BT stack? Transmitters are close (less than 1 meter) so link should be good too. Do you have any figures what throughput can be reached, and what delay to expect (module is BT V2.x)?

[Mike Petrichenko]

Hello,

As I can understand write and read works in different threads. It is not good idea.

WCL does not use any buffers on write operation and writes passed data immediately and directly to Bluetooth driver.

With regards to WCL_E_INTERNAL: There are few reasons it can be:

1. Driver is busy
2. Buffer is too big.
3. Connection is not established.

In case of MS driver you can call WSAGetLastError immediately after calling wclClient.Write to get extended error information. if you do so and give me the result code of WSAGetLastError I can say what exactly went wrong there.

[cgklein]

yes, has to happen in different threads.
Reading happens on the GUIs thread by copying received data in the OnData event to a circular buffer from where the read thread gets the data. The write thread accesses the same client object which is admitedly not a good idea.
The previsous lib. was using a stream, and could handle that. But if i use a lock/mutex/... should be ok?

System.Runtime.InteropServices.Marshal.GetLastWin32Error() gives me 10035 which means "Resource temporarily unavailable" according to MSDN (https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668%28v=vs.85%29.aspx)

[Mike Petrichenko]

Ok, threads is the other question.

With regards to error code. You have to use WSAGetLastError, not Win32GetLastError (which is actualy simple GetLastError).

[cgklein]

ok, now I did
        [DllImport("ws2_32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        static extern Int32 WSAGetLastError();
and call WSAGetLastError(), and it gives me same error code 0x2733 or 10035d (according to SO should be the same...http://stackoverflow.com/questions/765491/how-to-get-last-error-wsagetlasterror)
hope this is correct error code.

[Mike Petrichenko]

Hello,

Thank you a lot. Yes, this is correct code and it means exactly I told. Following MS documentation it is not critical error means that the resource is busy by other operation. In your case it is probably busy by reading incomming data when you try to send outgoing data. So retry to send data solves the problem.

[cgklein]

thanks! tried waiting randomly between 50-150ms, but still get the error every couple seconds, or often. But at least I know what it means now...

regarding the performance...I know this most likely is not an WCL issue, but I'd appreciate any input on this.
I need to send a firmware file via bluetooth to a CAN node at the other end (bus is 500kbit/s) ~ 46080 packets each 17 bytes long. I know that's probably not very efficient, and I should send bigger chunks, but need to stick to the protocol as the 'bridge' (microcontroller) is dumb. Currently takes ~ 7minutes, and bridge shouldn't be the bottleneck.
Can BT stack/WCL handle small packets efficiently?

regards, KC

[Mike Petrichenko]

Try to change values of wclClient.Buffers.ReadBuffer and wclClient.Buffers.WriteBuffer. Those properties are internal (drivers) buffers size for read and write operations. There is no guarantee that the driver will use exactly this values but at least at gives some "idea" to the driver to optimize writing and reading internal procedures.