With the obsolescence of the the XHRA USB Audio device https://www.xmos.com/download/private/X ... 281%29.pdf we wanted to offer a migration path.
If you use the XU208-128-TQ64-C10 device you will be able to produce a PIN COMPATIBLE replacement for the XHRA-2HPA-TQ64-C. This means it is possible to migrate to an XU208 device without making hardware changes to your XHRA system, although there will be some software work to do.
This post offers an example project which is designed to run on the XK-USB-AUDIO-HPA evaluation board https://www.xmos.com/support/boards?product=18340. Ie. if you remove the HXRA device from this board and replace it with an XU208 with this project in the SPI FLASH, it will function as a working headphone Amp.
Please note that the XU208 based solution will require you to download the Usb Audio Reference design https://www.xmos.com/support/software/uac2 and make modifications in the source to port it to your hardware. This normally involves modifying:
- customdefines.h (high level setting such as channel count, feature toggling (SPDIF, MIDI, HID, DFU etc..), supported sample rates/depths and PID/VID)
- audiohw.xc (audio hardware setup including DAC, clocks, LEDs etc.)
- xhra_xcore.xn (This is the xcore system description file for the project where you define audio signal pinout and FLASH specification) files, and sometimes:
- audiostream.xc & hostactive.xc if you wish to indicate when streams start/stop and when the USB host is active
The reference design documentation provides further details on the above - see section 5.6
Clearly you must ensure that the binary you compile for the XU208 is fully correct before flashing the QSPI device. It is possible to connect an XTAG debug adapter to the XHRA hardware using TP6..9 on the board which correspond to pins 60..63 on the device which are TMS, TCK, TDI and TDO. You will also need to connect to RST_N (TP10) to the XTAG. This way you can download and debug your app and even flash into the attached QSPI device. This is by far the most convenient way to develop and gives good debug visibility. You can do the same for your own hardware. See section H of the XU208 datasheet for more details of providing debug connections. http://www.xmos.com/download/private/XU ... t(1.9).pdf
Features of the attached project:
- USB Audio 2.0 (USB Audio class 1.0 fallback disabled)
- 44.1 - 384kHz Sample rates
- 32b PCM data
- DoP Support for 64x and 128x
- DSD Native support for 64x, 128x and 256x
- Uses ESS9018 DAC and SI5351A frequency generator as per XHRA hardware
- SPDIF Tx (up to 192kHz @ 24b)
- DFU Enabled
- VID/PID = 0x20B1/0x3066 (as per XHRA)
- Based on audio reference design 6.15.2rc2
- Includes DSD fix for the above release (see thread http://www.xcore.com/viewtopic.php?t=5010)
- It's C source so you can add a lot more functionality over the XHRA if you choose and integrate other MCU style features
Instructions for use:
- Download and unzip this source package
- Copy over the top of a fresh 6.15.1rc2 (latest released version) reference design download. Note you will need to copy into the root of the reference design project so that the sw_usb_audio and sc_usb_audio subdirectories are correctly overlaid. Download from here https://www.xmos.com/support/software/uac2
- Make sure you have a copy of the XMOS tools. We used 14.3.2 to test this. Download from here https://www.xmos.com/support/tools where you can also find links to user guides and programming docs
- Build the app_usb_aud_xu208_xhra project. Please see usual documentation for doing this:
https://www.xmos.com/download/private/s ... ha1%29.pdf
- Download to your XU208 or program the flash. To make a raw binary file suitable for programming a SPI FLASH, you can use xflash -o app_usb_aud_xu208.bin --noinq --boot-partition-size 2097152 bin/app_usb_aud_xu208_xhra.xe. Note that the boot partition size has been set to the whole flash device, in this case, a 16Mb IS25LQ016B. The boot partition has the bootloader, factory image and upgrade image in it. Please consult the tools documentation for more info on this.
Please note that this project is supplied 'as is', outside of the official release channels, without support or any warranty. It does work however and has undergone basic testing and is based on the reference design which is being used in hundreds of commercial products. The intention of supplying this is to make the transition from XHRA to XU208 as easier but please accept that you will be responsible for the source customisation to your own hardware.
[Edit 5th March 2018]
I have re-uploaded the source with eclipse (xtimecomposer GUI) project files. This means you can now do a simple import instead of file->"new xtimecomposer project based on existing application"
Migrating from XHRA to XU208
-
Verified
- XCore Legend
- Posts: 1140
- Joined: Thu May 27, 2010 10:08 am
Migrating from XHRA to XU208
You do not have the required permissions to view the files attached to this post.
Engineer at XMOS
-
- XCore Addict
- Posts: 222
- Joined: Mon Jan 08, 2018 4:14 pm
Hi
thanks for this post that also provides us with the perspective of using almost the standard "XK-USB-AUDIO-HPA evaluation board" hardware design with a proper piece of software running off the shelf without the trouble of deciphering the AN01027.
At least that is my plan now.
may I share a picture of the port mapping resulting from an analysis of the Hardware schematic and cross lecture of the XU208 datasheet. this may help :)
one question, could you confirm the compatibility of this platform with a 8 channel PCM I2S output (using P1A0, P1D0 and P1L0 for the 3 other I2Slines) and then what max frequency could we expect, 192k ?
thank you
thanks for this post that also provides us with the perspective of using almost the standard "XK-USB-AUDIO-HPA evaluation board" hardware design with a proper piece of software running off the shelf without the trouble of deciphering the AN01027.
At least that is my plan now.
may I share a picture of the port mapping resulting from an analysis of the Hardware schematic and cross lecture of the XU208 datasheet. this may help :)
one question, could you confirm the compatibility of this platform with a 8 channel PCM I2S output (using P1A0, P1D0 and P1L0 for the 3 other I2Slines) and then what max frequency could we expect, 192k ?
thank you
-
Verified
- XCore Legend
- Posts: 1140
- Joined: Thu May 27, 2010 10:08 am
Thanks - that portmap looks good and reflects xhra_xcore.xn and gpio_access.h in the app files.
The limitation is 64Mbps over the ISO data endpoint. So 8 x 32 * 192000 = 49152000 Mbps, which is OK.
Yes - that should be fine. As you suggested, you would lose SPDIF out due to limited 1b ports. You could possibly get one back by re-using SPI-CLK at runtime but you'd have to be very careful with SI on the clock line and ensure that the DAC was very muted during boot/DFU. Much easier to lose SPDIF TX..one question, could you confirm the compatibility of this platform with a 8 channel PCM I2S output (using P1A0, P1D0 and P1L0 for the 3 other I2Slines) and then what max frequency could we expect, 192k ?
The limitation is 64Mbps over the ISO data endpoint. So 8 x 32 * 192000 = 49152000 Mbps, which is OK.
Engineer at XMOS
-
- XCore Addict
- Posts: 222
- Joined: Mon Jan 08, 2018 4:14 pm
Thank you for your confirmation.
Also I ve just realized that someone is having a similar project leveraging this compatibility between the 2 chips and has even published a schematic here (only stereo channels but ok):
http://www.xcore.com/viewtopic.php?f=21&t=6328
Another question about this reference design and your xu208_xhra software, could you confirm that due to I2C on port 4C0 4C1 then it is not possible to use 4C2 4C3 in any case ? or it is possible to tweak the I2C lib ?
also just reading the SPI library app note (I need SPI too) it seems I cannot use it as it would requires only 1bit port type which we dont have anymore.
Anychance to adapt the SPI library (master and combine in IAP_TILE) for using port 4E0..3 for exemple ?
last but not least I cant see in the USB stack any sort of call for treating Vendor request type of command, any chance to get help on this in case I pursue this direction ?
thank you
Also I ve just realized that someone is having a similar project leveraging this compatibility between the 2 chips and has even published a schematic here (only stereo channels but ok):
http://www.xcore.com/viewtopic.php?f=21&t=6328
Another question about this reference design and your xu208_xhra software, could you confirm that due to I2C on port 4C0 4C1 then it is not possible to use 4C2 4C3 in any case ? or it is possible to tweak the I2C lib ?
also just reading the SPI library app note (I need SPI too) it seems I cannot use it as it would requires only 1bit port type which we dont have anymore.
Anychance to adapt the SPI library (master and combine in IAP_TILE) for using port 4E0..3 for exemple ?
last but not least I cant see in the USB stack any sort of call for treating Vendor request type of command, any chance to get help on this in case I pursue this direction ?
thank you
-
- Active Member
- Posts: 35
- Joined: Tue Jul 20, 2010 9:45 pm
When I try to download the project, it says the attachment does not exist anymore? Does anyone have the file?
-
Verified
- XCore Legend
- Posts: 1140
- Joined: Thu May 27, 2010 10:08 am
Weird - Sorry about that, I have re-attached it.it says the attachment does not exist anymore?
Engineer at XMOS
-
Verified
- XCore Legend
- Posts: 1140
- Joined: Thu May 27, 2010 10:08 am
Each port has only a single direction register so you can't have mixed directions. However, XS2 (xcore 200) has a drive low feature which drives low for 0 or open for 1, but again is set for the whole port and for I2C using a 4b port it will need to be set to this mode.could you confirm that due to I2C on port 4C0 4C1 then it is not possible to use 4C2 4C3 in any case ? or it is possible to tweak the I2C lib ?
You could probably tweak sc_i2c by changing S_REST from a define to a variable if you really needed to as long as you can handle low or high Z.
It's possible but is a non-trivial change to the software and would also reduce throughput.. You could always chose a bigger device with more 1b ports if needed.also just reading the SPI library app note (I need SPI too) it seems I cannot use it as it would requires only 1bit port type which we dont have anymore.
Anychance to adapt the SPI library (master and combine in IAP_TILE) for using port 4E0..3 for exemple ?
There are hooks for this. See VENDOR_AUDIO_REQS in endpoint0.clast but not least I cant see in the USB stack any sort of call for treating Vendor request type of command, any chance to get help on this in case I pursue this direction ?
Engineer at XMOS
-
- Active Member
- Posts: 35
- Joined: Tue Jul 20, 2010 9:45 pm
Is this a command-line build only? It doesn't appear that the eclipse project files are included, so I don't see a way to import this into Composer.
-
- Active Member
- Posts: 35
- Joined: Tue Jul 20, 2010 9:45 pm
Also received this error:
xflash -o app_usb_aud_xu208.bin --noinq bin/app_usb_aud_xu208_xhra.xe
Warning: F03097
Cannot check factory image protection because --noinq was specified.
Error: F03093 Cannot set boot partition size: no explicit boot partition size and no inquirer used.
By default the boot partition occupies the whole flash device but the flash device
size cannot be determined because the inquirer has been disabled. To fix this either
allow the inquirer to run (remove --noinq) or explicitly specify the boot partiton size
with --boot-partition-size.
What should the boot partition size be set to?
xflash -o app_usb_aud_xu208.bin --noinq bin/app_usb_aud_xu208_xhra.xe
Warning: F03097
Cannot check factory image protection because --noinq was specified.
Error: F03093 Cannot set boot partition size: no explicit boot partition size and no inquirer used.
By default the boot partition occupies the whole flash device but the flash device
size cannot be determined because the inquirer has been disabled. To fix this either
allow the inquirer to run (remove --noinq) or explicitly specify the boot partiton size
with --boot-partition-size.
What should the boot partition size be set to?
-
- Active Member
- Posts: 35
- Joined: Tue Jul 20, 2010 9:45 pm
We found that after swapping to the new processor, the chip select is always held low. Tried 2 different boards. It's the XMOS causing the issue, as I tried removing the spi flash and isolated the problem to the XMOS. Any ideas?