I2S/TDM Library WS/Frame Sync Clock Inconsistent Topic is solved

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
rgilio
Active Member
Posts: 33
Joined: Wed Jul 03, 2019 1:01 am

I2S/TDM Library WS/Frame Sync Clock Inconsistent

Postby rgilio » Fri Aug 02, 2019 7:08 pm

I'm connected to an external TDM microphone and interfacing with it using the I2S/TDM library.

I'm currently getting a readout of 19-24 kHz for the WS line when my MCLK and BCLK are clocked in at ~11.289MHz. I would expect to be seeing a 44.1kHz readout from the WS line and for the signal to be more consistent. I'm having trouble figuring out what would be causing this behavior.

Here's two pictures of the SDA_in line and the WS clock readouts I'm getting on my analyzer: WS and SDA readout. One image has the frame_sync set to be 32, the other to be 1.

It also looks like the SDA line sometimes sends data before the WS line gets driven high. I'm guessing this is also due to the inconsistent timing the WS is currently showing.
Since the WS line is driven by the TDM library I'm not sure how I'd go about adjusting it since I shouldn't need to modify it as I'd expect to get unintended behaviors. Is it possible the CS2100 clock is having issues causing this inconsistency or does this imply the external mic has issues since it's sending data before it receives the WS line? Also, how exactly do I configure the TDM library's sample rate, only thing I can think of is making sure the
BCLK is set to be at whatever target frequency I want and the fsync will auto be configured by the TDM library?
View Solution
User avatar
mon2
XCore Legend
Posts: 1518
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Sat Aug 03, 2019 5:15 pm

I think your source clock is too low for the 44.1khz requirement. Can you double the clock to 22.5792Mhz and test again? That is what the XHRA-2HPA reference design used.
User avatar
akp
Respected Member
Posts: 314
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Tue Aug 06, 2019 4:07 pm

How many TDM channels are you using? If you are running master then there might be an issue with backpressure on your calls (i.e. the tdm receive calls). The TDM code actually has to reload the FSYNC IO buffer at 44.1 kHz so if something is taking too long that could be a problem.

11.289 MHz BCLK / 256 = 44.1kHz FSYNC if you have 8ch / TDM lane @ 32 bit / ch so it seems like it should be OK. Make sure your BCLK is good, that's the actually clock that runs the FSYNC.
rgilio
Active Member
Posts: 33
Joined: Wed Jul 03, 2019 1:01 am

Postby rgilio » Wed Aug 07, 2019 1:18 am

I doubled the MCLK rate but that didn't fix the issue. However, I did fix my issue by removing one print statement that I had in the tdm_process. It looks like it was blocking the tdm_library and causing issues with the FSYNC port.

Dumb mistake on my end, but for anyone else having issues with their clocks, double check that you're not blocking your libs with any printing on the same core.
User avatar
mon2
XCore Legend
Posts: 1518
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Wed Aug 07, 2019 3:34 am


Who is online

Users browsing this forum: No registered users and 1 guest