xCORE-AUDIO-HiRes-2 clock settings Topic is solved

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
Junior Member
Posts: 5
Joined: Mon Jan 02, 2017 8:56 am

xCORE-AUDIO-HiRes-2 clock settings

Postby vveasel » Mon Jan 02, 2017 9:57 am


I can not get my head around clocks generation and routing on xCORE-AUDIO-HiRes-2 platform.

1/ XHRA-2HPA datasheet is sketchy on details but fairly logical - suggesting two frequency generator (24.576 MHz and 22.5792 MHz) controlled by GPIO_3 (default setting) with generator output tied up to both XRHA MCLK and DAC MCLK inputs.


2/ xCORE-AUDIO-HiRes-2 uses Si5351A-B04486-GT which is (according to Si labs addendum - http://www.silabs.com/internal-apps-man ... dendum.pdf) is preprogrammed to CLK1= 49.152000000 Mhz, CLK1 = 24.000000 Mhz and CLK2=45.158400000 Mhz.

So frequencies are twice higher but that's ok. But XHRA is MCLK is connected to CLK1, while DAC MCLK to CLK2 i.e. different frequencies ?! Why?

3/ GPIO_3 is tied up to RESET signal, meaning it is reprogrammed. Does it mean XHRA used in xCORE-AUDIO-HiRes-2 has a different fw revision? Or it is set by QSPI firmware?

Everything else is fairly straightforward but I am a bit stuck here. Any ideas?

View Solution
User avatar
XCore Legend
Posts: 1756
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Tue Jan 03, 2017 12:49 am

Hi Alex. Not a developer of audio widgets using XMOS but have the following limited comments which may help:

1) The xCORE-AUDIO-HiRes-2 CPU is an XMOS processor which communicates with the host PC via the USB interface. For this reason, the 24 Mhz clock value is suitable and required for framing the USB packets. The other clocks generated by the external PLL are not valid for USB framing.

2) Respectively, the DAC clocks must have been calculated and defined to be suitable for the high quality audio framing using the ESS DAC.

The use of a factory programmed clock source for the CPU is practical since the CPU is unable to boot without an oscillating clock.

3) In both cases, the external PLL is an I2C device which is available as a pre-configured device through SiLabs. XMOS has created the specific p/n which you have referenced in your post. Slapping this specific PLL, the ESS 9018 DAC shown in the ref design, the firmware posted for this project inside a QSPI flash device (please review the supported QSPI p/n and vendors) - will allow you to create a Plug & Play clone of the same ref design. Suspecting that most of the XMOS products on Aliexpress are from the same ref design.

NB: It is important that the QSPI flash device contain the XMOS supplied firmware AND that you enable the QSPI mode bit for this widget to operate correctly as the ROM inside this canned XMOS CPU demands the firmware to load in QUAD SPI mode. Also important to note that the same XMOS CPU cannot program a blank QSPI flash - you must perform this task out of circuit and then solder onto your board OR place the final product in RESET mode (to tri-state the related interface pins -> then assert the SPI / QSPI lines to inject the firmware via pogo-pins or similar tool). Since standard SPI is a subset of QSPI, it is possible to flash the entire firmware using standard (slow) SPI mode which will take a while (we found to be around 7 minutes) and then using standard SPI mode to enable the QSPI bit. The QSPI bit is non-volatile once configured. The firmware for this design is closed source and supported directly by XMOS.

There are in depth threads on this subject - including on how to properly format the firmware inside the QSPI flash. We dissected the XHRA-2 PCB and removed the factory QSPI flash -> dumped the contents and applied onto a blank to study the flashing process.

http://www.xcore.com/forum/viewtopic.ph ... =XHRA+2HPA

We have not validated the process but it should be possible to take a XCORE-200 CPU based kit (which features the QSPI socket) and then use it to program a blank flash device using the XFLASH tool supplied tool.

4) Yes, the firmware stored inside this QSPI flash device (by you) will perform the required tasks, including RESET of the DAC via GPIO_3 port pin.
Junior Member
Posts: 5
Joined: Mon Jan 02, 2017 8:56 am

Postby vveasel » Tue Jan 03, 2017 6:40 am

Hi mon2,

Appreciate your comments. Yes, my board has a provision for in-circuit QSPI programming, so I believe this issue has been taken care of.

My main question is about master clock which should be a single 24.576 MHz ( or 22.5792MHz) clock to both Xcore and Dac, but it is 49.152 Mhz (CLK0) for Xcore and 45.1584 Mhz (CLK2) for DAC instead (as per schematics/datasheet).

I suspect only 24 Mhz clock is used from Si5351A-B04486-GT during boot time and later CLK0 and CLK2 get reprogrammed via i2C but need to be sure. Unfortunately, USB Audio 2.0 Reference Design does not cover xCORE-AUDIO-HiRes-2.
Junior Member
Posts: 5
Joined: Mon Jan 02, 2017 8:56 am

Postby vveasel » Tue Jan 03, 2017 8:40 am

Found an answer in xCORE-AUDIO Hi-Res 2 DAC/HPA reference platform configuration file. SI5351 master clock is reconfigured to correct settings within sample rate selection events.

Who is online

Users browsing this forum: No registered users and 3 guests