STM32N657X0 SAI Rx DMA: Callbacks not firing / No clock output

[caglayankml]

Hello everyone,

I'm working with a NUCLEO-N657X0-Q board and trying to read audio data from an INMP441 I2S microphone using SAI2 in Master Receive mode with DMA. I have configured everything in STM32CubeIDE, but the DMA transfer complete interrupts are never firing.

Here is a summary of my setup and the troubleshooting steps I've taken.

Hardware Setup:

• Board: NUCLEO-N657X0-Q
• Microphone: INMP441
• Connections:
  • PE12 -> SCK (SAI2_SCK_B)
  • PE13 -> WS (SAI2_FS_B)
  • PE11 -> SD (SAI2_SD_B)
  • Mic L/R pin is connected to GND.
  • Mic is powered by the board's 3.3V supply.

STM32CubeIDE Configuration (.ioc):

• Project Type: FSBL only (no Appli).
• SAI2_B Configuration:
  • Mode: Master Receiver
  • Protocol: I2S Philips Standard
  • Data Size: 24 Bits
  • Number of Slots: 2
  • Audio Frequency: Set to 16 KHz.
• DMA Configuration:
  • SAI2_B is linked to HPDMA1_Channel0.
  • Mode is set to Circular.
• NVIC Configuration:
  • HPDMA1_Channel0 global interrupt is enabled.
• Clock Configuration:
  • SAI2 Kernel Clock is configured to ~2.048 MHz (derived from PLL2). It is not 0 and not at a very high frequency.

The Problem:

1. HAL_SAI_Receive_DMA() is called and returns HAL_OK.
2. However, the DMA callbacks (HAL_SAI_RxHalfCpltCallback and HAL_SAI_RxCpltCallback) are never triggered.
3. I have placed counter variables inside the callbacks, and they never increment when checked with the debugger. The i2s_buffer remains filled with zeros.
4. This leads me to believe that the SAI peripheral is not generating the necessary clocks (SCK/WS) to communicate with the microphone, which is why no data is being received and no DMA interrupts are generated.

Troubleshooting Steps Taken:

• Disabled Security Isolation: I have commented out the SystemIsolation_Config(); call in main.c.
• Verified IRQ Handler: I confirmed that stm32n6xx_it.c contains the HPDMA1_Channel0_IRQHandler function and it calls HAL_DMA_IRQHandler().
• Verified All Settings: I have double-checked all the configurations mentioned above (Clock, NVIC, DMA, SAI protocol) multiple times.
• Checked Hardware: I have verified the physical wiring.

My Question:

Before I proceed with probing the clock lines with an oscilloscope (which is far away), I wanted to ask the community: Is there a common configuration mistake or an essential initialization step for the STM32N6's SAI peripheral in Master Receive mode that could cause this behavior (i.e., failure to start clock generation)?

For your review, I have attached my main.c project file and screenshots of my HPDMA and SAI configurations.

(Please note: I used an AI assistant to help edit this text, so I apologize for any awkward phrasing.)

[AScha.3]

Hi,

Did you enable the SAI callbacks in Cube project settings?

[caglayankml]

Hi AScha.3,

Thanks for following up! Sorry for my late response.

I enabled the SAI callbacks as you suggested (`Register Callbacks` set to `Enabled` in Project Manager) and also disabled the ICACHE (`System Core > ICACHE > Disable`) to get the debugger working correctly.

Here's the current status:
* The debugger now hits breakpoints properly.
* My `main()` function starts, initializes peripherals, and the main `while(1)` loop is running (I can confirm this with `printf` messages sent periodically via VCOM).
* `HAL_SAI_Receive_DMA()` is called and still returns `HAL_OK`.
* *However, the DMA callbacks (`HAL_SAI_RxHalfCpltCallback` and `HAL_SAI_RxCpltCallback`) are still *never* getting called.** My counters (`control_half`, `control_complete`) inside these callbacks remain zero.

This confirms that the DMA interrupt isn't firing. Since the `IRQHandler` exists in `stm32n6xx_it.c`, callbacks are registered, security isolation is disabled (commented out `SystemIsolation_Config()`), and the SAI Kernel Clock is set correctly (between ~2 MHz-200MHz), it seems the issue might be that the SAI peripheral itself isn't starting the transfer or isn't receiving any clock/data correctly.

I wonder if I should check the hsai_BlockB2.State right after the HAL_SAI_Receive_DMA() call to confirm it's in the HAL_SAI_STATE_BUSY_RX state. Would that be a good next step?.

Do you have any other suggestions based on this new information, specifically regarding potential issues that could prevent SAI clock generation or data reception on the STM32N6 even if the configuration appears correct?

Thanks again for your continued help!

[AScha.3]

Hi,

I-cache should be ON , just D-cache OFF is useful, at least at beginning.

(only data is a problem with DMA action, instructions always only handels the cpu, dma running or not.)

next...SAI settings:

show your..., is output drive set ?

[caglayankml]

Hi AScha.3,
​Thanks again for your guidance. I followed your suggestions about enabling callbacks and disabling ICACHE, which allowed the debugger to work. I also reviewed the SAI settings.
​I tried configuring SAI B based on your example parameters, ensuring Output Drive is Enabled. Here is a screenshot of my current settings:
​Key settings in this configuration:
​Protocol: I2S Standard
​Data Size: 24 Bits
​Master Clock No Divider: Enabled
​Audio Frequency (Target): 48 KHz (Note: Changed from 16 KHz in earlier tests)
​Fifo Threshold: Empty (Still set to Empty based on your screenshot example, maybe this is wrong for Receiver?)
​Output Drive: Enabled
​Results with this configuration:
​
​The DMA callbacks (HAL_SAI_RxHalfCpltCallback and HAL_SAI_RxCpltCallback) are still not being triggered. My counters inside remain zero.

