USB Audio self-powered not detecting cable removal/insert

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
User avatar
bowerymarc
Active Member
Posts: 40
Joined: Mon Dec 30, 2013 7:29 am
Contact:

USB Audio self-powered not detecting cable removal/insert

Post by bowerymarc »

Using USB Audio library 6.15.2rc1....

I have a self-powered USB audio device, SELF_POWERED=1, etc...

If I start the firmware with USB plugged into computer (OSX) already, then it recognizes the connection (calls UserHostActive(1)), will stream and everything works fine.

But if I then unplug the USB cable, I don't get a call from UserHostActive(), so the device seems to think it's still connected, though the computer removes it from the list of USB audio devices, etc.

If I re-plug the cable, nothing happens. Computer doesn't recognize (using USB Prober to make sure).

If I run the firmware with cable unplugged, then plug it in, same thing. No UserHostActive(1) and no recognition.

Am I doing something wrong or is this how XUD_Manager works?

I do have VBUS connected to the USB's VBUS, with a 10KΩ pulldown, and the 'scope shows me that is going up to 5V when plugged in and down to 0V when unplugged.

Best,
Marc


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Which CPU ? Custom PCB ? If possible, post relevant details of your schematic.

Be sure you have wired up your VBUS as shown in Figure 15 of this datasheet:

http://www.xmos.com/download/private/XE ... .12%29.pdf

otherwise the VBUS pin may face inductive surge current damage. In our opinion, a better solution is to insert a low cost USB load switch into the design to prevent this and other related faults. For example, review the AP2822AK which is one of many such suitable parts.

https://www.diodes.com/assets/Datasheets/AP2822.pdf


Possibly the same issue posted here:

http://www.xcore.com/viewtopic.php?f=7&t=5589

please run xrun --dumpsate youapplication.xe and post the results.
User avatar
bowerymarc
Active Member
Posts: 40
Joined: Mon Dec 30, 2013 7:29 am
Contact:

Post by bowerymarc »

Hi Mon2,

forgive me, but I think you're wandering OT here. My question is specifically regarding how the firmware, in particular XUD_Manager handles VBUS. Assume VBUS is connected to the XS1_SU1_96 correctly, as I have stated in my OP. The link you sent has one reference to this where 'henk' asserts that VBUS needs to be up (5V) before the firmware starts up. But I'm not sure how he knows that, as far as I can tell there's no source code available for XUD_Manager....

If you re-read the scenarios in my OP, my question is how XUD_Manager handles those, specifically transitions of VBUS once the firmware is running.

thanks,
Marc
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

But I'm not sure how he knows that, as far as I can tell there's no source code available for XUD_Manager....
henk is the CTO of XMOS :)

https://www.linkedin.com/in/henkmuller
User avatar
bowerymarc
Active Member
Posts: 40
Joined: Mon Dec 30, 2013 7:29 am
Contact:

Post by bowerymarc »

So, mon2, it seems you're implying he's using his powerful position to access that code? I can't believe it! The scandal! :)

Well, maybe he'll weigh in here, I hope!!
User avatar
bowerymarc
Active Member
Posts: 40
Joined: Mon Dec 30, 2013 7:29 am
Contact:

Post by bowerymarc »

more info: connected XMOS to linux, to run wireshark, and it looks like the XMOS is not doing anything in the situation where: (a) power up XMOS before plugging in to computer, (b) unplug and re-plug after (a), or (c) unplug and re-plug after powering up XMOS with USB plugged in. With XMOS powered up with USB plugged in, then linux recognizes the unit (just like OSX) and transacts with it.

So, it seems that, oddly, Mr. Muller, the CEO of XMOS knows exactly how XUD_Manager works :)

I guess my question is, is there some way to get it to work in these other scenarios?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

The point to my post was:

1) VBUS is used by the XUD firmware

2) What if...VBUS port pin is damaged ? Then you may see the results you are observing. Why damaged ? Due to in rush surge current via the VBUS port pin unless the revised schematic has been applied to your design before use.

3)
please run xrun --dumpsate youapplication.xe and post the results.
Then others can review if the VBUS port pin activity is being read by the firmware.

4) Alternatively, you could consider to test another PCB with a fresh CPU but only if you have the protected front end circuit shown in the revised datasheets.
User avatar
bowerymarc
Active Member
Posts: 40
Joined: Mon Dec 30, 2013 7:29 am
Contact:

Post by bowerymarc »

I don't have the same schematic for VUSB. Instead I have a protection device to protect against over/undervoltage (p/n ECMF02-4CMX8) which isn't shown on that schematic. I'm going to try 'scoping it as well to see what the deal is in my test setup. In any case since I'm not getting any response about how VUSB should behave, I'll try to go back to my SLICE kit and see how it behaves.

In the meantime I'm attaching the output from:

xrun --dump-state --verbose app_usb_aud_skc_su1_wadda_2ioxs.xe

(which I had to turn off SIP in Sierra to run properly!)

For 5 different scenarios. Not sure what this will reveal, I'll be interested.

M
Attachments
dumpState output.zip
(17.23 KiB) Downloaded 749 times
dumpState output.zip
(17.23 KiB) Downloaded 749 times
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Marc,

1) do you have another one of your custom boards to test ? Do you see the same results with a fresh board ?

2) Can you reflash your PCB to use one of the other XMOS USB IP examples like the USB HID and/or USB CDC, etc ? How does another USB based IP behave with your custom PCB ? Not an audio developer so no direct knowledge of the audio IP but we have in house USB bus analyzers which we can use to debug if required.

Curious to hear about your results for the USB CDC example which we recall testing and worked fine.

https://www.xmos.com/support/appnotes/AN00124

Are you able to dock / remove / dock this USB serial widget example and your hardware ?

While testing the above IP, review this thread on IDs to deploy:

http://www.xcore.com/viewtopic.php?t=3191

The ST ESD EMI filter and transient protection device is better than not having one but does not prevent surge currents. The VBUS line should feature a soft start to limit in rush currents and fearing that could be an issue with the board you have under test. Once that pin pops, the VBUS pin will not function as it should.
User avatar
bowerymarc
Active Member
Posts: 40
Joined: Mon Dec 30, 2013 7:29 am
Contact:

Post by bowerymarc »

I may well have blown USB_VBUS. I had a 0.1uF cap to ground, and the voltage peaks at 6.2V. 2.2uF makes it worse. No cap is actually the best.
Second board is on the way to try next week. Meanwhile I'll dig up my SliceKit.
VBUS 0.1uF.JPG
(456.09 KiB) Not downloaded yet
VBUS 0.1uF.JPG
(456.09 KiB) Not downloaded yet
0.1uF on VBUS to GND
VBUS 2.2uF.JPG
(454.42 KiB) Not downloaded yet
VBUS 2.2uF.JPG
(454.42 KiB) Not downloaded yet
2.2uF on VBUS to GND
VBUS 0uF.JPG
(429.81 KiB) Not downloaded yet
VBUS 0uF.JPG
(429.81 KiB) Not downloaded yet
no cap to GND
Post Reply