[BUG] I2S / DMA FIFO is spilling data in the buffer causing channel offsetting

[carlocaione]

The setup

Using the EVK MIMXRT685 as I2S SLAVE configured as:

• TDM / DSP mode A (mono)
• 48kHz (SCK at ~25MHz)
• 16 slots (channels) per frame
• 512 SCK per frame
• 32 SCK per slot
• 32 bits of audio data per slot, left aligned
• WS pulsed for one SCK time
• Data sampled on WS rising edge

The following is a sample trace:

The problem

I'm interested in the RX path, that is using the EVK to record data received on the I2S interface sent for example by a PC. For the sake of simplicity let's assume that from the PC I'm streaming data only of the first channel out of 16.

We can do that by doing for example on a Linux machine:

speaker-test -r 48000 -c 16 -f 1000 -F S32_LE -D hw:APE,1 -t sine -s 1

With this command we are sending through the I2S interface a stream of data at 48kHz / 16 channels / S32_LE with a 1kHz sine wave only on the first channel, all the other channels are silent.

We try to send this data through several times, but instead of waiting for the stream to finish, we interrupt the streaming several times by pressing CTRL+C and giving the command again. This is possibly interrupting the stream of data mid-frame and restarting it from scratch.

What do we expect to see on the EVK side

We would expect to see in the I2S RX buffer something like this when the command is running (each 0 and X is 1 byte):

CH1  CH2  CH3  CH4  CH5  CH6  CH7  CH8  CH9  CH10 CH11 CH12 CH13 CH14 CH15 CH16 CH1  CH2  CH3...
XXXX 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 XXXX 0000 0000...

That is we expect to see data only on the Channel 1 and zeros on all the other channels when the command is streaming out data.

What we actually see on the EVK side

What actually happens is that the data is found on a different channel than 1. An offset is introduced in the recorded data.

For example:

CH1  CH2  CH3  CH4  CH5  CH6  CH7  CH8  CH9  CH10 CH11 CH12 CH13 CH14 CH15 CH16 CH1  CH2  CH3...
0000 0000 0000 0000 0000 0000 XXXX 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000...

In this case the data that is supposed to be on CH1, it is found on CH7 instead.

The reproducer

At https://gist.github.com/carlocaione/5c471fd25f083110e6c9f3c426874f29 the reproducer for the problem.

Since we need 16 channels we are using two FLEXCOMM interfaces with signal sharing and we use a ping-pong linked transfer onto two different buffers.

If we set a breakpoint at line 80 and we try to reproduce the issue, we can see that the execution stops at that line after a few attempts because valid data was found in channel 7 instead than channel 1.

A theory about the issue

What is possibly happening is that when we stop the streaming of data in the middle of the frame, the data in the FIFO up to that point is still flushed in memory, causing the offset when the streaming starts again at a later time.

Position in the RX buffer: CH1  CH2  CH3  CH4  CH5  CH6  CH7  CH8  CH9  CH10 CH11 CH12 CH13 CH14 CH15 CH16
Data transmitted         : XXXX 0000 0000 0000 0000 0000 XXXX 0000 0000 0000 0000 0000 0000 0000 0000 0000 
                          ^                             ^
                          RX is started                 Here we stop the streaming and start it again

Open questions

A reasonable expectation to me about the behaviour of I2S + DMA is that when the data is flushed to memory, this is done in chunks that are multiple of the size of the frame (64 bytes in this case) otherwise how can we detect when only part of the frame has been flushed to memory especially when using loop descriptors?