USB audio "on-demand"

Discussions about USB Audio on XMOS devices
User avatar
notDilbert
Member
Posts: 14
Joined: Mon Feb 25, 2019 3:05 pm

USB audio "on-demand"

Post by notDilbert »

Hi,

I'm working with a circuit based on the xCORE-200 MC Audio reference design.

1. Is there a way in software to have the device not enumerate as a USB audio device by default and then when required enable the USB audio?

2. I have tested disconnecting / re-connecting the USB_VBUS detect pin going to the XE216 and this does what is required. This requires a hardware change that we would like to avoid if possible. see datasheet p21
https://www.xmos.com/download/XE216-512 ... (1_16).pdf

Kind regards


User avatar
fabriceo
Experienced Member
Posts: 125
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hi
The standard USB Audio application already includes such a type of dynamic configuration changes for DFU.

by default the application expose a composited device with audio and dfu interfaces. When the host sends a specific command to the dfu interface via endpoint 0, then xmos is rebooting, with a flag set in memory in a region not overwritten by the xmos libraries.
Thus the application detects this situation and provides another device descriptor exposing only the dfu interface and no more audio.

based on this you can certainly leverage some piece of code and realize your use case in software. just search DFU in main.xc and endpoint0.c to find about this process

hope this helps
User avatar
Ross
XCore Expert
Posts: 947
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

How do you plan to control when the USB Audio "is required"?

Does the device need to do something else in the other mode?
User avatar
notDilbert
Member
Posts: 14
Joined: Mon Feb 25, 2019 3:05 pm

Post by notDilbert »

Thanks for the replies.

fabriceo, I had a look at the libraries and managed two results.

1. Windows report "Device Descriptor Request Failed"
2. USB audio enumerates but audio samples in and out end up in the void

Ross, There is UART comunication between the XE216 and another MCU with a comunication protocol to control the XE216.

I'm planning on adding an enabled / disable USB audio command to the protocol.

When enabled just work as usual with Windows device manager listing the USB audio device and when disabled Windows device manager do not list the device.

The same as happens when the XE216-512-TQ128 pin 45 USB_VBUS is low and it does not know it is connected to a host and does not pull-up USB_DP (I assume) to let host know a periheral is connected.

So basically enable / disable USB audio device enumeration in software.

If there was a register in the XE216 to control pull-up of USB_DP that would be ideal.
User avatar
Ross
XCore Expert
Posts: 947
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

notDilbert wrote: Thu Oct 26, 2023 11:52 am If there was a register in the XE216 to control pull-up of USB_DP that would be ideal.
There is such a register. I'm not sure if this is the cleanest way of achieving the behaviour you want - the audio device will still be running but in suspend essentially - all the audio clocks will continue etc and power will be used to do nothing.

I think a good way might be to reboot into a usb audio or "do nothing" image using a very trivial custom boot loader.

As for the reg write you asked for, use these functions from XUD_HAL.xc in lib_xud

Disconnect:

Code: Select all

void XUD_HAL_EnterMode_TristateDrivers();
Re-connect:

Code: Select all

void XUD_HAL_EnterMode_PeripheralFullSpeed();
User avatar
Ross
XCore Expert
Posts: 947
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

On reflection, I do not think your approach will work.

If you set this register "behind the back" of lib_xud it will see VBUS is present and set it back again....

If you really want to follow your approach you could modify XUD_HAL_GetVBusState_() to only return proper VBUS values when your external micro has sent the connect command.
I think this is quite "hacky" though... ;)
User avatar
notDilbert
Member
Posts: 14
Joined: Mon Feb 25, 2019 3:05 pm

Post by notDilbert »

This device will spend 99.9% of it's working life as a DSP number cruncher with not USB audio involved and connected.

The USB audio is only used for internal testing and calibration so a hack will do.

Looks like lib_xud is a newer library and trying to make it play nice with xTIME Composer Studio (Community_14.4.1) on Windows 10 will require some work.

I tried to build sw_usb_audio-[sw]_7_3_1\app_usb_aud_xk_216_mc with this version of the IDE

with xmake CONFIG=1AMi2o2xxxxxx all

But no joy, receiving these errors:

Code: Select all

C:/Users/User/workspace/sw_usb_audio-[sw]_7_3_1/lib_xua/host_usb_mixer_control/usb_mixer.cpp:612:13: error: unknown type name 'char_style'
            char_style mixer_output_name[USB_MIXER_MAX_NAME_LEN];
            ^
C:/Users/User/workspace/sw_usb_audio-[sw]_7_3_1/lib_xua/host_usb_mixer_control/usb_mixer.cpp:698:5: error: expected expression
    )
    ^
C:/Users/User/workspace/sw_usb_audio-[sw]_7_3_1/lib_xua/host_usb_mixer_control/usb_mixer.cpp:700:9: error: use of undeclared identifier 'devh'
        devh = 0;
        ^
C:/Users/User/workspace/sw_usb_audio-[sw]_7_3_1/lib_xua/host_usb_mixer_control/usb_mixer.cpp:774:12: error: use of undeclared identifier 'devh'
        if(devh)
           ^
C:/Users/User/workspace/sw_usb_audio-[sw]_7_3_1/lib_xua/host_usb_mixer_control/usb_mixer.cpp:798:12: error: use of undeclared identifier 'devh'
    return devh ? 0 : -1;
           ^
C:/Users/User/workspace/sw_usb_audio-[sw]_7_3_1/lib_xua/host_usb_mixer_control/usb_mixer.cpp:820:9: error: expected expression
        ) 
        ^
Is it possible to use lib_xud with this version of the IDE and include it in my existing project based on sw_usb_audio-[sw]_6.15.2\app_usb_aud_xk_216_mc example?

Starting to think changing the hardware design and only connecting USB_VBUS to the XE216 when USB audio is required might be a better solution...
User avatar
Ross
XCore Expert
Posts: 947
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

It looks like, for some reason, the build is attempted to build the host control program into the device binary - you don't want anything on the host_usb_mixer_control folder in the device code build.

You should really use 15 tools, that's what it's been tested against. If you really want to use the IDE from 14 tools they are some threads on here about how to do that.