Porting USB 2.0 Audio Reference onto XUF208-256-TQ64 custom Hardware

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
sebbo
New User
Posts: 2
Joined: Thu May 24, 2018 8:55 am

Porting USB 2.0 Audio Reference onto XUF208-256-TQ64 custom Hardware

Postby sebbo » Thu May 24, 2018 9:49 am

Hi,

I got a custom hardware with a XUF208-256-TQ64 and should create a USB to I2S converter to test different DAC. I created my project after the application note: "AN01027 Porting the XMOS USB 2.0 Audio Reference Software onto XU208 custom hardware". Everything went relatively smoothly. After some compilation problems I managed to flash the software on the Xmos. Then I installed the USB Audio 2.0 driver https://www.xmos.com/published/usb-audio-class-20-evaluation-driver-windows. But the device is not recognized as a USB device in Windows 10, nor is it recognized by the audio driver. The USB interface is connected to the board as shown in Figure 11 in the data sheet (https://www.xmos.com/download/private/XUF208-256-TQ64-Datasheet%281.15%29.pdf). Furthermore, the I2S is connected to pins X0D28, X0D32, X0D27 on the xmos.

1. is it possible to get such a converter via the Audio reference software?
2 Are the USB mappings in the XUF208-256-TQ64-I10.xn correct?
3. is there a way to debug the USB connections through the software?
4. does anyone have any idea what the problem is.
5. is the connection for the I2S even correct? I don't really understand mapping.
6. are the xmap warnings meaningful? (compiler_output.jpg)

I hope someone can help me.
Attachments
compiler_output.JPG
(78.44 KiB) Not downloaded yet
compiler_output.JPG
(78.44 KiB) Not downloaded yet
Makefile.txt
(2.69 KiB) Downloaded 46 times
Makefile.txt
(2.69 KiB) Downloaded 46 times
XUF208-256-TQ64-I10.xn
(3.21 KiB) Downloaded 47 times
XUF208-256-TQ64-I10.xn
(3.21 KiB) Downloaded 47 times
User avatar
mon2
XCore Legend
Posts: 1255
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Fri May 25, 2018 11:39 am

Hello.

1) yes it is possible to build your widget as required using the same processor. Audio field is a focus of XMOS.

2) the first warning could be the root cause of your IP failure. To support USB on XMOS devices, the software requires a certain amount of cpu bandwidth. The more cores that are used on a tile, the lower the bandwidth (MIPS). You are using 7 cores and believe only a max of 6 cores should be used else USB IP will not work.

3) post your schematic for a review to rule hardware issues
User avatar
mon2
XCore Legend
Posts: 1255
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Sat May 26, 2018 9:59 pm

A correction to my earlier post on the max limit of threads per tile restriction for USB support:

viewtopic.php?f=37&t=6460
sylvester
New User
Posts: 2
Joined: Tue May 08, 2018 9:41 pm

Postby sylvester » Tue May 29, 2018 10:24 pm

Hi,

If I may suggest, I have also created my first prototype with XMOS processor (XUF-208) and the project
which can be found here turned out to be easier in getting a working USB audio class device.
I had only to make changes in src/core/xhra_xcore.xn file as shown below and also needed to modify
src/extensions/audiohw.xc as I had 2 crystal oscillators selected by a GPIO rather than
an external PLL controlled over I2C bus.

Windows 10 recognizes the device without a need to manually install any additional drivers.

It also works well on Ubuntu:

thinkpad:~$ aplay -l
...
card 1: XHRAXU208 [XHRA->XU208], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0

thinkpad:~$ amixer -c1
Simple mixer control 'XHRA->XU208 ',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 127
Mono:
Front Left: Playback 127 [100%] [0.00dB] [on]
Front Right: Playback 127 [100%] [0.00dB] [on]
Simple mixer control 'XHRA->XU208 ',1
Capabilities: pvolume pvolume-joined pswitch pswitch-joined
Playback channels: Mono
Limits: Playback 0 - 127
Mono: Playback 127 [100%] [0.00dB] [on]


