Long response/recovery of YAT when running HID device concurrently

[Anonymous]

I am a long timer user of Yat and first I want to thank you for maintaining this excellent useful terminal!

My main usage of Yat is to handle communication between custom HID device and the PC.
I am using a Binary terminal type with Preset of: TI HID API.
From time to time I get stuck in condition were the opening of the Terminal Setting or any other GUI feature of the terminal get stuck for about 1 minute or more, and then recovers. When this condition happens, closing and opening of the Yat wont help, only reset of the PC will get me to normal behavior.
(see attached image)

In my dayly work I use to hibernet the PC, leaving the Yat application open, but disconnect it first from the HID device.

Any advice?

[Maettu]

Hi,

What version of YAT is being used? The latest 2.4.1 or 2.4.0 or older? With 2.4.0 there were quite a few performance and deadlock related improvements.

Are there serial COM ports in addition to the HID devices?

The combination of hibernating while USB devices are connected/open does in some cases cause issues. Also note this limitation (copy-pasted from the release notes):

   > Use of serial COM ports on disconnect, undock or hibernate without closing the port may result
     in the port no longer being usable. It happens due to a bug in the .NET 'SerialPort' class for
     which Microsoft only has vague plans fixing. To prevent the issue, refrain from disconnecting a
     device or undocking or hibernating while a port is open. In case the issue occurs, exiting YAT
     should be sufficient to force the .NET Runtime to terminate the buggy piece of code. If not,
     disconnecting the device or rebooting the computer should fix the issue.

Appart from that, I am not aware of an HID specific deadlock or similar issue, so additional information would be appreciated. If you are familiar with software development in C# .NET and Visual Studio, you could even follow debugging an issue in YAT source code using Visual Studio and try to nail down the issue.

You may either reply here or send an email via the SourceForge mail feature (if you have a SourceForge account) or send an email to the address shown in YAT's [Help > About...] dialog.

Best regards,
Matthias

[Anonymous]

Thank you for the fast response,

I'll remember your comment and close the Yat before hibernation.
Yet, I just got the problem again without hibernating the PC, just by consecutive series of running my HID device while recompiling my code on the device.
For 5 times there were no problems, and suddenly I got an issue of Long recovering of other PC program that uses serial HID communication with the same device I am working on (it is possible to connect to a single HID device from several PC programs in parallel!).
When I got this issue with the other PC programs, I realized that the Yat got stuck to this problematic condition again.
The one thing I know about the other program (made by a customer of mine) is it is based on .NET framework, just like the Yat.
I spent the last hour to find out a way to restart the ".NET framework" service without rebooting
the computer and find out that it is not possible.

Answers to your questions:
1) I am using the latest Yat version (aka 2.4.1)
2) There is another STLink virtual COM port, which I don't use during my work.

Unfortunately I am not familiar with software development in C# .NET and Visual Studio
(I am RT embedded person) so I can not debug this issue myself

Thanks,
Yosi.

[Maettu]

Hi Yosi,

Now this is interesting, the issue appearing when multiple apps are using the same device. Because I face the same issue with YAT's test board. The board has two TI LaunchPads connected, but I don't manage to use them stable concurrently.

Also, there are other limitations of the Windows HID infrastructure, see bug #169.

With FR#119 I may one day try to use libusb instead of HID.dll directly. This might solve some of these limitations. However, it is not a high prio task, I currently focus on finalizing YAT scripting.

In the meantime, if the issue happens again, you may try to disconnect/reconnect the device, more convenient than rebooting.

Best regards,
Matthias