8-ch audio card USB Bus Problems

XCore Project reviews, ideas, videos and proposals.
User avatar
mon2
XCore Legend
Posts: 1066
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Re: 8-ch audio card USB Bus Problems

Postby mon2 » Tue Apr 03, 2018 1:20 pm

Do check with XMOS to see if we are on the right track but many are reporting similar issues. Here is a thread directly based on the XMOS device and Linux - perhaps stale now but confirm with factory...

https://www.spinics.net/linux/fedora/al ... 13726.html

Check on Windows to see if the results are the same or different.
hamtam
Member++
Posts: 26
Joined: Wed Jun 28, 2017 7:37 am

Postby hamtam » Tue Apr 03, 2018 1:31 pm

I uploaded the current schematic. On Page 2 you can see that I connected VBUS with 3.3V.
hamtam
Member++
Posts: 26
Joined: Wed Jun 28, 2017 7:37 am

Postby hamtam » Tue Apr 03, 2018 2:51 pm

I found somethin in chapter 13 of the Data sheet about VDD. Maybe here is the problem? Currently it is powered with 3,3V.
User avatar
mon2
XCore Legend
Posts: 1066
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Tue Apr 03, 2018 5:34 pm

No. You are ok there as VDDIOT can be 3v3 or 2v5, varying with the devices you wish to interface with. For example, some Ethernet PHY devices demand the use of 2v5 swings while other logic require 3v3.


Image


Image

Suggest for you:

1) test on Windows - is it stable?

2) to load up the XMOS IP to test the USB widgets @ High speed.

Is your IP custom or the same as supplied by XMOS? Which IP are you loading up with your custom board?
hamtam
Member++
Posts: 26
Joined: Wed Jun 28, 2017 7:37 am

Postby hamtam » Wed Apr 04, 2018 12:57 pm

OK I removed the transformer and it made nothing better.
On the picture you can see how tiny the transformer is.
PCB without transformer

We try it now with an external consultant, I am verry keen to know how the problem will be solved. I will post it as soon as I now more.
Last edited by hamtam on Fri Apr 06, 2018 2:10 pm, edited 1 time in total.
hamtam
Member++
Posts: 26
Joined: Wed Jun 28, 2017 7:37 am

Postby hamtam » Fri Apr 06, 2018 10:43 am

We checked the current board with the HID IP. The device enumerates as an HighSpeed deviece and runs without problems.
So we doble checked the card with the XMOS Audio IP "USB Audio 2.0 Device Software" and got the failures again.

We tested with 8i8o:

Code: Select all

[92434.187597] usb 3-1.1.3: new high-speed USB device number 36 using xhci_hcd [92434.288135] usb 3-1.1.3: New USB device found, idVendor=20b1, idProduct=0008 [92434.288136] usb 3-1.1.3: New USB device strings: Mfr=1, Product=3, SerialNumber=0 [92434.288137] usb 3-1.1.3: Product: xCORE USB Audio 2.0 [92434.288138] usb 3-1.1.3: Manufacturer: XMOS [92439.966978] usb 3-1.1.3: 1:1: cannot set freq 96000 (v2): err -110 [92439.967051] usb 3-1.1.3: parse_audio_format_rates_v2(): unable to find clock source (clock -71)
[92439.967926] usb 3-1.1.3: parse_audio_format_rates_v2(): unable to find clock source (clock -71)
[92439.976483] usb 3-1.1.3: parse_audio_format_rates_v2(): unable to find clock source (clock -71)
[92439.977899] usb 3-1.1.3: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4
[92439.977901] usb 3-1.1.3: 10:0: cannot get min/max values for control 2 (id 10)
[92439.978138] usb 3-1.1.3: cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4
[92439.978140] usb 3-1.1.3: 10:0: cannot get min/max values for control 2 (id 10)
[92439.978380] usb 3-1.1.3: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xb00, type = 4
[92439.978381] usb 3-1.1.3: 11:0: cannot get min/max values for control 2 (id 11)
[92439.978460] usb 3-1.1.3: cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xb00, type = 4
[92439.978461] usb 3-1.1.3: 11:0: cannot get min/max values for control 2 (id 11)
[92439.980175] usbhid 3-1.1.3:1.4: can't add hid device: -71
[92439.980180] usbhid: probe of 3-1.1.3:1.4 failed with error -71 [92440.004631] usb 3-1.1.3: cannot get ctl value: req = 0x81, wValue = 0x101, wIndex = 0xb00, type = 1 [92440.004708] usb 3-1.1.3: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0xb00, type = 1
[92440.004787] usb 3-1.1.3: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xb00, type = 4
[92440.004788] usb 3-1.1.3: 11:0: cannot get min/max values for control 2 (id 11)
[92440.004865] usb 3-1.1.3: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xb00, type = 4
[92440.004866] usb 3-1.1.3: 11:0: cannot get min/max values for control 2 (id 11)


