K70 Audio SAI I2S DMA

[pbanta]

I have a K70-based project with the SGTL5000.  The project is running MQX4.1.  WAV files are stored on an eMMC and played on command from a user interface.  The code was lifted from the audio demo code for the TWR-AUDIO-SGTL module.  Most of the time the audio plays with no problem.  But sometimes the K70 stops and a small buffer of audio data repeats forever.  Sometimes CW10.6/PEMicro Multilink FX can catch it.  Most of the time I can pause CW and look at the task info.  I have noticed that my audio task is always stuck in an ioctl() call into the sai dma driver (sai_dma_dsai.c) and it's blocked waiting on an empty buffer semaphore that is supposed to be posted from the ISR.

case IO_IOCTL_I2S_WAIT_TX_EVENT:
            _lwsem_wait(&stats->BUFFER_EMPTY);
            break;

Is it possible for this driver to miss an interrupt?

I suspect a race condition somewhere because I have seen the system play the same file 300 times with no problem with the following sequence:

1. open file

2. open sai:

3 play file

4 close file

5 close sai:

Then I stopped CW and downloaded the same firmware and started again and the the file plays a random number of times before the system hangs.

Any ideas?

Thanks,

[pbanta]

I found more information regarding this issue.  My project contains an RTCS httpsrv web server.  When audio is playing and httpsrv is running an http session task there is a possibility that upon task exit the http session task will crash.  The stack trace looks like this:

This crash only happens when audio is playing.  The only correlation that I see is that the sai dma driver is using an lwsem in the ISR to signal that audio task that an empty buffer is ready.  I notice that as the httpsrv session task is exiting there is a call to _lwsem_post().

[isaacavila]

Hello Pbanta,

Your problem could be related to memory corruption but it is hard to identify the reason of it, more information from TAD like task's status, socket and stack information could be helpful. (Even if we could reproduce this issue on our side it would be better but do not know if specific setup is needed).

Also, I can recommend you to use MQX 4.2 due RTCS and SAI driver are more stable in this newest release. (SAI driver is quite different in MQX 4.2 in comparison with MQX 4.1 but looks more stable), however, if migrating this project to newest release is complicated, we can give a look to your current project.

Regards,

Isaac

[pbanta]

Hi Isaac,

Thank you for the reply.  Moving to MQX 4.2 is something I have considered, but this issue was discovered late in the product cycle.  There has been a lot of testing and burn-in on MQX 4.1 and all of that would have to be started from the beginning.

I have new information regarding the issue.  I forgot to mention in the original post that the board has DDR on it and the project is linked such that MQX uses DDR instead of SRAM.  I wondered it there was an issue with SAI DMA and DDR timing.  As an experiment, I modified the SAI driver to allocate buffers from the SRAM pool instead of the DDR pool.  The reliability of the system improved dramatically.  I was able to play audio in a loop continuously for 12 hours.  During the 12 hour test I ran a shell script that requested a CGI function in a loop.  This script had no delay, just an infinite loop calling wget.

I have not observed any crash if I start the audio output and then start the wget script.  However, if I change the order and start the wget script first and then audio output. I have observed a crash, but only once.  Very hard to reproduce.

[isaacavila]

Hello Pbanta,

I do not know if issues on SAI + DMA are presented when using DDR configuration (although they seem to be there, similar case occurs in USB when using DDR configuration instead of SRAM, communication's throughput gets impacted), but it can explain your behavior when using DDR.

I would suggest to use SRAM configuration instead of DDR and if problem persist, we can investigate it further.

Regards,

Isaac