iMX93 FIFO underruns when using SAI1 on M33

wirelessguy — Tue, 29 Sep 2026 22:41:37 GMT

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!

Re: iMX93 FIFO underruns when using SAI1 on M33

JorgeCas — Wed, 30 Sep 2026 20:46:32 GMT

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

wirelessguy — Thu, 01 Oct 2026 16:24:20 GMT

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.

topic Re: iMX93 FIFO underruns when using SAI1 on M33 in MCX Microcontrollers

iMX93 FIFO underruns when using SAI1 on M33

Re: iMX93 FIFO underruns when using SAI1 on M33

Re: iMX93 FIFO underruns when using SAI1 on M33