When we test i2o2 the device enummerates only with full-speed.

Code: Select all

usb 3-1.1.3: USB disconnect, device number 14 [ 246.732113] usb 3-1.1.3: new full-speed USB device number 15 using xhci_hcd [ 246.833645] usb 3-1.1.3: New USB device found, idVendor=20b1, idProduct=0009 [ 246.833650] usb 3-1.1.3: New USB device strings: Mfr=1, Product=3, SerialNumber=0 [ 246.833653] usb 3-1.1.3: Product: xCORE USB Audio 2.0 [ 246.833656] usb 3-1.1.3: Manufacturer: XMOS [ 252.022593] usb 3-1.1.3: 1:1: cannot set freq 48000 to ep 0x1 [ 252.023802] usb 3-1.1.3: 2:1: cannot set freq 48000 to ep 0x81
[ 252.026241] usb 3-1.1.3: 10:0: cannot get min/max values for control 2 (id 10)
[ 252.028531] usb 3-1.1.3: 11:0: cannot get min/max values for control 2 (id 11)
[ 252.056869] usb 3-1.1.3: 2:1: usb_set_interface failed (-32)
...
[ 252.071776] usb 3-1.1.3: 2:1: usb_set_interface failed (-32)
[ 252.072255] xhci_hcd 0000:00:14.0: URB transfer length is wrong, xHC issue? req. len = 0, act. len = 4294967288


We got the advice from mon2 and an experienced PCB designer, that the length of the leads mismatches a lot. Thus we created some sepentines on the USB bus lines. The mismatch between the lines of one pair must not be grater than 0,12 mm.

Image
We gave the new date to our PCB shop. We will see within the next 2 weeks if the new design works.
What we did also is to ensure with the PCB manufacturer the USB bus impedance. The PCB manufacturer tune the width and spacing if necessary to get 90 Ohms.
User avatar
mon2
XCore Legend
Posts: 1066
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Fri Apr 06, 2018 1:12 pm

Thanks for your update. The trace modifications are recommended and the testing of the USB CDC IP is an excellent way to test your design.

On the Linux errors, please review this thread:

viewtopic.php?f=8&t=1719

Would you please test on Windows and report your results?

From Ross (XMOS):
My understanding is that the (Linux) driver is not complete, it doesn't have all the units implemented from the USB Audio spec, however, if you disable MIXER (or at least set MAX_MIX_COUNT to 0) I believe it operates.
hamtam
Member++
Posts: 26
Joined: Wed Jun 28, 2017 7:37 am

Postby hamtam » Fri Apr 06, 2018 1:43 pm

I am not sure if it is related to our problem the post starts in 2012 and had the last message in 2014. As we did not have any problem like these with the XMOS reference board. The mixer is working fine also.

Windows also complains. It can not start the device.
Here I found a card wich runs if the moon and the stars have the right constellation:

alsamixer

I think it is really an issue with the USB signal quality.
hamtam
Member++
Posts: 26
Joined: Wed Jun 28, 2017 7:37 am

Postby hamtam » Mon May 07, 2018 2:37 pm

We have the HW revision 1.52 now. It still had the problems from the former hardware until we dived deeper into the Firmware.

After we increased the AUDIO_PLL_LOCK_DELAY to 40000000 which is about 400 ms the most of the devices are running without problems. But still there are some devices which does not. This devices do have either the wrong frequency or no signal on the XCORE_MCLK line. We currently investigate this problem.

It seems that we might not have had a big problem with the Hardware...
  • One of the FW problems is, that we did not wait until the PLL is locked. Only after the PLL is locked should synchronize the Audio Clock on the USB Bus.
Jowls
Newbie
Posts: 1
Joined: Thu May 17, 2018 5:03 pm

Postby Jowls » Thu May 17, 2018 5:12 pm

I'd be very interested in any updates, hamtam. We currently have the same issue (dmesg output shows the card is connected, but then many lines of errors after a few seconds, the first error being "parse_audio_format_rates_v2(): unable to find clock source (clock -71)"). I was encouraged when I saw you had success with AUDIO_PLL_LOCK_DELAY, but when I went to increase it, it was already at 40000000. Doubling it had no effect.

Who is online

Users browsing this forum: No registered users and 4 guests