Hi everyone,
i´m a EE student from germany and i designed a smal Headphone Amp with XUF208 as a perequesite for a bigger project.
At first i really like the xmos devices and i managed to port this software to my design without a problem until it came to VBUS :-)
I designed my Board according to Figure 11 in the XUF208 Datasheet and tried to set SELF_POWERED to 0, but it wont enumerate without VBUS connected.
I understood that in the XHRA Design VBUS schould always connected to 5V, but i couldnt figure out what i do have to change in software to make it work without VBUS connected to 5V.
thanks in advance
Nils
Migrating from XHRA to XU208
-
- Newbie
- Posts: 1
- Joined: Sun May 19, 2019 3:25 pm
-
- Experienced Member
- Posts: 75
- Joined: Fri Apr 15, 2016 6:46 pm
I realize the stated upper limit sample rate for this solution is 384kHz, but would it be possible to implement changes in the code to extend this to 768kHz?
-
- Junior Member
- Posts: 4
- Joined: Sun Jan 08, 2017 5:03 am
Hi All,
I’ve been working on an audio application using an XU208-128-TQ64, based on the XHRA to XU208 project, and I have most of the functionality I want working well. The last part is HID inputs, and that’s got me stumped right now. I have buttons attached to the following inputs, and want to allocate them to the following HID functions:
Based on the examples I could fine I wrote the following hidbuttons.xc:
#include <xs1.h>
#include <platform.h>
#include "devicedefines.h"
#ifdef HID_CONTROLS
/* Sets which port is used */
in port p_sw = on tile[0] : XS1_PORT_8C;
/* Sets which bits of port 8C correspond to each input */
/* Button A: X0D29, 8C3 */
#define P_GPI_BUTA_SHIFT 0x03
#define P_GPI_BUTA_MASK (1<<P_GPI_BUTA_SHIFT)
/* Button B: X0D30, 8C4 */
#define P_GPI_BUTB_SHIFT 0x04
#define P_GPI_BUTB_MASK (1<<P_GPI_BUTB_SHIFT)
/* Button C: X0D31, 8C5 */
#define P_GPI_BUTC_SHIFT 0x05
#define P_GPI_BUTC_MASK (1<<P_GPI_BUTC_SHIFT)
/* Button D: X0D33, 8C6 */
#define P_GPI_BUTD_SHIFT 0x07
#define P_GPI_BUTD_MASK (1<<P_GPI_BUTD_SHIFT)
/* Sets up HID controls */
#define HID_CONTROL_PLAYPAUSE 0x01
#define HID_CONTROL_NEXT 0x02
#define HID_CONTROL_PREV 0x04
#define HID_CONTROL_MUTE 0x20
/* Function where buttons are read, and HID commands made in response */
void UserReadHIDButtons(unsigned char hidData[])
{
/* Creates variables for each of the four buttons, and tmp to hold entire port */
unsigned a, b, c, d, tmp;
/* Imports port state into tmp */
p_sw :> tmp;
/* Buttons are active low (0 when active, 1 when inactive), so port state is inverted */
tmp = ~tmp;
/* Port state is broken into individual button states using masks defined above */
a = (tmp & (P_GPI_BUTA_MASK))>>P_GPI_BUTA_SHIFT;
b = (tmp & (P_GPI_BUTB_MASK))>>P_GPI_BUTB_SHIFT;
c = (tmp & (P_GPI_BUTC_MASK))>>P_GPI_BUTC_SHIFT;
d = (tmp & (P_GPI_BUTD_MASK))>>P_GPI_BUTD_SHIFT;
/* Results of button states are applied to HID controls */
hidData[0] = (a << HID_CONTROL_PLAYPAUSE) | (b << HID_CONTROL_NEXT) | (c << HID_CONTROL_PREV) | (d << HID_CONTROL_MUTE);
}
#endif
With this file, I get nothing from the buttons at all. Using some slightly different code, I can get the buttons to function, but they seem to repeat the HID function the entire time they are held down (so muting and unmuting many times, or skipping forward 10 tracks). Holding down a button for more than a second seems to send so many calls it can crash the audio player.
I’m not great at coding, and really hope one of you guys can point out where I’ve gone wrong.
Thanks,
Anton
I’ve been working on an audio application using an XU208-128-TQ64, based on the XHRA to XU208 project, and I have most of the functionality I want working well. The last part is HID inputs, and that’s got me stumped right now. I have buttons attached to the following inputs, and want to allocate them to the following HID functions:
Button A | X0D29 | 8C3 | HID Play/Pause |
Button B | X0D30 | 8C4 | HID Next Track |
Button C | X0D31 | 8C5 | HID Previous Track |
Button D | X0D33 | 8C7 | HID Mute |
#include <xs1.h>
#include <platform.h>
#include "devicedefines.h"
#ifdef HID_CONTROLS
/* Sets which port is used */
in port p_sw = on tile[0] : XS1_PORT_8C;
/* Sets which bits of port 8C correspond to each input */
/* Button A: X0D29, 8C3 */
#define P_GPI_BUTA_SHIFT 0x03
#define P_GPI_BUTA_MASK (1<<P_GPI_BUTA_SHIFT)
/* Button B: X0D30, 8C4 */
#define P_GPI_BUTB_SHIFT 0x04
#define P_GPI_BUTB_MASK (1<<P_GPI_BUTB_SHIFT)
/* Button C: X0D31, 8C5 */
#define P_GPI_BUTC_SHIFT 0x05
#define P_GPI_BUTC_MASK (1<<P_GPI_BUTC_SHIFT)
/* Button D: X0D33, 8C6 */
#define P_GPI_BUTD_SHIFT 0x07
#define P_GPI_BUTD_MASK (1<<P_GPI_BUTD_SHIFT)
/* Sets up HID controls */
#define HID_CONTROL_PLAYPAUSE 0x01
#define HID_CONTROL_NEXT 0x02
#define HID_CONTROL_PREV 0x04
#define HID_CONTROL_MUTE 0x20
/* Function where buttons are read, and HID commands made in response */
void UserReadHIDButtons(unsigned char hidData[])
{
/* Creates variables for each of the four buttons, and tmp to hold entire port */
unsigned a, b, c, d, tmp;
/* Imports port state into tmp */
p_sw :> tmp;
/* Buttons are active low (0 when active, 1 when inactive), so port state is inverted */
tmp = ~tmp;
/* Port state is broken into individual button states using masks defined above */
a = (tmp & (P_GPI_BUTA_MASK))>>P_GPI_BUTA_SHIFT;
b = (tmp & (P_GPI_BUTB_MASK))>>P_GPI_BUTB_SHIFT;
c = (tmp & (P_GPI_BUTC_MASK))>>P_GPI_BUTC_SHIFT;
d = (tmp & (P_GPI_BUTD_MASK))>>P_GPI_BUTD_SHIFT;
/* Results of button states are applied to HID controls */
hidData[0] = (a << HID_CONTROL_PLAYPAUSE) | (b << HID_CONTROL_NEXT) | (c << HID_CONTROL_PREV) | (d << HID_CONTROL_MUTE);
}
#endif
With this file, I get nothing from the buttons at all. Using some slightly different code, I can get the buttons to function, but they seem to repeat the HID function the entire time they are held down (so muting and unmuting many times, or skipping forward 10 tracks). Holding down a button for more than a second seems to send so many calls it can crash the audio player.
I’m not great at coding, and really hope one of you guys can point out where I’ve gone wrong.
Thanks,
Anton
-
- Active Member
- Posts: 35
- Joined: Tue Jul 20, 2010 9:45 pm
I am having the same issue as TriHex above. The XU208 will not enumerate when VBUS is disconnected, even when SELF_POWERED is set to 0. I am using the latest version of the stack combined with the zip from the original post. Any idea what this could be?
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hi. On the Vbus issue, can you test the following and post your results?
references:
https://github.com/xmos/lib_device_control/issues/66
https://www.xmos.com/developer/published/xuddg?page=3
The PwrConfig parameter to XUD_Manager() indicates if the device is bus or self-powered.
Valid values for this parameter are XUD_PWR_SELF and XUD_PWR_BUS.
When XUD_PWR_SELF is used, XUD_Manager() monitors the VBUS input for a valid voltage and reponds appropriately. The USB Specification states that the devices pull-ups must be disabled when a valid VBUS is not present. This is important when submitting a device for compliance testing since this is explicitly tested.
If the device is bus-powered XUD_PWR_SELF can be used since is assumed that the device is not powered up when VBUS is not present and therefore no voltage monitoring is required. In this configuration the VBUS input to the device/PHY need not be present.
XUD_PWR_BUS can be used in order to run on a self-powered board without provision for VBUS wiring to the PHY/device, but this is not advised.
references:
https://github.com/xmos/lib_device_control/issues/66
https://www.xmos.com/developer/published/xuddg?page=3
The PwrConfig parameter to XUD_Manager() indicates if the device is bus or self-powered.
Valid values for this parameter are XUD_PWR_SELF and XUD_PWR_BUS.
When XUD_PWR_SELF is used, XUD_Manager() monitors the VBUS input for a valid voltage and reponds appropriately. The USB Specification states that the devices pull-ups must be disabled when a valid VBUS is not present. This is important when submitting a device for compliance testing since this is explicitly tested.
If the device is bus-powered XUD_PWR_SELF can be used since is assumed that the device is not powered up when VBUS is not present and therefore no voltage monitoring is required. In this configuration the VBUS input to the device/PHY need not be present.
XUD_PWR_BUS can be used in order to run on a self-powered board without provision for VBUS wiring to the PHY/device, but this is not advised.
You do not have the required permissions to view the files attached to this post.
-
- Active Member
- Posts: 35
- Joined: Tue Jul 20, 2010 9:45 pm
In devicedefines.h, this is present:
#ifndef XUD_PWR_CFG
#ifdef SELF_POWERED
#define XUD_PWR_CFG XUD_PWR_SELF
#else
#define XUD_PWR_CFG XUD_PWR_BUS
#endif
#endif
In xTimeComposer, it shows that the value is defined as XUD_PWR_BUS
I will double-check to be sure.
#ifndef XUD_PWR_CFG
#ifdef SELF_POWERED
#define XUD_PWR_CFG XUD_PWR_SELF
#else
#define XUD_PWR_CFG XUD_PWR_BUS
#endif
#endif
In xTimeComposer, it shows that the value is defined as XUD_PWR_BUS
I will double-check to be sure.
-
- Active Member
- Posts: 35
- Joined: Tue Jul 20, 2010 9:45 pm
I tried setting it directly (#define XUD_PWR_CFG XUD_PWR_BUS), but the end result did not change. No enumeration without vbus connected.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
@jmag99 - for your design, how is your PCB powered? Using the USB Vbus or an external power supply?
Test your custom PCB with AN00129 - USB HID MOUSE (runs using USB High Speed interface)
https://www.xmos.com/resources/application-notes/
This IP creates a mouse that will spin in a square pattern till removed.
Does this demo work on your PCB? Removal and re-dock work ok with the USB interface?
Then consider to run as follows:
and post your output.
reference:
https://www.xcore.com/viewtopic.php?f=37&t=5808
Test your custom PCB with AN00129 - USB HID MOUSE (runs using USB High Speed interface)
https://www.xmos.com/resources/application-notes/
This IP creates a mouse that will spin in a square pattern till removed.
Does this demo work on your PCB? Removal and re-dock work ok with the USB interface?
Then consider to run as follows:
Code: Select all
xrun --dump-state --verbose your.xe
reference:
https://www.xcore.com/viewtopic.php?f=37&t=5808
-
- Active Member
- Posts: 35
- Joined: Tue Jul 20, 2010 9:45 pm
Board is bus powered.
Here is the output:
Here is the output:
Code: Select all
Program received signal SIGBUS, Bus error.
[Switching to tile[0] core[1] (dual issue)]
XUD_SetReady_OutPtr (ep=<value optimized out>, addr=<value optimized out>) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/usb_buffer/decouple.xc:681
681 inuchar(c_buf_ctrl);
***** Active Cores *****
5 tile[0] core[4] 0x00046e58 in XUD_DeviceAttachHS ()
4 tile[0] core[3] (dual issue) XUD_ResetEndpoint (one=<value optimized out>, two=<value optimized out>) at C:/Firmware/XMOS/sc_xud/module_xud/src/XUD_EpFunctions.xc:166
3 tile[0] core[2] (dual issue) XUD_SetReady_InPtr (ep=<value optimized out>, addr=<value optimized out>, len=3) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/usb_buffer/usb_buffer.xc:585
* 2 tile[0] core[1] (dual issue) XUD_SetReady_OutPtr (ep=<value optimized out>, addr=<value optimized out>) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/usb_buffer/decouple.xc:681
1 tile[0] core[0] (dual issue) deliver (divide=0, c_out=<value optimized out>, c_spd_out=<value optimized out>, curSamFreq=<value optimized out>, c_adc=<value optimized out>) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/audio.xc:339
Thread 5 (tile[0] core[4]):
***** Call Stack *****
#0 0x00046e58 in XUD_DeviceAttachHS ()
***** Disassembly *****
0x46e58 <XUD_DeviceAttachHS+296>: setc (ru6) res[r9], 0x1 *
0x46e5a <XUD_DeviceAttachHS+298>: in (2r) r0, res[r9] *
0x46e5c <XUD_DeviceAttachHS+300>: bt (ru6) r0, -0x3
0x46e5e <XUD_DeviceAttachHS+302>: bu (u6) 0x7
0x46e60 <XUD_DeviceAttachHS+304>: mkmsk (rus) r1, 0x1
***** Registers *****
r0 0x1 1
r1 0x3 3
r2 0x7f3a4 521124
r3 0x1 1
r4 0x1 1
r5 0x3 3
r6 0x0 0
r7 0x0 0
r8 0x12c 300
r9 0x10500 66816
r10 0x1 1
r11 0x1 1
cp 0x472b8 291512
dp 0x47838 292920
sp 0x7f3a8 521128
lr 0x46388 287624 write_periph_32_aux + 52
pc 0x46e58 290392 XUD_DeviceAttachHS + 296
sr 0x0 0
spc 0x0 0
ssr 0x0 0
et 0x0 0
ed 0x401 1025
sed 0x0 0
kep 0x40100 262400
ksp 0x46e58 290392
Thread 4 (tile[0] core[3] (dual issue)):
***** Call Stack *****
#0 XUD_ResetEndpoint (one=<value optimized out>, two=<value optimized out>) at C:/Firmware/XMOS/sc_xud/module_xud/src/XUD_EpFunctions.xc:166
#1 0x00040835 in Endpoint0 (c_ep0_out=<value optimized out>, c_ep0_in=<value optimized out>, c_audioControl=3842, c_mix_ctl=0, c_clk_ctl=<value optimized out>, c_EANativeTransport_ctrl=<value optimized out>, dfuInterface=524128) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/endpoint0\endpoint0.c:764
#2 0x00041a85 in _Susb_audio_core_0.task.Endpoint0.2 (frame=<value optimized out>) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/main.xc:383
#3 0x00046e90 in __start_core ()
***** Disassembly *****
0x442f0 <XUD_ResetEndpoint+72>: in (2r) r0, res[r2] *
0x442f2 <XUD_ResetEndpoint+74>: nop (0r)
0x442f4 <XUD_ResetEndpoint+76>: in (2r) r0, res[r3] *
0x442f6 <XUD_ResetEndpoint+78>: nop (0r)
0x442f8 <XUD_ResetEndpoint+80>: bu (lu6) 0x1
***** Registers *****
r0 0x498d8 301272
r1 0x49598 300440
r2 0x702 1794
r3 0xd02 3330
r4 0x49558 300376
r5 0xf02 3842
r6 0x49658 300632
r7 0x0 0
r8 0x7fbf4 523252
r9 0x0 0
r10 0xffffffff -1
r11 0x0 0
cp 0x472b8 291512
dp 0x47838 292920
sp 0x7fb88 523144
lr 0x40835 264245 Endpoint0 + 1049
pc 0x442f0 279280 XUD_ResetEndpoint + 72
sr 0x140 320
spc 0x0 0
ssr 0x0 0
et 0x0 0
ed 0x0 0
sed 0x0 0
kep 0x40100 262400
ksp 0x442f0 279280
Thread 3 (tile[0] core[2] (dual issue)):
***** Call Stack *****
#0 XUD_SetReady_InPtr (ep=<value optimized out>, addr=<value optimized out>, len=3) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/usb_buffer/usb_buffer.xc:585
#1 XUD_SetReady_In (ep=<value optimized out>, len=3) at C:/Firmware/XMOS/sc_xud/module_xud/include\xud.h:510
#2 buffer (c_aud_out=1282, c_aud_in=<value optimized out>, c_aud_fb=2818, c_sof=770, c_buff_ctrl=4098, p_off_mclk=1048832, c_aud_ctl=3586) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/usb_buffer/usb_buffer.xc:383
#3 0x00041a3d in _Susb_audio_core_0.task.buffer.1 (frame=<value optimized out>) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/main.xc:340
#4 0x00046e90 in __start_core ()
***** Disassembly *****
0x432d8 <buffer+264>: waiteu (0r) *
0x432da <buffer+266>: nop (0r)
0x432dc <buffer+268>: in (2r) r0, res[r6] *
0x432de <buffer+270>: add (2rus) r7, r8, 0x0
0x432e0 <buffer+272>: nop (0r)
***** Registers *****
r0 0x0 0
r1 0x1 1
r2 0x1770000 24576000
r3 0x302 770
r4 0x502 1282
r5 0xb02 2818
r6 0x302 770
r7 0x49928 301352
r8 0xe02 3586
r9 0x0 0
r10 0x0 0
r11 0x43400 275456
cp 0x472b8 291512
dp 0x47838 292920
sp 0x7fc88 523400
lr 0x43229 274985 buffer + 89
pc 0x432d8 275160 buffer + 264
sr 0x141 321
spc 0x0 0
ssr 0x0 0
et 0x0 0
ed 0x0 0
sed 0x0 0
kep 0x40100 262400
ksp 0x432d8 275160
Thread 2 (tile[0] core[1] (dual issue)):
***** Call Stack *****
#0 XUD_SetReady_OutPtr (ep=<value optimized out>, addr=<value optimized out>) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/usb_buffer/decouple.xc:681
#1 decouple (c_mix_out=2, c_buf_ctrl=4354) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/usb_buffer/decouple.xc:871
#2 0x00041aa9 in _Susb_audio_core_0.task.decouple.3 (frame=<value optimized out>) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/main.xc:389
#3 0x00045bb4 in __start_other_cores ()
***** Disassembly *****
0x42e10 <decouple+304>: int (2r) r0, res[r0] *
0x42e12 <decouple+306>: nop (0r)
0x42e14 <decouple+308>: bu (lu6) 0x1
0x42e18 <decouple+312>: stw (lru6) r7, dp[0x97b]
0x42e1c <decouple+316>: ldw (lru6) r0, dp[0x969]
***** Registers *****
r0 0x1102 4354
r1 0x48414 295956
r2 0x4955c 300380
r3 0x2 2
r4 0x0 0
r5 0x2 2
r6 0xbb80 48000
r7 0x1 1
r8 0x402 1026
r9 0x0 0
r10 0x7fd38 523576
r11 0x408c4 264388
cp 0x472b8 291512
dp 0x47838 292920
sp 0x7fd38 523576
lr 0x41aa9 268969 _Susb_audio_core_0.task.decouple.3 + 29
pc 0x42e10 273936 decouple + 304
sr 0x142 322
spc 0x42db8 273848 decouple + 216
ssr 0x102 258
et 0x0 0
ed 0x0 0
sed 0x0 0
kep 0x40100 262400
ksp 0x42e10 273936
Thread 1 (tile[0] core[0] (dual issue)):
***** Call Stack *****
#0 deliver (divide=0, c_out=<value optimized out>, c_spd_out=<value optimized out>, curSamFreq=<value optimized out>, c_adc=<value optimized out>) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/audio.xc:339
#1 0x00041841 in audio (c_mix_out=258, c_config=0, c=<value optimized out>) at C:/Firmware/XMOS/sc_usb_audio/module_usb_audio/audio.xc:1211
#2 0x00041ac1 in __main__main_tile_0 ()
Backtrace stopped: frame did not save the PC
***** Disassembly *****
0x412b0 <deliver+216>: syncr (1r) res[r4] *
0x412b2 <deliver+218>: nop (0r)
0x412b4 <deliver+220>: getts (2r) r5, res[r4]
0x412b6 <deliver+222>: nop (0r)
0x412b8 <deliver+224>: ldc (lru6) r7, 0x64
***** Registers *****
r0 0x102 258
r1 0xbb80 48000
r2 0x0 0
r3 0x0 0
r4 0x10c00 68608
r5 0x102 258
r6 0x10e00 69120
r7 0x1770000 24576000
r8 0x87654321 -2023406815
r9 0x0 0
r10 0x7fe88 523912
r11 0x0 0
cp 0x472b8 291512
dp 0x47838 292920
sp 0x7fe10 523792
lr 0x41841 268353 audio + 405
pc 0x412b0 266928 deliver + 216
sr 0x140 320
spc 0x0 0
ssr 0x0 0
et 0x0 0
ed 0x0 0
sed 0x0 0
kep 0x40100 262400
ksp 0x412b0 266928
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
The original XHRA-2HPA shows that USB connector Vbus is connected to the USB_Vbus pin of the CPU and the PCB is USB bus powered.
Do you have support for doing the same?
Is there a known issue or risk to mate the Vbus pin of the CPU to the USB Vbus connector pin (through an inrush filter or similar current limit IC) and still be Bus powered?
Not an audio developer so thought to raise this silly question. This topic has been raised many times so curious on the end resolution.
Do you have support for doing the same?
Is there a known issue or risk to mate the Vbus pin of the CPU to the USB Vbus connector pin (through an inrush filter or similar current limit IC) and still be Bus powered?
Not an audio developer so thought to raise this silly question. This topic has been raised many times so curious on the end resolution.