topic Re: [MCXN947] SAI_RxSetConfig() clears RCR4.FCOMB for multi-channel RX — bug confirmation request in MCX Microcontrollers

[MCXN947] SAI_RxSetConfig() clears RCR4.FCOMB for multi-channel RX — bug confirmation request

maohuynh — Fri, 22 May 2026 03:58:30 GMT

Dear NXP Support Team,

I am writing to report a potential bug I found in the MCUXpresso SDK SAI driver (`fsl_sai.c`)

while developing an **Active Noise Cancellation (ANC)** system on the **FRDM-MCXN947**

evaluation board. I would appreciate your confirmation of whether this is a known issue

and whether a fix is planned.

Project Overview

I am building a real-time ANC system on FRDM-MCXN947 with the following audio hardware:

4× INMP441 MEMS microphones — feedforward and error microphones for the FxLMS algorithm
2× MAX98357A I2S amplifiers — anti-noise speaker output via SAI1 TXD0 (P3_20)
Dual-core split: Core0 handles all I/O (SAI DMA, LCD, shell), Core1 runs the FxLMS
DSP algorithm. IPC via MCMGR mailbox, 16 ms frame rate (256 samples @ 16 kHz).

The system requires capturing all 4 microphones simultaneously on every 16 ms frame.
Because MCXN947 provides only one DMA request line for SAI1 RX
(kDma0RequestMuxSai1Rx = 101U), FIFO combine mode (RCR4.FCOMB) is the only
SDK-supported path to receive from both RXD0 and RXD1 with a single DMA channel.

Bug Found

SDK version: MCUXpresso SDK (mcuxsdk-core, commit 0455af2)
Driver versions: fsl_sai v2.4.11 / fsl_sai_edma v2.7.4
File: drivers/sai/fsl_sai.c

The problem

SAI_RxSetConfig() unconditionally clears RCR4.FCOMB whenever channelNums > 1,
even when the caller explicitly set fifoCombine = kSAI_RXFifoCombineModeEnabledOnRead.

The call chain is:

SAI_RxSetFifoConfig() (fsl_sai.c lines 1103–1105) — correctly sets RCR4.FCOMB
from config->fifoCombine:

rcr4 &= ~I2S_RCR4_FCOMB_MASK;
rcr4 |= I2S_RCR4_FCOMB(config->fifoCombine);   // ← set correctly
base->RCR4 = rcr4;

SAI_RxSetConfig() (fsl_sai.c lines 1439–1444) — runs after step 1 and
unconditionally clears it:

/* make sure combine mode disabled while multipe channel is used */
if (config->channelNums > 1U)
{
    base->RCR4 &= ~I2S_RCR4_FCOMB_MASK;   // ← always clears, ignores fifoCombine
}

SAI_TransferRxSetConfigEDMA() (fsl_sai_edma.c lines 362–368) — has an assert()
that correctly requires fifoCombine to be non-zero when channelNums > 1, but it
validates the config struct, not the hardware register. The assert passes while
RCR4.FCOMB is already 0 in the hardware.

The comment at step 2 says "make sure combine mode disabled while multiple channel is used"
— this appears to be a copy of the TX-side logic incorrectly applied to RX. For RX, FIFO
combine mode is required for multi-channel DMA, as documented in the example code
in fsl_sai_edma.c lines 340–350.

Observed symptom

After calling SAI_TransferRxSetConfigEDMA() with channelMask = kSAI_Channel0Mask | kSAI_Channel1Mask
and fifoCombine = kSAI_RXFifoCombineModeEnabledOnRead:

SAI1->RCR4 & I2S_RCR4_FCOMB_MASK == 0 (should be 2)
SAI RX FIFO overflow errors fire immediately on AUDIO_CaptureStart()
kStatus_SAI_RxError callbacks flood the system (hundreds per second)
The FreeRTOS UART shell task (priority 2) becomes completely unresponsive
No valid audio data is received

Reverting to single-channel (kSAI_Channel0Mask only, channelNums=1) restores
full system operation immediately.

Secondary issue — confusing enum values

The _sai_fifo_combine enum in fsl_sai.h (lines 272–277) uses swapped numeric values
for TX vs RX directions:

kSAI_FifoCombineModeEnabledOnRead      = 1U,  // TX only
kSAI_RXFifoCombineModeEnabledOnRead    = 2U,  // RX only

The example code in fsl_sai_edma.c line 348 uses kSAI_FifoCombineModeEnabledOnRead
(the TX enum, value=1) for an RX configuration. On devices with
FSL_FEATURE_SAI_HAS_FIFO_COMBINE_MODE=1 this silently configures write-combine instead
of read-combine for RX.

