i.MX6S ESAI TDM slot problem

[Aemj]

Dear team,

My customer is facing the issue around i.MX6 ESAI TDM data transfer.

Please find the attached file for the details.

The issue is that TDM slot data could be misaligned when bit clock is higher than 20.8MHz.

In my understanding, the bit clock of i.MX6S ESAI can be up to 33MHz.

Is it true?

The customer has a doubt whether ESAI can work fine in such situation(bit clock>20.8MHz, 8slot TDM).

Once i posted same question to TIC and the answer was that it may be caused by silicon erratum ERR008000.

Is it sure?

[andreasri]

Hi, Fabio, 

thanks for your response. 

For your Information, we are using iMx6Q.

When we set the ahb_clk_root to a higher frequency (176MHz) the tdm output works synchronous to the Frame Sync also at 96khz and Bitlcock at 24,576 MHz. In normal operation without changing the ahb_clk_root, the tdm output is not synchronous to Framesync and has several dropouts, as you can see in the attached screenshots.

Framesync 96 khz, Bitclock 24,576 MHz, ahb_clk_root 132 MHz, tdm out not synchronous

Framesync 84 khz, Bitclock 21,504 MHz, ahb_clk_root 132 MHz, tdm out synchronous and working

Framesync 96 khz, Bitclock 24,576 MHz, ahb_clk_root 176 MHz, tdm out synchronous and working

It seems that the tdm_out(TX0) gets not enough data in normal operation and 96khz. Maybe one clock in the ESAI interface is not fast enough for external Bitclock with 24,756 MHz? 

We know overclocking the AHB_clk_root is not a solution just a way the identify the problem.

Thanks for your response!

Best Regards

Andreas

[fabio_estevam]

Hi Andreas,

Which Linux kernel version are you using?

Regards,

Fabio Estevam

[andreasri]

Hi,

we are using mainline kernel 4.1.5 with RT-patch, several patches for our board

and patches from the freescale kernel:

0001-ASoC-fsl-Add-dedicated-DMA-buffer-size-for-each-cpu-.patch

0002-MLK-11179-ASoC-fsl-implement-specify-audio-DMA-buffe.patch

0003-MLK-11429-4-ASoC-fsl_esai-add-spba-clock-support.patch

0004-MLK-11429-9-ASoC-fsl-implement-the-ESAI-xrun-handler.patch

0005-MLK-11429-12-ASoC-fsl_esai-Add-driver-suspend-and-re.patch

0006-MLK-9760-ASoC-fsl_esai-fix-NULL-pointer-issue-in-res.patch

0007-MLK-9782-ASoC-fsl_esai-fix-the-channel-swap-issue-in.patch

0008-ASoC-fsl_esai-Add-driver-suspend-and-resume-to-suppo.patch

0009-ASoC-fsl_esai-ETDR-and-TX0-5-registers-are-non-volat.patch

0010-MLK-11915-06-ASoC-fsl_esai-fix-missing-break-in-swit.patch

0011-MLK-11948-ASoC-fsl_esai-fix-the-channel-swap-issue-a.patch

0012-MLK-11429-8-ASoC-dmaengine-Add-two-function-for-dmae.patch

Regards 

Andreas

[fabio_estevam]

Also, can you try passing fsl,esai-synchronous in the device tree?

[andreasri]

Hi Fabio,

we passed fsl,esai-synchronous in the device tree, it made no change to the tdm output.

It would be great to get a solution for this problem.

Thanks for your response

Regards

Andreas

[andreasri]

Did your costomer find a solution for this issue? We are having the same problem at the moment with 96k framesync and 24,576 Mhz bitlcock. Setting the ahb_clk_root makes the tdm output working as expected. 

Best Regards

Andreas

[fabio_estevam]

Hi Andreas,

Could you please clarify what you mean by "Setting the ahb_clk_root makes the tdm output working as expected"?

Thanks

[art · Accepted solution]

Yes, the most likely cause of the issue is the effect of the ERR008000 silicon erratum, caused by data underrun/overrun.

Have a great day,
Artur

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Aemj]

Dear Artur,

