xCore-200 MC dev board own design - off/on switch - how to restart and re-enumerate USB audio?

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
Post Reply
Zed1970
Active Member
Posts: 55
Joined: Tue Oct 15, 2019 10:36 am

xCore-200 MC dev board own design - off/on switch - how to restart and re-enumerate USB audio?

Post by Zed1970 »

Hi,

Our product software is based on the app_usb_aud_xk_216_mc sample code (and xCore-200 MC dev board); our design also has a number of switches including an off / on switch and a USB mux/pass-though ( FSUSB63UMX ). The USB pass-though (FSUSB63UMX) enables the user to select USB xmos audio/spdif OR to use another USB item inserted into an auxiliary socket directly - pass-through. Problem is when the source switch selects the auxiliary device switching back to xmos audio it doesn't come back up as a sound card any more. Somehow I need to restart the xmos enumeration so as to appear once again as an external USB sound card. Is this possible? Same applies for the off/on switch.

Basic flow:
1) Power on in audio mode
2) Enumerates and appears as a USB audio card
3) Switch over to auxiliary USB input
4) Whatever the device is enumerates and is usable i.e mouse
5) Switch back to audio mode, never appears again as a USB sound card <= when switched back I need to restart the USB audio side somehow...

Thanks.


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

Post by mon2 »

Hi. If you force a RESET on the XMOS CPU, the new USB function is properly enumerated? Assuming this is the case.

Which component in your design steers the USB MUX?

Consider to force the #RESET line on your XMOS CPU to be LOW when the USB MUX is steered to the alternate USB device. This will allow the alternate USB device to function but will park the XMOS CPU under reset condition.

When you steer the USB MUX back to the XMOS CPU, the #RESET line will be released and respectively force a reset for the enumeration again.

Thinking that a single gate open-drain buffer (TI p/n SN74LVC1G07 or any equivalent) could do all of the above. Just wire up the USB mux so that if SEL = HIGH, the XMOS USB lines are mapped to the outside world through the MUX. Input of this buffer = SEL pin. Output of this buffer to #RESET pin on the XMOS CPU.

Test this idea first by steering the MUX away and then back to the XMOS CPU. Once you have done this, GROUND the #RESET pin on your XMOS CPU carefully with a small piece of wire. After you release this GROUND (LOW) state, does the IP work? If yes, above idea will also work.

If you wish to keep BOTH or more USB widgets always active then consider to insert a USB 2.0 HIGH SPEED HUB (Microchip is stable on features and quality).
Zed1970
Active Member
Posts: 55
Joined: Tue Oct 15, 2019 10:36 am

Post by Zed1970 »

Hi mon2,

Thanks, reset idea may of worked but the switch to flip between aux usb and the xcore runs of a muxed bank of switches under software control on the xcore, so a reset would majorly upset things. Is there a point in the usb code where I could slip in a software reset just for the audio core?

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

Post by mon2 »

Hi. Not an audio developer so do not claim to know the low level details of the audio IP as I should but..

a) assuming that your flash issues are resolved? - did receive an email from XMOS on your case and that a resolution was in the works between you two.

b) moving forward, you could consider to write the value of your switch configuration into a free location inside your external flash. Upon each power up / reset cycle -> read back this value to configure your external hardware. Then proceed to use the single gate solution on the #RESET pin (after manual testing of the idea). Now, if the CPU is reset, no loss of the switches due to the external flash holding this non-volatile value. Any time you change the switch settings via the XMOS CPU, write back the switch value to the external flash.

Here is an appnote on the use of the external flash for data storage:

Code: Select all

https://www.xmos.com/file/an00188-using-quadspi-flash-memory-for-persistent-storage-with-xcore-200

Otherwise, not sure at this time on how you can reset the USB IP (only) without losing your XMOS GPIO settings used by your external hardware.

Essentially the use of the single gate suggestion is a quick work around that should be feasible to deploy. Again, do test first with a manual piece of wire to ground once your XMOS is in the "lost" state. Assuming that the XMOS USB IP is not detecting the MUX stealing away the D+ / D- lines. The USB IP works before the MUX is steered away from the XMOS CPU but does not see the need to restart the code run once the MUX is restored.
Zed1970
Active Member
Posts: 55
Joined: Tue Oct 15, 2019 10:36 am

Post by Zed1970 »

Just to add some extra information, if the board is just ran up with the app_usb_aud_xk_216_mc code it produces a USB sound card as it should. However if the USB - signal wise - cable is unplugged and reinserted from then on it fails to come back as a sound card, is this normal? On Linux it does appear to re-enumerate teh second time+ but ALSA never sees it again as a usable sound card.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Due to your severe time crunch (in order) suggest:

a) contact XMOS on the issue to see if they have a quick fix - kind of recall this issue but not sure if the resolution is through software

b) generally speaking, the VBUS line should be monitored for the USB cable plug / unplug. Is your widget powered by the USB port or SELF POWERED? Is the IP flag configured correctly in the IP?

c) test the XMOS USB IP for the HID MOUSE - does that work correctly every time?

Do post your results / feedback.

Will try to investigate - time permitting between open projects :)
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Your issue may be related to the following:

https://www.xcore.com/viewtopic.php?t=5808

On your custom PCB, is the PCB powered from the USB connector or do you have a local power supply?

Does your custom design feature in-rush current protection between Vbus pin on the USB connector and the XMOS CPU? (if Vbus is even connected on your design)

From past readings from other developers, the issue could be a latch up of the XMOS CPU or possible XMOS CPU damage due to inductive kick back through the USB cable. The above thread documents the strength of the voltage spikes that are present which are well beyond the recommended values of the silicon.

Diodes Inc. has some great USB load switch devices which offer many features including in-rush protection to prevent such possible damage. If you can, post the partial schematic of the USB connection to the XMOS CPU for a quick review.

What are the results if you attempt to run the same IP on the XMOS MC Audio devkit?
Zed1970
Active Member
Posts: 55
Joined: Tue Oct 15, 2019 10:36 am

Post by Zed1970 »

Thanks, I'll check these points out.
Post Reply