AN00124 virtual COM not working. AN00184 virtual COM works fine

[vicacid]

Hi dear forum members,
I have a strange problem regarding the use of a virtual COM port. Environment used is the xCORE200 Multichannel Audio Board together with xTIMEcomposer 14.4.1 on Linux Mint.
lib_usb is 3.1.2, lib_xassert 3.0.0, lib_gpio 1.1.0, lib_logging 2.1.0.

When I import AN00124 everything compiles fine, when running the code, launching gives no errors but the boards seems to be identified as a mutlichannel audio interface (PID 0008), of which the corresponding code is stored in the flash.
The output of dmesg is then:
[Fr Jun 30 09:12:50 2023] usb 1-12.2: new high-speed USB device number 45 using xhci_hcd
[Fr Jun 30 09:12:50 2023] usb 1-12.2: New USB device found, idVendor=20b1, idProduct=0008, bcdDevice= 6.f2
[Fr Jun 30 09:12:50 2023] usb 1-12.2: New USB device strings: Mfr=1, Product=3, SerialNumber=0
[Fr Jun 30 09:12:50 2023] usb 1-12.2: Product: xCORE USB Audio 2.0
[Fr Jun 30 09:12:50 2023] usb 1-12.2: Manufacturer: XMOS
[Fr Jun 30 09:12:50 2023] usb 1-12.2: 1:1: cannot set freq 192000 (v2/v3): err -71

Of course the clock can not be set to 192 kHz since there is no audio functionality in AN00124.

I tried it several times now, the behaviour is most of the time the same, but sometimes the response can also be:
[Fr Jun 30 09:31:27 2023] usb 1-12.2: new high-speed USB device number 57 using xhci_hcd
[Fr Jun 30 09:31:27 2023] usb 1-12.2: Device not responding to setup address.
[Fr Jun 30 09:31:28 2023] usb 1-12.2: Device not responding to setup address.
[Fr Jun 30 09:31:28 2023] usb 1-12.2: device not accepting address 57, error -71



Then I tried AN00184, which is just an extension of AN00124 with an I2C interface. There everything works consistently fine and dmesg gives:
[Fr Jun 30 09:26:16 2023] usb 1-12.2: new high-speed USB device number 53 using xhci_hcd
[Fr Jun 30 09:26:16 2023] usb 1-12.2: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11
[Fr Jun 30 09:26:16 2023] usb 1-12.2: New USB device found, idVendor=20b1, idProduct=0401, bcdDevice= 1.00
[Fr Jun 30 09:26:16 2023] usb 1-12.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Fr Jun 30 09:26:16 2023] usb 1-12.2: Product: CDC Virtual COM Port
[Fr Jun 30 09:26:16 2023] usb 1-12.2: Manufacturer: XMOS
[Fr Jun 30 09:26:16 2023] usb 1-12.2: SerialNumber: 0123456789Config
[Fr Jun 30 09:26:16 2023] cdc_acm 1-12.2:1.0: ttyACM0: USB ACM device


Smart as I thought to be :-) I then took the COM functionality of AN00124 (character loopback), inserted it into AN00184 and commented out the "app_virtual_com_extended" parts, since I don't need I2C. Unfortunately dmesg then gives again:
[Fr Jun 30 09:21:26 2023] usb 1-12.2: New USB device found, idVendor=20b1, idProduct=0008, bcdDevice= 6.f2
[Fr Jun 30 09:21:26 2023] usb 1-12.2: New USB device strings: Mfr=1, Product=3, SerialNumber=0
[Fr Jun 30 09:21:26 2023] usb 1-12.2: Product: xCORE USB Audio 2.0
[Fr Jun 30 09:21:26 2023] usb 1-12.2: Manufacturer: XMOS
[Fr Jun 30 09:21:26 2023] usb 1-12.2: 1:1: cannot set freq 192000 (v2/v3): err -71


So, the code for the virtual COM port can not really be wrong. But that it is only working correctly when the COM application code fulfills some unknown properties is quite unsatisfying. Or maybe there is a problem in the startup of the code or USB functionality?
I have no idea what I could change now to get the COM port working without I2C and will be happy about any ideas and help.

Thanks and best regards
- vicacid

[Ross]

I would erase the flash using

Code: Select all

xflash --erase-all

I would also use the latest code: https://github.com/xmos/lib_xud/tree/de ... VCOM_class

[vicacid]

Hi Ross,
thanks for your quick answer.

I used the latest code from github with the newest XTC toolchain 15.2.1 and after some tries was able to compile the AN00124 example using xmake. Then I ran the binary using xrun and got the following message from dmesg:
[Di Jul 4 10:50:57 2023] usb 1-12.4.2: USB disconnect, device number 22
[Di Jul 4 10:50:57 2023] usb 1-12.4.2: new high-speed USB device number 23 using xhci_hcd
[Di Jul 4 10:50:57 2023] usb 1-12.4.2: Device not responding to setup address.
[Di Jul 4 10:50:57 2023] usb 1-12.4.2: Device not responding to setup address.
[Di Jul 4 10:50:57 2023] usb 1-12.4.2: device not accepting address 23, error -71

or sometimes:
[Di Jul 4 11:00:15 2023] usb 1-12.4.2: new full-speed USB device number 27 using xhci_hcd
[Di Jul 4 11:00:15 2023] usb 1-12.4.2: device descriptor read/64, error -32
[Di Jul 4 11:00:15 2023] usb 1-12.4.2: device descriptor read/64, error -32


I also flashed the .xe file and power-cycled the board with the same effect. I then erased the flash and ran the code again. Again with the some output of dmesg.

A short explanation why I still used the old tools. There are two reasons, the first one is, that they are still much more comfortable for me than the new ones. The second reason is, that we want to integrate COM port functionality into an existing project, which is based on sw_usb_audio and implemented using the old tools and libraries like lib_usb instead of lib_xud.
In the existing project, we included the COM functionality already as far as we could, but it is not showing up under windows (7 or 10), that's why we tried AN00124 and AN00184 and used Linux to get some more insights with dmesg. Remarkably, in our project the COM port shows up in dmesg under Linux, but not under Windows. So maybe there is (also) a driver problem?

Thanks and best regards,
- vicacid

[vicacid]

Hi Ross,
after a Thesycon driver update, the COM port in our project now works fine.

Since the driver is for USB Audio, it does not help regarding AN00124. But looking at the AN was only a step in understanding why our project did not work correctly, we do not need it as it is.

So the problem is solved for us.

Thanks and best regards
- vicacid

[Ross]

Glad your problem is solved, what was the driver update?

[vicacid]

Hi Ross,
we use an evaluation driver from Thesycon. The evaluation period was just over when we tried the addition of the COM port to our project, but we didn't realize that... :-) Additionally, in my mind the driver was just connected to audio, not to the operation of a virtual COM port.

Then we tried AN00124 to have a bare COM project as a reference and it also did not work. Confusingly AN00184 works fine and in lack of further ideas I wrote to the forum.

Now we have a new evaluation driver from Thesycon and our project works fine. Thanks to Thesycon for that, very good support!

Thanks and best regards
- vicacid

[Ross]

Thanks for explaining! Good luck with the project!