Sorry for my late response.

My customer wants to be sure that the phenomenon is caused by ERR008000.

Could you provide the detailed mechanism of the ERR008000 malfunction?

BR,

Miyamoto

[art]

There are two possible cases - overrun and underrun.

1. In case of underrun (transmit FIFO empty), the transmission logic of ESAI still continues running, sending an empty slots. When next portion of data comes to transmit FIFO, the ESAI logic takes first available data for first available time slot, that might be not the one the first available data is dedicated to. After that, the following data will be transmitted in wrong time slots, that is equal to channel swapping.

2. In case of overrun (receive FIFO overflow), the next receiving data cannot be placed to FIFO and just become lost. When software reads and empties the receive FIFO, the next receiving data will be immediately placed to FIFO regardless of the time slot order. After that, the receiving data will be read from FIFO in wrong order, that is equal to channel swapping.

Best Regards,

Artur

[Aemj]

Hi team,

If the issue is caused by ERR008000, underrun/overrun is supposed to occur on their board. But the customer did not see the underrun/overrun exception occurred.

Is it possible?

I mean the handler for overrun/underrun exception could not capture the overrun/underrun event.

Is it possible that the handler for overrun/underrun exception could not capture the overrun/underrun event in the situation that ERR008000 occurs?

BR,

Miyamoto

[art]

Are these interrupts enabled in the ESAI module? Please ask them to check.

Best Regards,

Artur

[Aemj]

Dear Artur,

The customer confirmed that those interrupts are enabled in his software.

Because of that, he doubts whether ERR008000 causes this issue.

BR,

Miyamoto

[aurelienbouin]

Hello,

If I am right ESAI underrun and overrun are not handled ...

I don't see anywhere set the bit TEIE of TCR or the REIE of RCR

What is the kernel to use to get the ESAI driver working ... with the chip errata ERR008000 handled ...

Thank you

Sincerely,

Aurelien BOUIN

[sinanakman]

Hi Aurelien, if I remember correctly that errata suggests that

in case of underrun or overrun a reset is the work around.

When you say "with the chip errata ERR008000 handled"

do you expect something other than a reset ?

Regards

Sinan Akman

[aurelienbouin]

Hi Sinan,

Non I don't expect more than ESAI reset if it takes not too much time ...

But actually it is not handled at all ! I have not seen any reset ...

have you tried on your application to consume cpu and see if there is swaping ?

My test was just to do :

while true; do true; done

Regards,

Aurelien BOUIN

[Aemj]

Hi Aurelien,

You are saying about LinuxBSP, right?

The customer does not use Linux for their product, it is iTron base.

Tnanks,

Miyamoto

[sergioliberman-]

Hello Miyamoto,

Here in the USA, we are in the Thanksgiving holiday. Most people will return to work on Monday, December 1st.

I am jumping into this discussion quite late, and I would like some more information from the customer:

1) When they tried to invert the polarity of the clocks, did they invert the polarity of the serial bit clock and the Frame Sync in relation to each other? I mean, invert the polarity of one of them at a time, not both together.

2) What are the measured setup and hold timings for the serial bit clock , Frame Sync clock, and the data? It is not sufficient to operate the serial bit clock at up to 33MHz, all the datasheet setup and hold timings as well as the timing relationships between serial bit clock, Frame Sync clock and data line as shown in the datasheet must be obeyed.

3) Is it possible for the customer to try an experiment, and define the Frame Sync clock in the ESAI to transition one bit earlier? The reason is to find out if there is a clock timing relationship issue between serial bit clock and Frame Sync clock in this particular system.

Best regards,

Sergio

[Aemj]

Hi Sergio,

Welcome to our discussion.

I will ask the customer about the information.

2) As for bit clock, the customer already measured the waveform.

Please find the attached file.

BR,

Miyamoto

[Aemj]

Dear Sergio,

I checked with the customer and the followings are the answer.

1) The customer already tested changing the polarity of bit clock and the result was the same.

2) Do you mean that the timing change is made by setting RFSR bit in ESAI_RCR register into 1?

If so, they tested it and the result was the same.

BR,

Miyamoto