I2S/TDM SLAVE not sync on WS (IDFGH-8003)

[CesareVin]

Environment

• Development Kit: ESP32-S3-DevKitC-1
• Kit version : v1
• IDF version : v5.0-dev-4001-g495d35949d & 4.4.1
• Build System: idf.py
• Compiler version : (crosstool-NG esp-2022r1-RC1) 11.2.0
• Operating System: Linux and macOS
• Using an IDE?: NO
• Power Supply: USB

Problem Description

If I2S/TDM is configured as Slave in full-duplex data played out is not correctly aligned on WS.
Sometimes first channel appear when WS is High, some times when WS is LOW.

Expected Behavior

I2S/TDM slave should recognize channel order and should output data accordingly WS Polarity.

Actual Behavior

• 1 esp32s3 is Master Clock and transmit data
• 1 esp32s3 is Slave Clock and receive data and transmit it back.

Both ESP send the same pattern that identify channels.
Frame 1

• CH1 : 0x1AAAAA{sample-id}
• CH2 : 0x1BBBBB{sample-id}
• CH3 : 0x1CCCCC{sample-id}
• CH4 : 0x1DDDDD{sample-id}
  Frame 2
• CH1 : 0x2AAAAA{sample-id}
• CH2 : 0x2BBBBB{sample-id}
• CH3 : 0x2CCCCC{sample-id}
• CH4 : 0x2DDDDD{sample-id}

ES:
0x1AAAAA01
0x1BBBBB01
0x1CCCCC01
0x1DDDDD01
0x2AAAAA00
0x2BBBBB00
0x2CCCCC00
0x2DDDDD00

Master and Slave esp are both configured in the same standard I2S_TDM_PHILIP.

• As you can se from the image below, data is correctly placed on low WS and respect the configuration

• As you can se from the image below, data placed on high WS and not respect the configuration.

This happen only rebooting the slave.
No overflow are in evidence ( we monitor and print it )

We also monitor interrupt from DMA sent and DMA rec.
These interrupt seem to be not synchronized and the distance between these interrupt differ from different power cycle.
We notice that when this distance is less then X is when the system work properly.

We wait for updated esp32-s3_technical_reference_manual_en for a while.
Now finally v0.8 is released and we have full documentation for I2S.
On page 742 you mention that peripheral can work simultaneously and independently but seem that there is no way to start tx and rx exactly at the same time that could be the root cause of the problem.

Tried also to start peripheral manually to reduce this latency but no way.

I2S0.rx_conf.rx_start = 1;
I2S0.tx_conf.tx_start = 1;

Also resetting hw fifo, restarting gdma channel. No way.

It seem that Slave a full duplex slave mode is not supported.

We have also a lot of doubt about I2S clocking.
In esp32s3 and esp32c3 you provide a MCLK in but common and standard audio clock like 24.576 MHz are not supported because I2S_RX/TX_CLOK in slave mode must be 8 >= bit clock and this kind of master clock never exist in audio application.

I also would like to put in evidence that driver only support 160 MHz clock and that i2s_struct.h mention APLL that is not supported.

uint32_t rx_clk_sel : 2; /*Select I2S Rx module source clock. 0: no clock. 1: APLL. 2: CLK160. 3: I2S_MCLK_in.*/

We Also tried to use PLL_D2_CLOCK ( 240 MHz ) as source with this clock division coeff :

a : 64 
b : 61 
N : 1 
out freq 122880000.000000
tx_clkm_div_x : 0014 
tx_clkm_div_y : 0001 
tx_clkm_div_z : 0003 
tx_clkm_div_yn1 : 0001 

and a MI/MO equal to 10 for bit clock division but without good result.

What we are doing wrong ?
How to allow this peripheral to work properly in a low latency ( 1 ms ) full-duplex i2s slave application ?

Thank you in advance.

Steps to reproduce

1. Download the attached project
2. Connect master and slave following pinout described in project README
3. Monitor data output from slave esp32s3

Code to reproduce this issue

tdm_test_idf5.zip

[L-KAYA]

Thank you so much for providing such a detailed investigation! And sorry for the asynchronization in the slave duplex TDM mode.

According to your discription, I suspect that the issue could be caused by the different clock domains of TX and RX channels, because unlike the former chips, the I2S on ESP32-C3 and ESP32-S3 has separate clock domain for the TX and RX channels, which can support TX and RX working at different clock but can also lead to the asynchronization.

In master duplex mode, we select the 160m PLL clock for TX channel and share the clock to RX channel by setting the bit sig_loopback, actually in the master case, only TX channel is a really master channel who generates the clocks, but the RX channel is forced to act as slave role to sync the clock to the TX channel.

But in slave duplex mode, both TX and RX channel will not generate the clocks, I don't know if the sig_loopback field still take effect. Or, maybe we have to disable the sig_loopback in this case. Currently I can hardly to tell if it is a hardware issue or a bug in the driver, I'll look into it.

If you want to try by yourself, here are two suggestions might work:

• Try to disable sig_loopback for slave duplex mode
• Try to select mclk_in as the clock source for both TX and RX channel, then input the mclk from master. But since the driver doesn't support inputting the mclk signal now, you may have to calculate the clock divisions by yourself to get the correct BCLK and WS signal.

And as for the clock source, ESP32-C3 and ESP32-S3 do not support APLL, it's a mistake while generating the i2s_struct.h , please take the Technical Reference Manual for the final reference. And it's indeed a hardware limitation that the master clock has to be at least 8 times to the bclk on ESP32, but not sure if it still exists on C3/S3, if the limitation has gone, I'll fix it.

[L-KAYA]

Further investigation shows that the asynchronization is related to the high sample rate. When the sample rate is high(like 96KHz), we must guarantee the internal mclk frequency of slave should be more than 8 times to the bclk. But currently it is fixed to 8 in the driver, will make it changeable in the next bugfix.

FYI, 48KHz sample rate has no such issue. You can lower down the sample rate if 96KHz is not necessary.