No USB TDM audio on 2 out of 3 prototype boards

[klebb]

I have received three prototype boards for a new product from our manufacturer which contain an XMOS XU212-256-TQ128 device to serve as a USB audio port, connecting to an FPGA on the same board via a TDM interface. The XMOS device is configured with a Master mode sw_usb_audio application, defined by (in the Makefile):

INCLUDE_ONLY_IN_2AMi16o16mxxxxx_tdm8 =
XCC_FLAGS_2AMi16o16mxxxxx_tdm8 = $(BUILD_FLAGS) -DI2S_CHANS_ADC=16
-DI2S_CHANS_DAC=16
-DXUA_PCM_FORMAT=XUA_PCM_FORMAT_TDM
-DMAX_FREQ=96000
-DI2S_CHANS_PER_FRAME=8

My test set-up comprises a Windows PC installed with a Thesycon driver connected via USB cable to the prototype board. This arrangement works perfectly on the first board I brought up, providing 16 channels of audio on two TDM8 lanes to the FPGA, which I can monitor using Altera's SigTap tool, in addition to passing the audio through to a DAC and a headphone output.

However, for the other two boards, Windows settings indicates that the XMOS device is found and connected, and the info panel associated with the driver indicates the correct settings as defined in the app's Makefile and xua_conf.h file (no. of channels, VID, PID, custom text strings, etc.), but when a media app (eg Spotify) attempts to play audio, none is propagated and, in the specific case of Spotify, a 'Can't play the current song.' notification is briefly displayed. Monitoring the TDM bus with SigTap (clocked by the BCLK output from the XMOS IC), I can see that the LRCLK output briefly disappears whenever I attempt to play audio on Spotify, and returns a few seconds later (a single pulse for every 256 BCLK cycles), coincident with the Spotify notification, but both TDM lanes are permanently at logic '0'.

The fact that the problem occurs on just two of the three boards would obviously suggest a manufacturing fault, but I have checked/tried the following and not discovered anything amiss:

• Power rails: the XMOS IC is powered by +3V3 for all VDDIO, VDDIOT, OTP_VCC and USB_VD33 power pins and by +1V0 for all VDD pins plus USB_VDD and PLL_AVDD (which is filtered by the recommended 4R7/100n combination). All power pins are decoupled with co-located 100n capacitors and an additional 10u bulk decoupling capacitor is used for each rail. The rails appear stable, within tolerance and noise/jitter free when monitored with a 'scope, and connection to each power pin has been verified.
• Power sequencing: a power sequencing device is used which ensures that the +1V0 rail rises about 20ms after the +3V3 rail - this has been verified through measurement.
• Resets: RST_N and TRST_N are tied together and are driven by diode OR'd combination of a POR# signal (generated by the power sequencer device about 200ms after all rails are stable) and the XSYS_RST# provided by the xTAG board. I have tried manually resetting during operation - no change in behaviour.
• Clocks: The 'CLK' input (pin 125) is driven by 24MHz, and the MCLK clock (delivered via pins X0D13 and X1D35) is 24.576/22.5792 (depending on the state of FSEL). Both clocks are generated by the same PLL device (a Microchip PL611 IC) and are measured to be with 15ppm. I have also tried pulling the frequency in both directions by up to about 20ppm - no change in behaviour.
• XMOS IC condition: I have replaced the XMOS IC on both boards - no change.
• XMOS app: I have tried configuring (both through xrun and xflash) with other apps, eg 1AMi2o2xxxxxx, the simplest possible I2S configuration - again, LRCLK present, but no audio.

I am thinking that perhaps there is some aspect of my design (either h/w or s/w) which is marginal and could account for the fact that one board works and the other two don't - does this seem likely? Is there a way that this possibility could be explored using xscope or xdbg (or something else)? Alternatively, is the behaviour I have described a common occurrence with an established cause?

[Joe]

I'd start by running xrun --dumpstate <binary_name.xe>.

Symptoms sound like there's a missing clock somewhere or similar so blocking flow of data.

[Ross]

Which sw_usb_audio version are you using and what version of the deps are you using (if you use the cmake based build system you will get a handy manifest.txt output)

Any access to a USB analyser at all?

[Ross]

for Joe's experiment, clear the flash (--erase-all) and run from xrun. Removes the risk of any power related reboot booting program stored in flash and maybe adding some confusion. I'd start with a lower channel count i2s config.

[klebb]

Hi Joe, Ross,

Thank you for your replies.

Firstly, concerning Joe's experiment, I tried erasing the flash with 'xflash --erase-all' but I get:

Error: F03022 A --target or --target-file option is required.

I've tried adding the --target option with various guesses (eg '0' and '1') as a parameter, but without success. I don't understand why I have to specify the target device when attempting to erase it, yet I don't have when I configure it with an executable file. What am I missing here?

Secondly, the version of sw_usb_audio I'm using is 7.2.0, which is the version you (Ross) advised me to upgrade to two years ago when helping me with ticket #216438 'TDM16 looped back audio distorted'. As you'll note if you recall this ticket, there were a couple of modifications you asked me to make to his version in order to address my TDM16 related issue (which I'm no longer persuing, after selecting a bigger target device for our current product), and I haven't upgraded since then. Is it worth upgrading to a later version of software?

Thirdly, no I don't have access to a USB Analyser, but could look into the possibility of hiring one if necessary.

[Joe]

Hi,

--target-file=<xn_file.xn>

xflash needs to know where the flash is connected on the target device. This info is contained in the XE file when programming.

I'll let Ross answer but I would suggest it's always advisable to be using the latest version of the sw_usb_audio codebase.

If you want a simple sanity check of usb operation, I've included a binary which should enumerate as a mouse and move the cursor around.

app_hid_mouse_demo_200.xe

Cheers,
Joe

[Ross]

I'd use the latest (v9 currently) there are quite number of improvements including a new DFU scheme, improved S/PDIF receiver, support for new build system, quite a few bug fixes etc

[klebb]

Thanks, Joe - I've succeeded in erasing the flash and executing my app from xrun - no change in behaviour.

I've also tried your USB sanity app - that works, causing the mouse arrow to rapidly follow the corners of a tightly defined square.

I'll try upgrading the software next...

[Joe]

That would align with the theory of a missing clock or different signal on the non working boards. The HID mouse demo doesn't need any external signals.