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 ?