I2S channel tag

[dieterteuchert]

When the Kinetis K10 receives a stereo audio data stream, i get each audio sample reading the receiver FIFO (using DMA). How can i know which audio sample was first in frame and which one was second in frame? Do they always load as pairs? I mean there should be a proven and reliable method to resolve this. Something similar happens with the transmitter: When i stream data into the transmitter FIFO, how can i know when to put the first word of a frame?

[dieterteuchert]

I have another one: When i try to connect both I2S0 transmitter FIFOs to DMA channels, i have a problem because in Table 3.18 on page 76 of my K10 reference manual there is only one I2S0 transmit request source to the DMA MUX. How can i properly feed both transmitter FIFOs channels?

[egoodii]

You can use the minor/major-loop counters & offset mechanisms of the DMA to 'split' those single TX (and RX) DMA requests into individual linear ping-pong buffers (as many as you like!).  However, this process relies on starting in sync and staying that way.  I am not aware of any potential mechanism within the I2S process to insure that you are 'still in sync' and still splitting the stream properly.

[dieterteuchert]

It has been 18 days without response, thanks anyway.

In the meantime we found a watchdog type solution for checking the phase of RX and TX FIFOs with respect to the LRCLK and the phase of each DMA with respect to the FIFOs. Turned out that all four mutual sources of error hardly ever cause trouble, even during debugging, and our resync procedure has not really been tested yet. I mean there are lots of MCUs running without any watchdog at all...

The Cortex M4 with its 32 x 32 MAC and the Kinetis TDM capable I2S make a nice machine for high end audio.

[egoodii]

Sorry for the delay -- I am only a casual browser to these forums.  I would be interested in some details on your sync-check operation.  I personally couldn't convince myself I could rely on an interrupt response time to a sufficient level to make any such condition-driven check meaningful for the 6 channels I was working with.  I have also found that 'no checking at all' has not caused me particular trouble, but I have a 'nagging concern' in two environments:  One is telephony, where timeslot-data-interchange is everywhere, and synchronous-behavior is subject to line errors.  The other is the PLL nature of some CoDecs (as the I2S clock master) where I have had designs using ceramic PLL filter caps with microphonics, and a mechanical hit (like a bump in the road!) would cause a 'hit' to the PLL and a full-fledged re-sync to the clocks therein.  It is potential conditions like this that worry me, not the normal 'all counters running nicely in sync'.