​Oscilloscope: I probed the SAI pins:
​SCK (PE12): Shows a clock signal (frequency corresponds to 48 KHz target and settings).
​WS (PE13): Shows a frame select signal (48 KHz).
​SD (PE11): Shows data activity from the microphone.

​Remaining Issue:

Even though the clocks are generated and the microphone is sending data, the DMA interrupts are not firing.

​Could the Fifo Threshold setting being Empty be incorrect for Master Receive mode? Should it be Half Full instead?
​Also, in the CubeMX Clock Configuration tab, although I target 48 KHz, the Real Audio Frequency shows 0.
​
​Any further advice, especially regarding the Fifo Threshold setting for receiver mode, would be greatly appreciated.
​Thank you!

[AScha.3]

So on H7S3 , SAI shows:

with clock setting for SAI:

+ try setting stereo...as i dont know, what "mono" doing with 2 channels (I2S is basically always 2 ch, L+R ).

+ try fifo..half, if you like; it will not explode...just 30 sec and you know.

+ btw  look at ..N657X0 errata sheet, just to exclude, there is a known problem.

[caglayankml]

Hi AScha.3,
Thanks for the suggestions. I tried setting `Fifo Threshold` to `Half
Full`, ensured `Output Drive` is `Enabled`, and verified the `SAI
Kernel Clock` is ~2MHz. Unfortunately, the DMA callbacks are still not
firing.
Following the troubleshooting guide, I checked the
**`hsai_BlockB2.ErrorCode`** in the debugger right after calling
`HAL_SAI_Receive_DMA()`.
The `ErrorCode` shows **`130` (Decimal), which is `0x82` (Hex).**
Looking up the HAL error codes, this corresponds to
**`HAL_SAI_ERROR_LFSDET` (Late Frame Synchronization Detected)**.
This is puzzling because the STM32 is configured as **Master
Receiver**, so it should be *generating* the WS/FS signal itself. Why
would it detect a "late" frame sync signal that it's supposed to
create?
* Could this indicate an issue with the SAI clock source (PLL not
locking, clock instability)? I've tried deriving the ~2MHz clock from
PLL2 P.
* Is there any other configuration that might lead to
`HAL_SAI_ERROR_LFSDET` in Master mode?
I also re-confirmed with the oscilloscope that SCK and WS signals
**are present** on the pins PE12 and PE13, and there is data activity
on PE11 (SD).
I'm currently trying to switch the SAI clock source to PLL3 P as a
next step.
Any insights into why `HAL_SAI_ERROR_LFSDET` might occur in Master
Receive mode would be very helpful.
Thanks!

[AScha.3]

Hi,

>verified the `SAI Kernel Clock` is ~2MHz

Whats the `SAI Kernel Clock` ? the 24M i have for SAI ?

+

because

>the Real Audio Frequency shows 0

shows: the SAI clock much to low, try as i do, to set it to 24.xx M .

-> Real Audio Frequency should show, what you get.

Now you get .... 0.

[caglayankml]

Hi @AScha.3,

Thank you very much for your suggestion regarding the SAI clock.

I have tried setting the clock to 24.xx MHz as you recommended, and a wide range of other frequencies (between 0.5 MHz - 200 MHz), but unfortunately, the issue persists.

Here are my current key settings:
- DMA Mode: Circular
- DMA Data Width: Peripheral: Word, Memory: Word
- SAI Slot Size: 32-bit
- NVIC: DMA stream interrupt is enabled.

I have also used breakpoints in my user code in while (1) loop. During debugging to trace the issue. I am still receiving the same error code: 0x82.

Based on the error flags, this seems to be a combination of HAL_SAI_ERROR_DMA (0x80) and HAL_SAI_ERROR_OVR (0x02). This leads me to believe that while the clock frequency is important, the root cause is a problem in my DMA configuration. It seems the DMA transfer fails first, which then causes the SAI FIFO to overrun.

Given this, do you have any further suggestions on what to check specifically within the DMA settings? Are there any common mistakes or known issues for this configuration that I might be missing?

[AScha.3]

Hi,

so expected Fs now shows something close to 48k ?

+

I just looked at your program...as i dont have a N657 , i am on H743 (here, for my audio player);

you use HPDMA , i just normal DMA , but what i miss , is the DMA setup, before using it. (But maybe not needed on N657, look for an example or just try. Look in the driver, whats there as comment/info.)

And callbacks registered .

And your buffer so small - why ? (I have 4K buffers)

so first init dma, then start SAI :

//main...init
  HAL_SAI_RegisterCallback(&hsai_BlockA1, HAL_SAI_TX_HALFCOMPLETE_CB_ID, HAL_SAI_1a_TxHalfCpltCallback);
  HAL_SAI_RegisterCallback(&hsai_BlockA1, HAL_SAI_TX_COMPLETE_CB_ID, HAL_SAI_1a_TxCpltCallback);

 fresult = HAL_DMA_Init(&hdma_sai1_a);

 	fresult = HAL_SAI_Transmit_DMA(&hsai_BlockA1,  (uint8_t *)playbuf , (sizeof(playbuf))/4);	// master start 

 (just from my prog, you have to use your names and SAI_receive of course.