XferData function doesn't time out if device disconnected

[ThAl_4704151]

I'm trying to write an application to format the logs I have coming out of my FX3. Basically, every time a CyUSB device attaches, we create a new thread that repeatedly polls for new data and puts it in a queue that gets read on the main thread. These threads are each associated with a flag that indicates if the thread should terminate gracefully. This happens if a device is removed, for example. I use the deviceAttached and deviceRemoved events to handle devices adding or removing.

The situation I'm running into is that I receive a deviceRemoved event and request the thread to terminate gracefully using my flag. In the thread, even though the timeout on xferData is set to 1 second, the xferData function doesn't return, which means the thread doesn't read my flag, and thus doesn't terminate.

During normal operation, xferData terminates after a second like it should. It's just after the device is disconnected that it hangs. 

Am I doing something wrong, or is there a workaround for this?

I've attached the solution if you'd like to try it out. usbMgr.cs is where the interesting parts are. UsbPoll is the thread body. removeDevice is the function that's trying to join the thread. If you wanted to try this out, you don't actually need your FX3 to transmit anything as long as it's using the PID, VID, and endpoint that I'm expecting.

I'm running into other issues getting xferData to actually receive data, but that's probably going to be a different post.

[JayakrishnaT_76]

Hello,

Can you please refer to the following thread in which one of our community member has suggested an alternative solution for the same issue:

https://community.infineon.com/t5/USB-superspeed-peripherals/FX3-Net-XferData-call-never-exits-when-...

You can also refer to the C# source code of Streamer application that comes along with FX3 SDK. The application handles both device detach and attach events. Also, the application is not getting stuck after removing the device. This is because the same application works well when I reprogram the device again after detaching the device. The source code of C# streamer application can be found in the following location within FX3 SDK:

C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\application\c_sharp\streamer

You can use it as a reference to create your application.

[ThAl_4704151]

In both the streamer app and the other response, they solved the problem by killing the threads using the thread abort function. However, best practice is to avoid that because generally speaking it's better to allow the thread to finish its work first and then terminate when it's ready.

I might set it up to use the abort as a fallback in case I'm stuck in this situation. I'd prefer to do it more cleanly though.

EDIT: I've also just learned that microsoft marked thread.abort as obsolete in .net 5.

EDIT: EDIT: Also in both .Net 5 and any version of .Net core, it throws a PlatformNotSupportedException.

[Rashi_Vatsa]

Hello,

In case you do not want to use the reference code for killing the thread as done in the streamer app, you can refer to the recommended action section of this Breaking change: Thread.Abort is obsolete - .NET | Microsoft Docs post for an alternative to thread.abort

[ThAl_4704151]

I found that already. Neither of those solutions works in this case.

Their first solution is to use a cancellation token. The problem with that is that you have to check the status of the cancellation token, and the thread I want to cancel is stuck down in native code somewhere during the call to xferData, so I can't.

Their second solution is just to suppress the warning, but calling the function still produces a PlatformNotSupportedException at runtime on .Net 5 and .Net core, and does not kill the thread.

[AliAsgar]

Hi,

Could you let us know the endpoint number of the interrupt endpoint? Is it 0x8A?

Also let us know what should be done with FX3 kit after running the host application (FX3 logger) to reproduce the issue at our end. Should there be any transfers done from the Interrupt endpoints?

Best Regards,
AliAsgar

[ThAl_4704151 · Accepted solution]

All of them are interrupts. The 4 ports I use for real data are 0x2, 0x4, 0x86, and 0x88, and the debug one is 0x8A. The one that I'm locking up on is 0x8A. The others are read by a different app.

The 4 "real" endpoints don't really matter for this. I don't even think you really need anything coming through the debug endpoint to reproduce this, but even then it doesn't really matter what. If it doesn't recognize the pattern, it'll set a flag that marks the corresponding table entry as "corrupted", but it reads the data all the same.

What I've got right now as my workaround is that I rolled back to .net 4.8 framework so that I could use abort. Then I found that xferData locks up in native code somewhere in your library, and that prevents the interrupt that abort produces from killing the thread, so I stuck the call to your function in a task launched from that thread. The abort kills the thread, but ostensibly that task is still floating out there until the program terminates, which is a memory leak.