Current Workaround

I currently work around this by manually restoring RCR4.FCOMB after SAI_TransferRxSetConfigEDMA()
returns:

SAI_TransferRxSetConfigEDMA(SAI1, &s_saiRxHandle, &rxConfig);

/* Workaround: fsl_sai.c:1443 clears RCR4.FCOMB unconditionally when channelNums>1 */
SAI1->RCR4 = (SAI1->RCR4 & ~I2S_RCR4_FCOMB_MASK) | I2S_RCR4_FCOMB(2U);

This is fragile and requires direct register access bypassing the SDK API.

Questions

Is this a confirmed bug in fsl_sai v2.4.11?
Is there a known fix or patched version available?
Is the example code at fsl_sai_edma.c:348 (kSAI_FifoCombineModeEnabledOnRead used
for RX) intentional or also a documentation error?
Is there an official supported way to capture from SAI1 RXD0 + RXD1 simultaneously
on MCXN947 using the public SDK API that I may have missed?

A full bug report with the complete call chain analysis is attached.

Thank you for your time and support.

Best regards,
Huynh Mao
huynhmaook@gmail.com

Re: [MCXN947] SAI_RxSetConfig() clears RCR4.FCOMB for multi-channel RX — bug confirmation request

Celeste_Liu — Tue, 26 May 2026 11:17:44 GMT

Hello @maohuynh ,

Thanks for your post. I am currently investigating the issue you raised and will get back to you as soon as possible.

Celeste

Re: [MCXN947] SAI_RxSetConfig() clears RCR4.FCOMB for multi-channel RX — bug confirmation request

Celeste_Liu — Wed, 27 May 2026 08:23:39 GMT

Hello @maohuynh ,

Thank you for your patience.

First, I can confirm that fsl_sai v2.4.11 and fsl_sai_edma v2.7.4 are already the latest versions.

Regarding your statement
“SAI_RxSetConfig() (fsl_sai.c lines 1439–1444) runs after step 1”,
I have some concerns.

After reviewing fsl_sai.c, although SAI_RxSetConfig() appears after SAI_RxSetFifoConfig() in terms of line numbers, the actual execution flow shows that SAI_RxSetConfig() is called first, and then SAI_RxSetFifoConfig() is invoked within that function, provided that FSL_SAI_HAS_FIFO_EXTEND_FEATURE is enabled.

This means that when FSL_SAI_HAS_FIFO_EXTEND_FEATURE is enabled, the RCR4_FCOMB field will eventually be configured correctly.

As for the clearing of FCOMB at line 1443, my understanding is that this operation is intended to manually reset the pointer, which is consistent with the description in the reference manual (RM).

Therefore, I currently think that there is no bug here.
If you think my understanding is incorrect, please feel free to point it out.

Have a great day.

Celeste

Re: [MCXN947] SAI_RxSetConfig() clears RCR4.FCOMB for multi-channel RX — bug confirmation request

maohuynh — Wed, 03 Jun 2026 15:49:38 GMT

Hi @Celeste_Liu ,
Thank you for the clarification.
After re-reading the source code,
I agree that SAI_RxSetFifoConfig() does restore RCR4.FCOMB after the clear — your explanation of the execution order is correct.

However, the root cause of the hardware failure is a different issue: the enum _sai_fifo_combine shares numeric values between TX and RX, but the hardware encoding of TCR4.FCOMB and RCR4.FCOMB is opposite for the same numeric value (confirmed in PERI_I2S.h):

RCR4.FCOMB = 1 → enable on FIFO writes (from receive shift registers) — not what DMA needs
RCR4.FCOMB = 2 → enable on FIFO reads (by software/DMA) ← correct for multi-channel RX DMA

The example code at fsl_sai_edma.c line 348 instructs fifoCombine = kSAI_FifoCombineModeEnabledOnRead (= 1), which is the TX enum. Its name sounds correct for RX DMA reads, but its numeric value (1) maps to write-combine on RCR4, not read-combine. The assert at line 366 validates this same wrong value and silently passes, so no error is reported while the hardware is misconfigured.

The workaround I applied is I2S_RCR4_FCOMB(2U) written directly after SAI_TransferRxSetConfigEDMA(). Could NXP confirm whether the example at line 348 should use kSAI_RXFifoCombineModeEnabledOnRead (= 2) instead, and whether the assert at line 366 should be updated accordingly?

Could you help me check it ?

BRs,

Mao Huynh