Migrating from XHRA to XU208

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
TriHex
Newbie
Posts: 1
Joined: Sun May 19, 2019 3:25 pm

Re: Migrating from XHRA to XU208

Postby TriHex » Sun May 19, 2019 3:38 pm

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
DHembree
Experienced Member
Posts: 75
Joined: Fri Apr 15, 2016 6:46 pm

Postby DHembree » Wed Jun 05, 2019 4:47 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?
amc184
New User
Posts: 2
Joined: Sun Jan 08, 2017 5:03 am

Postby amc184 » Mon Jun 10, 2019 8:52 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:
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
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
jmag99
Active Member
Posts: 35
Joined: Tue Jul 20, 2010 9:45 pm

Postby jmag99 » Thu Jun 27, 2019 12:56 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?
User avatar
mon2
XCore Legend
Posts: 1500
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Jun 28, 2019 12:04 pm

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.


xmos_vbus.png
You do not have the required permissions to view the files attached to this post.
jmag99
Active Member
Posts: 35
Joined: Tue Jul 20, 2010 9:45 pm

Postby jmag99 » Fri Jun 28, 2019 12:19 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.
jmag99
Active Member
Posts: 35
Joined: Tue Jul 20, 2010 9:45 pm

Postby jmag99 » Fri Jun 28, 2019 1:33 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.
User avatar
mon2
XCore Legend
Posts: 1500
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Jun 28, 2019 1:46 pm

@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:

Code: Select all

xrun --dump-state --verbose your.xe
and post your output.

reference:
viewtopic.php?f=37&t=5808
jmag99
Active Member
Posts: 35
Joined: Tue Jul 20, 2010 9:45 pm

Postby jmag99 » Fri Jun 28, 2019 3:27 pm

Board is bus powered.

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
User avatar
mon2
XCore Legend
Posts: 1500
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Jun 28, 2019 3:51 pm

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.

Who is online

Users browsing this forum: No registered users and 0 guests