diff --git a/src/core/xhra_xcore.xn b/src/core/xhra_xcore.xn
index 1df47bb..0cb2331 100644
--- a/src/core/xhra_xcore.xn
+++ b/src/core/xhra_xcore.xn
@@ -24,15 +24,15 @@
<Port Location="XS1_PORT_4B" Name="PORT_SQI_SIO"/>

<!-- Audio Ports -->
- <Port Location="XS1_PORT_1N" Name="PORT_MCLK_IN"/>
- <Port Location="XS1_PORT_1M" Name="PORT_I2S_LRCLK"/>
+ <Port Location="XS1_PORT_1L" Name="PORT_MCLK_IN"/>
+ <Port Location="XS1_PORT_1O" Name="PORT_I2S_LRCLK"/>
<Port Location="XS1_PORT_1P" Name="PORT_I2S_BCLK"/>
- <Port Location="XS1_PORT_1O" Name="PORT_I2S_DAC0"/>
- <Port Location="XS1_PORT_4C" Name="PORT_I2C"/>
- <Port Location="XS1_PORT_1M" Name="PORT_DSD_DAC0"/>
- <port Location="XS1_PORT_1O" Name="PORT_DSD_DAC1"/>
+ <Port Location="XS1_PORT_1M" Name="PORT_I2S_DAC0"/>
+ <Port Location="XS1_PORT_4E" Name="PORT_I2C"/>
+ <Port Location="XS1_PORT_1O" Name="PORT_DSD_DAC0"/>
+ <port Location="XS1_PORT_1M" Name="PORT_DSD_DAC1"/>
<Port Location="XS1_PORT_1P" Name="PORT_DSD_CLK"/>
- <Port Location="XS1_PORT_1L" Name="PORT_SPDIF_OUT"/>
+ <Port Location="XS1_PORT_1A" Name="PORT_SPDIF_OUT"/>
<Port Location="XS1_PORT_16B" Name="PORT_MCLK_COUNT"/>

<!-- USB Ports -->


I'm going to post the full schematics for review, after making necessary corrections for version 2 of the PCB.
I have learnt the hard way the PLL_AVDD needs to be connected to 1V voltage supply, not the 3.3V one.
I could likely avoid some headache and wasting one piece of XUF208 if I have posted initial version of the
schematics for review.
Attachments
0fa6dbcd2089f81f1227526346d3084f_1526933885.jpg
(377.78 KiB) Not downloaded yet
0fa6dbcd2089f81f1227526346d3084f_1526933885.jpg
(377.78 KiB) Not downloaded yet
5c0abf2bef46c82e40f4b35b2dc4f2a4_1526933482.jpg
(177.55 KiB) Not downloaded yet
5c0abf2bef46c82e40f4b35b2dc4f2a4_1526933482.jpg
(177.55 KiB) Not downloaded yet
sebbo
New User
Posts: 2
Joined: Thu May 24, 2018 8:55 am

Postby sebbo » Sat Jun 09, 2018 1:55 pm

After a short break from the Xmos to I2S converter project, I took up the project again. Meanwhile I have managed that Windows 10 recognizes the device immediately by applying VBUS 5V (I know that this is not recommended for a USB powered device). But now I have the following problem: If I want to play a Windows test sound, the output (Windows Sound Test) hangs. The schematic and an image of the Windows Sound Test is attached. I hope someone has an idea how to figure out what's causing it. Out of desperation I once tested the HID-Class Application Note, it works perfectly.
Attachments
usb2i2s_xmos_final.pdf
(47.83 KiB) Downloaded 53 times
usb2i2s_xmos_final.pdf
(47.83 KiB) Downloaded 53 times
sound test.PNG
(29.68 KiB) Not downloaded yet
sound test.PNG
(29.68 KiB) Not downloaded yet
User avatar
mon2
XCore Legend
Posts: 1255
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Tue Jun 12, 2018 12:35 pm

