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
USB Audio self-powered not detecting cable removal/insert
-
- Active Member
- Posts: 40
- Joined: Mon Dec 30, 2013 7:29 am
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
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.
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.
-
- Active Member
- Posts: 40
- Joined: Mon Dec 30, 2013 7:29 am
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
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
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
henk is the CTO of XMOS :)But I'm not sure how he knows that, as far as I can tell there's no source code available for XUD_Manager....
https://www.linkedin.com/in/henkmuller
-
- Active Member
- Posts: 40
- Joined: Mon Dec 30, 2013 7:29 am
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!!
Well, maybe he'll weigh in here, I hope!!
-
- Active Member
- Posts: 40
- Joined: Mon Dec 30, 2013 7:29 am
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?
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?
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
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)
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.
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)
Then others can review if the VBUS port pin activity is being read by the firmware.please run xrun --dumpsate youapplication.xe and post the results.
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.
-
- Active Member
- Posts: 40
- Joined: Mon Dec 30, 2013 7:29 am
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
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
You do not have the required permissions to view the files attached to this post.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
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.
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.
-
- Active Member
- Posts: 40
- Joined: Mon Dec 30, 2013 7:29 am
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.
0.1uF on VBUS to GND
2.2uF on VBUS to GND
no cap to GND
Second board is on the way to try next week. Meanwhile I'll dig up my SliceKit.
0.1uF on VBUS to GND
2.2uF on VBUS to GND
no cap to GND
You do not have the required permissions to view the files attached to this post.