I'm using the SAI SDMA driver to continiously play audio. I've notices that sometimes the callback I've installed using SAI_TransferTxCreateHandleSDMA() is called much earlier compared to when I expected it to. I'm not seeing any fifo errors by when checking SAI_TxGetStatusFlag()
I'm calling SAI_TransferSendSDMA() directly from the callback to load the next buffer. Is this allowed? Could it be possible that the interrupt returns before the SDMA have written any a second dma request is issued?
I use i.MX8 M Mini, I run zephyr (so SDK 2.8) on the M4 core.
I have looked at the documentation for both sai, sai_sdma and sdma.
I use the sdma interrupt to trigger an audio framework to generate audio, so I need that interrupt to be deterministic and reliable with no underflows of the fifo.
looking at the sai sdma driver I see that it calls the sdma driver and disables the sdma channel in the irq callback. Why it does so would be interesting to know.
Please load the "FSL_SDMA_MULTI_FIFO_SCRIPT" script into the SDMA as follow:
#include "fsl_sdma_script.h"
const short g_sdma_multi_fifo_script[] = FSL_SDMA_MULTI_FIFO_SCRIPT;
...
(In main function)
...
SDMA_Init(EXAMPLE_DMA, &dmaConfig);
SDMA_CreateHandle(&dmaHandle, EXAMPLE_DMA, EXAMPLE_CHANNEL, &context);
SDMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_CHANNEL, 2);
SDMA_LoadScript(EXAMPLE_DMA, FSL_SDMA_SCRIPT_CODE_START_ADDR, (void *)g_sdma_multi_fifo_script,FSL_SDMA_SCRIPT_CODE_SIZE);
...
I'm only using one channel so the multififo script is not used.
I think I figured it out and the main issue was that I only call SAI_TransferSendSDMA() once and the rest from the callback. So there was always only one buffer in the bdpool. By disabling the interrupts and calling SAI_TransferSendSDMA() four times I fill it up before any interrupt is triggered and from there I always have it full.
Thank you for your help.
Which NXP device are you using? and which version of SDK are you trying?.
Let me share the documentation link
https://mcuxpresso.nxp.com/api_doc/dev/467/group__sai__sdma.html