If the XMOS HID example works with your PCB then the audio IP should be reviewed.

Otherwise,

a) PCB is impedance controlled for the USB traces?

b) The center pad of the XMOS CPU is grounded on the PCB design?

c) Be sure to have inrush transient protection for the VBUS line to avoid permanent damage to the XMOS CPU:

viewtopic.php?t=5936
sylvester
New User
Posts: 2
Joined: Tue May 08, 2018 9:41 pm

Postby sylvester » Tue Jun 12, 2018 8:00 pm

In your XUF208-256-TQ64-I10.xn file you have:

<Port Location="XS1_PORT_1N" Name="PORT_MCLK_IN"/>

But pin X0D37 seems to be not connected to any clock source. What is supposed to be the I2S root
clock in your circuit?

I'm not sure which reference design are you using currently, but in my case (xhra2xu208_1v0.zip)
I had to disable I2C communication in AudioHwInit and AudioHwConfig callbacks, as I had nothing
connected to the I2C bus. I did it initially by simply modifying the *_REGREAD, *_REGWRITE macros
as shown below. Sorry, I forgot to mention about it in my previous post, these I2C communication
attempts were causing audio playback hangs if I recall correctly.

thinkpad:/hdd/devel/xmos/workspace/app_usb_aud_xu208_xhra(master)$ git diff
diff --git a/src/extensions/audiohw.xc b/src/extensions/audiohw.xc
index e0850fc..9c55b54 100644
--- a/src/extensions/audiohw.xc
+++ b/src/extensions/audiohw.xc
@@ -43,12 +43,12 @@ struct r_i2c i2c = {PORT_I2C};
#define SABRE9018Q2C_2A 0x2A

// SI5351B easy register access defines
-#define SI5351A_REGREAD(reg, data) {data[0] = 0xAA; i2c_master_read_reg(SI5351A_I2C_DEVICE_ADDR, reg, data, 1, i2c);}
-#define SI5351A_REGWRITE(reg, val) {data[0] = val; i2c_master_write_reg(SI5351A_I2C_DEVICE_ADDR, reg, data, 1, i2c);}
+#define SI5351A_REGREAD(reg, data) (0)
+#define SI5351A_REGWRITE(reg, val)

// SABRE9018Q2C easy register access defines
-#define SABRE9018Q2C_REGREAD(reg, data) {data[0] = 0xAA; i2c_master_read_reg(SABRE9018Q2C_I2C_DEVICE_ADDR, reg, data, 1, i2c);}
-#define SABRE9018Q2C_REGWRITE(reg, val) {data[0] = val; i2c_master_write_reg(SABRE9018Q2C_I2C_DEVICE_ADDR, reg, data, 1, i2c);}
+#define SABRE9018Q2C_REGREAD(reg, data) (0)
+#define SABRE9018Q2C_REGWRITE(reg, val)
User avatar
mon2
XCore Legend
Posts: 1255
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Wed Jun 13, 2018 2:44 am

Your current limit resistors for the LEDs are quite low @ 90R9 ohms. Any specific reason for such a low value? You may be exceeding the max source current with such low resistor values for the respective GPIO port pins on the CPU.

Recommend to increase the resistor value to 470 ohms to 1k range for each. If you are after nice and bright signal LEDs then consider to source a LED with a high MCD rating rather than lowering the series LED resistors. We use 80 or higher MCD rated SMD and through hole LEDs in assorted projects. Some are scary bright so approach with caution.
sleepfox
Member
Posts: 12
Joined: Fri Jun 01, 2018 5:03 pm

Postby sleepfox » Thu Jun 14, 2018 4:59 pm

Hi, judging from your schematics, the pins that you picked for I2S are all 4-bit ports. Not sure if that would be an issue but the XMOS application notes specifically recommend 1bit port for I2S. And there seem not to be any master clock input for audio.

Who is online

Users browsing this forum: No registered users and 17 guests