Audio clocks problem on XS1_U8A

[genap]

I have a project where XS1-U8A is receiving TDM8 audio from ADC (XMOS is a master) and sends it over USB to the host system for recording.
We have a few designs like this working without any problems.

Nevertheless In the current design we've faced a problem with disappearing audio.
Once in a while with no apparent reason ADC stops sending proper TDM audio and sends a train of pulses instead, which looks like a single bit per TDM8 channel.
Resuming proper operation requires power cycling.
After some testing we were able to reproduce this issue.
It seems like after touching any of the 24MHz crystal pins the LRCLK and BCLK frequencies change.
LRCLK changes from 48KHz to 45.6KHz,
BCLK changes from 12.288MHz to 12.998MHz.
At this point an ADC stops functioning properly.
The frequencies never return to the proper values, and the only way to recover is a power cycling.

Will appreciate any advice on the resolution of this issue.
Gennady

[Caleb]

Are you referring to the 24.000MHz system clock oscillator or the 24.576MHz audio master clock oscillator? If touching something on the PCB makes a change then maybe there's an assembly fault or contamination on the board. Perhaps there is solder flux that you can clean with alcohol but sometimes contamination under an IC is difficult or impossible to clean. Is this a BGA package XS1_U8A? We've occasionally had PCBs where the BGA was not correctly assemble - not enough hear to re-flow all of the balls. In one case we were lucky that it was a ball on the outside row that we could see. I think that it the mclk pin. There was not enough room to each with the smallest soldering iron tip. We used a piece of small wire, heated it with the iron, small amount of solder on the end and touched that to the BGA ball long enough to get it to flow to the pad. I think there was another PCB that had an assembly problem that we were able to fix by heating the PCB in an oven. We don't have a sophisticated hot air rework tool.
If it's the 24MHz system oscillator, do you have a proper 1.8V clock buffer that has proper rise time and jitter performance to meet the spec.?

[mon2]

@genap - believe that you may be creating a different event by touching the crystal that is resulting in the same issue of ADC lockup.

Checklist:

1) Are you actually using a crystal (not powered) or a crystal oscillator (will be powered)? Best if you can share that part of the schematic if there is any doubt.

If crystal, then yes, your finger touches will present more load capacitance and throw off the crystal operation till the XMOS CPU and/or ADC falls into twilight zone. Actually this very finger trick was a CPU hack years ago to into a hidden factory bootloader - a story for another time...

A quick idea to test if you suspect the crystal operation is to source a 3v3 (3.3 volt) crystal oscillator @ 24 Mhz or whatever you have onboard from Arrow / Digikey / Mouser for tomorrow. Then cut the output of your current crystal oscillator and feed the output from your new part direct into the XMOS CPU. Now if you finger touch the oscillator, the output will not deviate since the parts are encased inside the SMD oscillator you are about to purchase.

2) However, guessing the above is not the issue - can you download AN00129 HID mouse demo from the XMOS toolchain and compile and test on your board? This will move the mouse pointer around till stopped in a square pattern - does this run for hours / till you stop the demo? Trying to validate your USB communication here.

Left side of the toolchain -> examples -> USB examples -> AN00129 -> double click and compile -> rest will follow automatically to update the IP as required. You may need to manually update the lib_xassert from down left side of the toolchain = 3.0.0 version that is required for the HID demo. Double-click on the lib_xassert down south and the toolchain will inform you of the old / new version details. Allow for this update to continue -> compile and test the mouse IP.

3) Next, you must review the source code to EXCLUDE any I2C devices that are being referenced by the XMOS toolchain that are NOT present in your design. The XMOS IP will retry up to 2,000 times before timeout and the symptoms you have posted are the side band effect for this phantom I2C hardware in the code.

@caleb - the XMOS clock operates @ +3v3 so 1v8 is not a suitable clock buffer for these XMOS CPUs - believe that only the XMOS ARM CPU was operating the clock @ +1v8 but going from (my fading) memory here.

Please post your update.

[genap]

The problem is not that crystal (24 MHz, and this is a crystal) changes frequency when touching, and so audio clocks.
The problem is that XMOS doesn't restore the audio clocks to initial values.
It seems that XMOS's PLL locks to the deviated frequency and doesn't lock to the restored original (proper) crystal frequency when the finger is released.
Here is the XMOS part of rhe design schematics.

J035_xmos.pdf

[mon2]

@caleb - my apologies, the applied CPU does indeed require a 1v8 swing clock source, if using an external oscillator. Crystal is a no care. Forgot about this variation of the CPU.

@genap - but does this widget lock up if the crystal is not touched? If the widget locks up if left alone but is streaming your audio then the fault is most likely elsewhere.

The XMOS CPU draw current varies with the IP you are running (# of cores that are active). Noting this, perhaps consider to beef up the applied inductors which are 700mA rated (as shown in the schematic). If using ferrite bead style, consider to test with true wire wound, shielded devices from Taiyo Yuden or similar @ 2A+ rated. FB versions derate quickly over load.

Does your design use the same ADC and other external hardware like the XMOS ref design? If not, the code must be reviewed to remove non-present devices else the I2C code will be retrying and this will break your USB IP.