DMA configured for I2S getting halt sometimes for K70

[deepakbhagat]

I have used DMA0 for I2S data transfer from K70 with SGTL5000. I have implemented ping pong buffer for data transfer through i2s as mention in application note by freescale AN4369.

I have notice that DMA stop generating interrupt thus there is no sound from the SGTL5000 codec.

In isr I am switching the buffer addresses.

I am unable to find out the reason for interrupt not getting triggered after the major loop is over.

The code is working fine but once in a while we are facing the above issue.

Please help me out regarding what might be the root cause of interrupt not getting generated.

I have attach the DMA init function, please let me know what may be the possible reason of DMA getting hanged.

Original Attachment has been moved to: dma_init.txt.zip

[likong]

Hi,

Are you sure this is the issue of DMA? As you are using clk from K70, if SAI do not consume data, there is of course no interrupt generated from dma.

I suggest you to test if SAI is working normally, to see if all mclk, bclk and frame sync is working while no sound.

[egoodii]

Personally, I would strongly avoid attempting 'real time' modification of DMA registers 'on the fly'.  Use one double-sized buffer and the half-interrupt to treat them as your ping-pong buffers.  And if you need to multiplex multi-channel audio, let the DMA do that too!

[jeremyzhou]

Hi Deekparkhagat,

I've review your SR question. Could you tell me what's the configuration of the CR[EDBG] bit?

Since the DMA operation is configurable in debug mode via the bit.

Best regards,

Ping

[deepakbhagat]

I have set the DMA_CR.EDBG bit to 1.

[jeremyzhou]

Hi Deekparkhagat,

Regarding the CR[EDBG], you could that the eDMA will stops transferring data if CR[EDBG] is set.

So I think it may be the reason of your project didn't work properly.

Wish my support help.

Best regards,

Ping

[deepakbhagat]

Thank you for the help, but just want to inform you that even when I am not debuging the code is working fine and i can hear the sound from the codec. Once in a while the sound stops but the other task are unaffected and keeps on working. So can you help me to understand in what area I need to check for the no sound from codec. During the debug we found that DMA interrupt was halted.

Regards,

Deepak Bhagat.

[jeremyzhou]

Hi Deekparkhagat,

I've had a brief look through your attachment and it looks fine. I guess this issue may be caused by a conflict between fill the Ping-Pong buffer and DMA transter. Suppose a Ping-Pong buffer is loaded with the new aduio samples now, while DMA also start to

transfer the aduio samples to Audio output peripheral from the Ping-Pong buffer. I'll still looking into it.

I'm looking forward your reply.

Best regards,

Ping

[deepakbhagat]

Thank You Ping,

     In my task I have kept the flags that won't allow the DMA to access the buffer that CPU is using and vice versa.

In our application we are running the code from external DDR and my sound generation task is also working from external DDR. The ping pong buffer were stored in internal RAM. Is it possible to store some part of sound generation task function in internal RAM and some part in external ram.

I have one code for sound generation that is running from internal memory as that code size is less with minimum functionality and it is not having DMA issue up till now. is it so that code storage may cause the DMA issue?

I have kept the sound generation code running from internal memory for testing.

[jeremyzhou]

Hi Deekparkhagat,

Thanks for your reply. Regarding to the situation of store some part of sound generation task function in internal RAM and some part in external ram, I think it's possible to cause the DMA issue if the address is not configured correctly. So it's wise to keep the sound generation codde running from internal memory for testing.

I'm also lookinf forward to your news!

Best regards,

Ping

[deepakbhagat]

Hi Ping,

     Just to inform you that, I have kept the ping pong buffer and flags related to DMA in internal RAM. Its working fine at the moment and will keep on updating you as the device is in testing phase.

Thanks for the al the help.

Regards,

Deepak Bhagat.

[egoodii]

And I will submit an opinion that it is the 'on the fly' alteration of DMA registers 'while it is using them' that occasionally causes a conflict that shuts down the DMA engine.  I don't know why AN4369 talks about 'ping pong' using the half-interrupt, and then doesn't implement it that way.  Another way would be to chain two DMA descriptors, each set up to handle one of your buffers, and point them at each other.  You might find some inspiration in this thread:

is there any demo code for using I2S?

[deepakbhagat]

Thanks Earl,

     I will try out the things mentioned by you.

Other issue tha we are facing ->

We have interfaced SGTL5000 with K70 for our medical product. We found during testing the SGTL5000 is getting reset. So how can we K70 come to know that the SGTL 5000 has reset as there is no external reset for SGTL5000.

As in our product we are initializing the codec only once in start and then there is only I2S communication going on there after.

Can you please suggest the way that the reset condition of SGTL5000 can be detected by the K70 controller?

This issue has made the sound generation task on hold and thus delaying the product release.

Regards,

Deepak Bhagat.

[egoodii]

I am not directly familiar with the SGTL5000 part but...

What MCLK do you run-in?  Do you use the SGTL5000 PLL?  Is the SGTL5000 the I2S bus master?

What particular 'symptom' gives you the impression that the SGTL5000 has undergone an internal 'reset'?  I will assume you've 'ruled out' power supply glitches and noise as the source...

[deepakbhagat]

Thanks Earl,

     I am working on the same ping-pong buffer issue and modifying the code according for our need.

Mclk is 6144000Hz

I am not using SGTL PLL while SGTL5000 is in slave mode. all the clk are generated from K70.

We could not debug the code for the exact reason as it was reported by customer that EMC and ESD testing the Sound got turn off while all the other task were working fine according to customer obervations. So just wanted info about how to detect SGTL reset so that even though the reset happens but still it could be found out and re-intailized.

[egoodii]

OK.  So where does this 6.144MHz come from?  The I2S rate MUST be an EXACT division from that clock.  You might have better luck making the SGTL the I2S master, and Kinetis the slave.

So you are looking for 'random' resets from ESD.  I can only assume there is 'some' register you set over I2C (SPI?) that you could 'read' every now and then and if that has returned to some 'reset default' you can assume things are 'hosed' and reinitialize your entire audio subsystem.

[deepakbhagat]

Thanks for the reply.

     I have generated Mclk BitClk and Fs from controller and its working on exact frequency.

I have one more query regarding running of code-

In our application we are running the code from external DDR and my sound generation task is also working from external DDR. The ping pong buffer were stored in internal RAM. Is it possible to store some part of sound generation task function in internal RAM and some part in external ram.

I have one code for sound generation that is running from internal memory as that code size is less with minimum functionality and it is not having DMA issue. is it so that code storage may cause the DMA issue?

[egoodii]

I'm not sure what you mean by 'controller'.  I will just state that while the Kinetis has the ability to 'divide down' an MCLK, in my experience said division did NOT create a continuous square wave suitable for Sigma-Delta CoDec sampling, which MUST be VERY jitter-free.  Sure, it was the right frequency, but...see this article:

http://www.edn.com/design/analog/4397389/Analyzing-audio-DAC-jitter-sensitivity

As for the DDR question, I haven't yet used such memory on Kinetis, so I can't speak directly to any considerations thereof, except a 'general note' from experience with complicated memory systems on uCs -- I would NOT be surprised to hear of 'rare' interactions, not properly handled in hardware (arbiters, pagemode interaction, etc.).

[deepakbhagat]

Hi Earl,

     Just to inform you that, I have kept the ping pong buffer and flags related to DMA in internal RAM. Its working fine at the moment and will keep on updating you as the device is in testing phase.

Thanks for all the help.

Regards,

Deepak Bhagat.