iMX93 FIFO underruns when using SAI1 on M33 I'm using SAI1 to drive an external I2S device. 40MHz BCLK, 1.25MHz WCLK. Boot from Linux, code running on M33 via remoteproc. Getting FIFO underruns for the SAI1 interface. Can't figure out why? Did same code using SAI3 on M33 (A55 was held in uboot) and no problems. Any ideas? Thanks! Audio(PDM | I2S | SAI) Re: iMX93 FIFO underruns when using SAI1 on M33 Hello,
Unfortunately, we do not have examples in SDK to use CODECs in our SDK.
You could try to use the examples in SDK as reference and you can find in the next path:
mcuxsdk\examples\driver_examples\sai
If you see FIFO underrun warnings, could be caused by an empty TX FIFO because data is not being pushed fast enough or the transmitter is not properly enabled.
A reason that could be causing this issue is resource availability/configuration. First, I suggest you confirm that you do not have issues where the Cortex-A processor is not using the same resources from Cortex-M that could cause the issue.
Did you confirm that Transmitter Enable bit from SAI Transmit Control Register (TCSR) register is enable?
Best regards. Re: iMX93 FIFO underruns when using SAI1 on M33 I've moved the SAI1 code to the A55 under Linux. Still getting FIFO errors. Here are the details of the configuration and questions: Platform Board: i.MX93 EVK; /sys/devices/soc0/soc_id=i.MX93, /sys/devices/soc0/revision=1.1. Package marking/mask not yet recorded. Linux: 6.12.20-lts-next-gdfaf2136deb2, PREEMPT, A55. SAI1 at 0x443b0000, TX via 44000000.dma-controller-CH21. SAI1 serial root: 40 MHz from VIDEO_PLL; 40 MHz BCLK, 1.25 MHz frame rate. SAI3/WM8962 is Linux-owned and was idle for the reproductions below. LMX2571 I2S FSK sink: signed 16-bit code in active slot, zero in other slot. Constant code +8500 produces the expected +17 kHz RF offset. Minimal Linux reproduction (M33 remoteproc offline) Custom DTB exposes SAI1 as an ALSA playback device; SAI1 PCM card 0. Static ALSA PCM: hw:0,0, S16_LE, 2 channels, 1,250,000 frames/s; period 2,400 frames, buffer 19,200 frames. No Gaussian filter or other real-time waveform generation. TX FIFO depth 32 words, TX DMA burst 8 words, FIFO watermark 24. Static data: slot 0=8500, slot 1=0. Command: python3 /root/cp7g_static_playback.py --device hw:0,0 --seconds 600 Latest result: 750,000,000 frames written in 599.958 s, ALSA xruns=0. SAI1 FEF IRQ diagnostic: 1 episode, 9 IRQ entries over 2.685 ms. First observed at monotonic uptime about 675.892537 s, approximately 7.16 s before playback stopped; not an end-of-stream drain event. First-IRQ instrumentation (timings are after the hardware FEF assertion) TCSR=0x90150c01; consecutive time reads=41 ns; handler work before first TCSR read=209 ns; first TCSR regmap read=120,607 ns (return 0). FEF W1C regmap write=241,007 ns (return 0), before detailed snapshot. Post-ACK TFR0=0x00020001, read=242,799 ns. Post-ACK eDMA CH21 first raw register read=241,423 ns; total CH21 snapshot time=487,722 ns. CH_CSR=0x80000005, CH_ES=0x00000000, CH_INT=0x00000000, CH_SBR=0x00208003, CH_PRI=0x00000000. The TFR0 and CH21 values were sampled after the acknowledgment, not at initial FEF assertion. The long reads/writes cannot establish that they caused the initial FIFO error; CH_ES=0 only says no channel error was latched when sampled. The FEF is a hardware event despite ALSA xruns=0. Independent simplified firmware reproduction With Linux booted and ALSA capture idle, M33 code drove the same SAI1 TX using a single self-linked eDMA CH21 TCD, constant +8500 / zero slots, no major-loop callbacks, no foreground buffer refill, no Gaussian filter. At 40 MHz BCLK, FIFO depth 32, watermark 24, DMA minor loop 16 bytes, it stopped on SAI1 FEF after 216 s (Rev R). In the post-FEF fault snapshot, CH21_ES=0 and DMA global ES=0; the TCD was still self-linked. Similar faults occurred in later priority and internal-BCLK trials. A half-rate trial also failed. Thus neither Python nor M33 waveform computation/refill is necessary to reproduce the intermittent SAI1 FEF. Linux playback also fails with the M33 offline. Probe loading and external wire length changes did not remove the problem. Additional observation A burst-4 / watermark-28 Linux run had one FEF episode at uptime about 676.889 s on a separate boot; the latest burst-8 fault was at 675.893 s. A system journal search around 670–682 s in the latest boot found no logged activity. Similar uptime is suggestive only, not proof of a timer. Questions for NXP 1. Is there a known i.MX93 rev 1.1 mask erratum or low-power/interconnect condition that can delay SAI1 and eDMA CH21 register access and/or DMA service by 100–250 us while SAI1 TX and its clocks are enabled? 2. What hardware status, clock-gating, interconnect, or eDMA traces can identify the first missed SAI1 FIFO service request before FEF? 3. Does SAI1 TX FEF indicate any condition other than an actual FIFO underrun in this asynchronous master configuration? 4. Are there documented SAI1/eDMA burst, watermark, or clock constraints for continuous 40 MHz BCLK / 1.25 MHz stereo frame output on i.MX93? Can provide custom DTB, Linux fsl_sai.c/h changes and static playback script, M33 self-linked TCD source, full boot clock tree, and scope/RF data.
View full article
