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
USB audio "on-demand"
-
- Member
- Posts: 14
- Joined: Mon Feb 25, 2019 3:05 pm
-
- XCore Addict
- Posts: 234
- Joined: Mon Jan 08, 2018 4:14 pm
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
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
-
Verified
- XCore Legend
- Posts: 1152
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
How do you plan to control when the USB Audio "is required"?
Does the device need to do something else in the other mode?
Does the device need to do something else in the other mode?
Technical Director @ XMOS. Opinions expressed are my own
-
- Member
- Posts: 14
- Joined: Mon Feb 25, 2019 3:05 pm
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.
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.
-
Verified
- XCore Legend
- Posts: 1152
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
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.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.
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();
Code: Select all
void XUD_HAL_EnterMode_PeripheralFullSpeed();
Technical Director @ XMOS. Opinions expressed are my own
-
Verified
- XCore Legend
- Posts: 1152
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
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... ;)
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... ;)
Technical Director @ XMOS. Opinions expressed are my own
-
- Member
- Posts: 14
- Joined: Mon Feb 25, 2019 3:05 pm
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:
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...
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
)
^
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...
-
Verified
- XCore Legend
- Posts: 1152
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
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.
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.
Technical Director @ XMOS. Opinions expressed are my own