STM32N6实战：SAI+GPDMA实现音频采集与调试全攻略

最近在NUCLEO-N6这块板子上把音频输入做通了，用的是STM32N6的SAI外设配合新一代GPDMA来搬运数据，整个过程里踩了不少坑，也把N6这颗MCU在音频采集场景下的脾气摸了个七七八八。这篇东西不是照抄参考手册，是我实际调通之后沉淀下来的操作记录，覆盖了方案选型、CubeMX配置、GPDMA初始化、音频代码实现和调试排障，适合手里有NUCLEO-N6、正准备用SAI做音频采集的工程师参考。

STM32N6这代芯片，大家的注意力基本都被Cortex-M55和NPU吸引了，这没错，但音频采集这种基础功能用N6做反而非常舒服。主频800MHz，RAM又大，GPDMA结构和老F4/F7系列完全不一样，不再受DMA1/DMA2通道绑定外设的约束，配起来灵活得多。SAI还是那个SAI，稳定、抗造，配合GPDMA的循环模式，可以做到CPU零干预持续采集音频数据，这对后续做语音识别、声纹处理、或者简单的频谱分析都非常关键。

1. 项目概述与方案选型

1.1 为什么用STM32N6做音频输入

如果你只是想在MCU上采集个音频、做做FFT或者跑个关键词识别，很多人第一反应还是H7甚至F4。但N6的优势是实打实的：

第一，主频800MHz的M55内核，跑算法绰绰有余，采集进来之后不管做波束成形还是跑NPU推理，都不用担心CPU算力被音频搬运占掉太多。哪怕PCM数据直接进内存再同时转发给NPU做处理，整个链路都搞得定。

第二，片上RAM最高可以到几兆字节（具体看你用的N6B3还是N6F3系列），这意味着音频缓冲不再捉襟见肘。F4时代那点内存，缓冲开大了就爆SRAM，只能做处理完就丢；N6上你可以直接开一两秒的环形缓冲，后续做事件检测、声音回看都方便。

第三，GPDMA这个外设是真的为高吞吐数据搬运设计的。它不是老DMA那种通道固定、还得分主从模式的结构，而是每个通道都可以绑定任意带DMA请求的外设，支持循环模式、链表模式、可靠的安全/非安全属性配置。做音频采集时，一条GPDMA通道在后台把SAI收下来的数据连续不断搬到内存里，CPU完全不参与，只有半buffer满和全buffer满的时候触发一次中断给个信号。

另一个容易被忽略的点是STM32N6自带安全区和非安全区（TrustZone）功能。这在音频采集里也很有用，比如你希望把音频数据放在安全区内存，应用代码跑在非安全区，通过安全的API去拿数据，那GPCDMA和SAI就得跟GTZC的配置配合好。如果只是普通采集，把外设都配成非安全就能省掉很多麻烦。

1.2 SAI和GPDMA的组合优势在哪

SAI（Serial Audio Interface）是ST单片机上专门为数字音频设计的串行接口，一根帧同步线FS、一根位时钟BCLK、一到两根数据线SD，和常用的I2S编解码器、I2S数字麦克风都能无缝对接。SAI在N6上支持独立的发送和接收块（A和B），可以配置成TDM模式、I2S模式、LSB/MSB对齐模式，灵活性非常高。

不直接用I2S外设？因为STM32N6没有单独叫I2S的外设，I2S协议其实是靠SAI来模拟的。你在CubeMX里选SAI，然后把协议选成I2S standard就行。这个细节如果没弄清楚，找外设列表的时候会懵一圈。

GPDMA则是ST这几年新推的DMA架构，相比老一代DMA，它有几个很实用的特性：

• 多通道可以自由映射，不用担心SAI接在DMA1还是DMA2上，也不用查通道映射表。
• 支持循环模式（Circular Mode），这是音频采集的刚需，DMA搬完一整个缓冲区自动回绕继续搬，配合半满/全满中断做双缓冲，数据永远不会断。
• 支持8/16/32位数据传输宽度对齐，SAI接收到的音频帧可以直接按32位（左声道+右声道拼在同一个字里）或者16位（单声道/双声道16位）搬运，省去后面拆包的功夫。
• 触发方式很灵活，可以选择在FIFO达到某个阈值时发起搬运，也可以每个数据字都触发，后者非常适合音频这种等时数据流。

所以GPU呢？其实我是想说，GPDMA + SAI + 中断回调，这套链路做下来，比老式"SAI + DMA + FIFO中断"的方案方便得多，关键是缓冲区管理逻辑非常清晰：半满中断处理前半段数据，全满中断处理后半段数据，来回交替，永远不丢数据。

1.3 整体系统架构

整个音频采集系统的框图拆开看，大概是这样的：

• 音频信号源：接在NUCLEO-N6板卡扩展口上的数字麦克风或音频编解码器。我用的是INMP441这种I2S接口的MEMS麦克风模块，供电3.3V，信号线只要四根：SCK（位时钟）、WS（帧同步）、SD（数据）、L/R（声道选择）。这比模拟麦克风+运放+ADC的老方案省太多事。
• 硬件连接：SCK接SAI1的SCK引脚，WS接SAI1的FS引脚，SD接SAI1的SD_A引脚。
• 片上搬运：SAI1通过GPDMA通道把音频数据搬到一个用户自定义的缓冲区，缓冲区开成4字节对齐的uint32_t数组。
• 中断通知：GPDMA半满/全满各触发一次回调，在回调里只是置标志位，实际处理放主循环或者交给NPU/信号处理模块。
• 数据处理：把采集到的PCM数据从32位帧中拆出有效位，做音量计算、存到SD卡或者送给NPU。

这样分层下来，每一层都可以单独调试。信号有没有、波形对不对、数据有没有搬进内存、内存里的数据格式是否正常，一步一步排查非常方便。

2. 硬件连接与引脚配置

2.1 NUCLEO-N6板卡资源盘点

NUCLEO-N6这块板子，和之前NUCLEO家族的板卡布局基本一致，但核心芯片换成了STM32N6。开发板上提供了ST-LINK调试器、三个用户LED、两个按钮、Arduino Uno V3扩展接口以及ST Morpho全引脚扩展排针。

做音频输入时用得最多的就是Morpho排针，因为SAI1的引脚不一定在Arduino接口上全部引出。你需要在CubeMX里看你选的引脚具体映射到哪个位置，然后在原理图上找到对应的排针编号，用杜邦线或者飞线连到外部模块。

NUCLEO-N6板卡的板载ST-LINK用的是调试口，也和USB转串口复用，这个不影响音频功能，但是调试时很方便，可以直接开一个串口打印调试信息。

2.2 音频前端选择：从PDM麦克风到编解码器

音频输入的前端方案，基本就三类：

• PDM数字麦克风，接DFSDM外设或者某些支持PDM解调的SAI。PDM的好处是只传1-bit数据流，由MCU内部做抽取滤波得到PCM数据，缺点是PDM解调本身会吃掉一些CPU周期，而且DFSDM和SAI在N6上具体支持情况需要查对应型号的勘误表。
• I2S接口MEMS麦克风，比如INMP441、ICS-43434，内部已经做了PDM到PCM的转换，输出标准的I2S格式PCM数据，MCU这边只需要配置SAI接收即可。我最终选用INMP441，接线最简单，而且模块很便宜，几块钱一片。
• 音频编解码器，比如CS42L51、WM8960、TLV320AIC23这类，它们通常有ADC和DAC，可以录音也可以放音，还带麦克风前置放大和线路输入。接Codec的好处是后续可以播放，但调试时多一个I2C控制通道，需要先配置Codec的寄存器，才能让SAI收到有效数据。

如果只是验证SAI和GPDMA的链路通不通，强烈建议先拿INMP441这种I2S麦克风，省去I2C配置的干扰。等链路通了，再换Codec做双向音频也不迟。

2.3 SAI引脚映射与时钟生成

在NUCLEO-N6上我用的是SAI1 Block A，信号线定义：

• SAI1_SCK：串行位时钟，由SAI1主机产生，一般配置成64 * fs，也就是每帧64个位时钟，这样左右声道各32位，16位有效数据也在这个32位槽里左对齐。
• SAI1_FS：帧同步信号，在I2S标准协议里，一个帧周期是左右各一个声道，FS低电平表示左声道，高电平表示右声道（具体极性可以在CubeMX里翻转）。
• SAI1_SD_A：数据线，接收外部麦克风或Codec返回的PCM数据。

N6的SAI外部MCK（主时钟输出）可以配置为PLL2或PLL3生成的音频主时钟。比如我取fs=48kHz，MCK频率配置为512 * fs = 24.576MHz，这个频率是广播音频里非常标准的主时钟，后续接Codec时也是它想要的工作频率。需要注意：INMP441这种I2S MEMS麦克风不需要MCK，它自己从BCLK恢复时钟，但CS42L51这类Codec通常必须要MCK。

CubeMX里时钟树配置的思路是这样：

• PLL1跑系统时钟（800MHz），这个别乱动。
• PLL2里留一路给SAI的时钟源，比如PLL2_Q输出48MHz，然后分频得到24.576MHz的SAE? 不，SAI_MCLK就出来了。
• 需要确认N6的SAI时钟树：SAI_CK = PLL2_Q / 分频系数。分频后的频率要小于SAI最高时钟限制，同时能够被需要的主时钟频率整除。

具体计算：如果你想MCK=24.576MHz，而PLL2_Q输出49.152MHz，那分频系数就是2，直接得到24.576MHz；如果PLL2_Q输出73.728MHz，分频系数就是3，得到24.576MHz。这些都能在CubeMX时钟树页面里实时看到实际频率，配置的时候务必小心红色的超频警告，看到页面变黄变红就要调整。

3. CubeMX配置与GPDMA初始化

3.1 核心配置步骤

我以STM32CubeMX + STM32CubeIDE为基础，一步步走一遍配置过程。

第一步，选择MCU型号。NUCLEO-N6对应的是STM32N6B3系列（或者你用的具体型号），在CubeMX的MCU选择器里输入STM32N6B3K? 如果找不到，选择STM32N6系列再在Board Selector里选NUCLEO-N6开发板。选中板卡后，CubeMX会自动初始化外部时钟、调试口和LED引脚，省去很多配置工作。

第二步，配置SAI。在Categories左侧选择Multimedia -> SAI1，勾选Block A，Mode选择Master Receiver。为什么是Master Receiver？因为你希望N6产生BCLK和FS，然后从麦克风/Codec那边接收数据。如果选Slave模式，就需要外部设备提供位时钟和帧同步，一般I2S麦克风都是被动接收时钟，所以N6必须做主机。

Block A参数配置参考：

• Protocol：I2S standard（实际就是生成I2S时序）
• Data Size：32位（因为INMP441一个时隙是32位，有效数据24位，正好按32位读进来再移位）
• Frame Length：32位
• Frame Sync Active：High level? 实际上INMP441的WS在高电平时是右声道，CubeMX里可以配成FS Active During Slot 0，然后再根据实际波形调整。
• Frame Sync Offset：1 bit（I2S标准里FS比数据提前一位时钟，这是标准）
• Output Drive：Enable（保证驱动能力）
• FIFO Threshold：默认即可（也可以配成Quarter Empty/Full，影响不大）

第三步，配置时钟树。把Audio Clock Source选到PLL2或PLL3某个输出，然后看页面上的频率是否正确。我这边配PLL2_Q为49.152MHz，SAI分频系数2，得到24.576MHz的MCK。48kHz采样率下MCK=512*fs刚好。

第四步，配置GPDMA。在SAI1的DMA Settings选项卡里Add一个DMA request，选择GPDMA1通道。这里要注意，N6里DMA控制器叫做GPDMA1和GPDMA2，别找DMA1/DMA2。

点击DMA请求之后，配置如下：

• Direction：Peripheral to Memory
• Mode：Circular（循环，重中之重）
• Priority：High（音频实时性要求）
• Increment Address：内存地址递增，外设地址固定
• Data Width：Word（32位）——和SAI的Data Size对齐

还有一个关键点，GPDMA有个FIFO阈值配置。在内存和FIFO之间搬运时，可以选择什么时候触发搬运请求。我的配置是FIFO Threshold = Full或Half，整体效率差不多，但如果你发现中断频率过高、CPU负载大，可以适当调高阈值。

第五步，配置NVIC。到NVIC Settings选项卡，打开SAI1 global interrupt、GPDMA中断。很多人配完GPDMA忘了使能中断，导致回调永远不执行。

3.2 GPDMA与SAI的握手机制

SAI和GPDMA之间的握手，和老的DMA有点类似：SAI接收FIFO每进来一个或几个数据字，就会向GPDMA发一个请求，GPCDMA根据配置的burst大小把数据从FIFO搬到内存。

这里要明白一个概念：GPDMA是按传输粒度工作的。它把一整块数据搬运看成若干次burst，每次burst可以搬4、8、16个数据单元。对音频而言，每次SAI收到一个32位帧，就往FIFO里塞一个字，GPDMA通过FIFO把数据攒到一定数量后，一次性搬走，减少对总线的占用。

我看到一些工程师在配GPDMA时照抄H7的配置，其实没必要。N6的CubeMX里配置相对简单，你只需要确认：

• Data Width = Word（32位），保证一次搬运正好是一个音频帧（左右声道各16位或24位拼成一个32位Word）。
• Burst Size = 1或者4都行，配置成1对时序要求最严格，配置成4能减少GPDMA触发次数，但对FIFO门限有要求。
• 如果出现音频数据中间有间隙（采到的波形是断断续续的），很可能是FIFO门限配置过高导致小批量数据没能及时搬走、FIFO溢出丢字，这时可以把门限调低一些。

3.3 安全区/非安全区配置对音频链路的影响

N6的TrustZone安全功能不是摆设，如果你在CubeMX里启用了TrustZone（TrustZone Enabled），那SAI和GPDMA默认可能是安全外设，而你的应用程序是Non-Secure的，这就导致了无论怎么调DMA，数据都进不了Non-Secure内存。

我实际遇到的症状是：GPDMA中断回调能触发，但是收到的数据缓冲区一直是全0，或者说DMA搬运根本没执行，报Bus Error。查了半天，最后定位到是GTZC的TZSC配置那里，SAI1和GPDMA1被划到了Secure域，而Non-Secure的应用程序无法直接访问这些安全外设的寄存器，DMA请求也就没法正常路由。

解决办法有两种：

• 方案一，如果你不需要 TrustZone，就在CubeMX里关闭 TrustZone，所有外设默认都是 Non-Secure，省心。
• 方案二，如果项目确实需要安全隔离，就得在 TrustZone 初始化文件里，把 SAI1、GPDMA1 以及它们对应的中断 EXTI 通道都配置为 Non-Secure，同时把音频缓冲区所在的 RAM 区域标记为 Non-Secure，然后在 Non-Secure 应用里正常使用。

关于中断这一点，很多人会漏。N6的中断控制器里，同一个外设的中断源有 Secure 和 Non-Secure 两种触发路径。如果你在外设安全属性已经是 Non-Secure，但中断优先级分组或者 NVIC 里设置不对，中断可能进了 Secure 那边，然后卡死。调试这种问题最简单的方法是先关闭 TrustZone，把功能跑通，再逐步打开安全隔离，这样能大幅缩小排查范围。

4. 音频数据采集代码实现

4.1 初始化流程与HAL函数

CubeMX生成工程之后，SAI和GPDMA的初始化代码已经自动生成了，核心集中在MX_SAI1_Init()和MX_GPCDMA_Init()函数里。

启动音频采集不需要像老库那样自己写一整套DMA启动代码，直接调HAL函数：

uint32_t audio_buf[AUDIO_BUF_SAMPLES] __attribute__((aligned(4))); HAL_StatusTypeDef ret; ret = HAL_SAI_Receive_DMA(&hsai1, (uint8_t *)audio_buf, AUDIO_BUF_SAMPLES); if (ret != HAL_OK) { Error_Handler(); }

注意AUDIO_BUF_SAMPLES的单位是样本数，对于32位音频帧，每个样本就是32位。缓冲区开成uint32_t数组，这样一次中断触发的要么是前半段半满、要么是后半段全满，处理时很方便。

HAL_SAI_Receive_DMA内部会把GPCDMA配置成 Circular 模式，并且把用户缓冲区指针写到DMA目的地址寄存器。启动后，只要SAI有数据进来，GPCDMA就会自动搬运，不需要CPU干预。

4.2 半满中断与全满中断的双缓冲机制

这一节是整个代码的核心。

GPCDMA在循环模式下，搬运到缓冲区中点的时刻会触发一次传输半完成中断，搬运到缓冲区末尾时触发一次传输完成中断，然后地址自动回绕到缓冲区开头继续搬。这个机制天然形成了双缓冲：

• 前半段缓冲区正在被GPCDMA写入，后半段缓冲区已经稳定，可以处理。
• 后半段缓冲区正在被GPCDMA写入时，前半段缓冲区稳定，可以处理。

HAL库里面当然有现成的回调接口，你可以自己实现：

volatile uint8_t buf_half_ready = 0; volatile uint8_t buf_full_ready = 0; void HAL_SAI_RxHalfCpltCallback(SAI_HandleTypeDef *hsai) { if (hsai->Instance == SAI1) { buf_half_ready = 1; } } void HAL_SAI_RxCpltCallback(SAI_HandleTypeDef *hsai) { if (hsai->Instance == SAI1) { buf_full_ready = 1; } }

回调里不要做耗时工作，只置标志位。中断里做数据处理有两个问题：一是占用中断时间会导致中断响应变慢，更糟的是如果GPCDMA正在搬后半段，而你又在中断里访问了音频缓冲区并且做大量运算，你的运算指令和DMA搬运指令争抢总线，可能导致DMA搬运不及时、数据丢失。

主循环里就可以根据标志位来处理数据了：

while (1) { if (buf_half_ready) { buf_half_ready = 0; process_audio(&audio_buf[0], AUDIO_BUF_SAMPLES / 2); } if (buf_full_ready) { buf_full_ready = 0; process_audio(&audio_buf[AUDIO_BUF_SAMPLES / 2], AUDIO_BUF_SAMPLES / 2); } }

4.3 缓冲区数据处理：从32位帧中提取有效PCM数据

INMP441输出的数据格式是24位有效数据，左对齐在32位时隙里，低位无意义，大致排列如下：

• 位31..位8：24位PCM样本（二进制补码）
• 位7..位0：无效位，通常为0

为了得到干净的单声道16位PCM数据，需要先右移8位，再截取低16位：

int16_t sample = (int16_t)(audio_word >> 8);

这样取出来的就是可以直接送录音文件、或者做音量计算的PCM数据。

如果你接的是双声道Codec，那么一个32位字的高16位是左声道、低16位是右声道（I2S标准下）。处理逻辑：

int16_t left = (int16_t)(audio_word >> 16); int16_t right = (int16_t)(audio_word & 0xFFFF);

有的Codec支持24位有效数据，那还需要再多移一位：右移8位后只保留高16位，或者右移1位得到带符号24位。关键是搞清楚外部设备的输出格式，这个直接决定了数据对不对。

我在调试时验证数据是否正常的方法很简单：采集一段1kHz正弦波，把收到的PCM数据导出来，在电脑上画图或者用FFT看频谱。如果FFT峰值正好落在1kHz而且没有明显谐波，说明链路完全正常。当然如果只是想在嵌入式里快速验证，也可以算一算这段数据的RMS值——正弦波的RMS应该大约是峰值的0.707倍，而且不会是满幅噪声。

5. 调试验证与常见问题排查

5.1 波形验证与数据完整性检查

音频采集最怕的就是"有中断但数据是错的"。我建议按照从信号源到软件处理的顺序，一层层检查：

第一步，用示波器或者逻辑分析仪看SAI1_SCK和SAI1_FS引脚，确认位时钟和帧时钟存在。如果BCLK或FS根本没有，说明MCK时钟配置有问题，回到CubeMX时钟树检查PLL2/SAI分频。

第二步，看SAI1_SD_A引脚有没有数据。INMP441在静音环境里输出的是接近0的PCM数据，在示波器上看起来像是接近中间电平的噪声；对着麦克风说话，引脚上应该有明显的幅度变化。如果SD引脚完全没动静，可能麦克风供电不足或者VDD没有接好，也可能是麦克风的L/R选择引脚没配置正确（INMP441的L/R引脚接地，左声道输出；接VDD，右声道输出）。

第三步，看程序里的原始缓冲区。在调试器里把audio_buf数组的hex数据导出来，手动检查几个样本是否落在合理范围。正常语音数据不应该全0，也不应该全0xFFFFFF，全0xFFFFFF往往表示SAI没接收到有效信号，或者Data Size配置和数据不对齐。

第四步，算RMS或者峰值。跑一个简单的处理函数：

float calc_rms(uint32_t *buf, uint32_t len) { uint64_t sum = 0; for (uint32_t i = 0; i < len; i++) { int16_t s = (int16_t)(buf[i] >> 8); sum += (uint64_t)(s * s); } return sqrtf((float)sum / len); }

对着麦克风说话，RMS值会明显跳变，就说明从麦克风到SAI到GPCDMA到内存的整条链路都是通的。

5.2 常见问题排查表

调试过程中我遇到过几类问题，整理成一个速查表，按发生频率从高到低排列：

这里面最隐蔽的是最后一个HardFault问题。GPDMA不像老DMA那样访问非法地址就默默停掉，它有时候会触发总线错误中断，进而进HardFault。如果排查HardFault时想到DMA，那首先要确认audio_buf是不是4字节对齐（uint32_t数组本来就会对齐，但如果你是手动分配的局部变量，可能栈地址不是4字节对齐），其次确认AUDIO_BUF_SAMPLES是否和DMA配置的传输长度完全一致，如果DMA搬运到缓冲区末尾再加1个样本，问题就来了。

5.3 我的调试经验总结

这一路调下来，几个心得分享给大家。

第一，音频调试必须从信号源头开始排查。别急着看代码，先拿示波器或者逻辑分析仪确认BCLK、FS、SD引脚波形。只要波形对了，问题就缩小到GPDMA配置和软件处理这两块。我见过有人调了三天找不到原因，最后发现是麦克风L/R引脚悬空，导致数据一直在两个声道间跳来跳去。

第二，先用HAL库的阻塞模式验证SAI本身能不能收到数据。比如HAL_SAI_Receive(&hsai1, buf, 1, 1000)阻塞接收一个样本，如果连这个都超时，说明外设配置或者硬件连接就有问题，没必要急着上DMA。这个步骤是很多初学者跳过的。

第三，GPDMA的Priority不要配成Low。虽然Priority不影响正确性，但在N6这种多DMA外设并存的环境里，Low优先级可能在系统繁忙的时候被一直拖欠，音频数据流就会断。配High或者Very High，代价可以忽略。

第四，缓冲区大小要跟你的处理节奏匹配。在48kHz采样率下，如果缓冲区开1024个样本（4096字节），每1024/48000 = 21.3ms触发一次中断，主循环必须在这个时间范围内把数据处理完，否则就会出现overrun问题。如果你的处理逻辑比较重，要么把缓冲区开大，要么用DMA链表把人分成更多小块。我的经验是：缓冲区越大，系统越稳，但实时性越差；反过来缓冲区小，延迟低，但主循环压力大。N6有充足RAM，我建议直接开到4096或8192个样本，给MCU留足余量。

5.4 后续可以怎么扩展

这套逻辑调通之后，扩展空间非常大。因为GPCDMA + SAI本质上就是一段持续不断的PCM比特流在进内存，你只需要在处理器里写各种算法消费这些PCM数据即可。

比较实用的扩展方向：

• 接音频Codec实现双向音频，即SAI同时配收发两个Block，Block A收、Block B发，再用GPDMA两条通道分别搬运收发数据，这就是一个完整的音频交互相机。
• 把缓冲区里的PCM数据灌给N6的NPU做关键词识别。N6的Neural-ART NPU很适合跑一些小尺寸音频分类模型，DMA采进来的数据直接作为输入张量的一部分，省去读写外部存储的延迟。
• 用GPCDMA链表模式做更细粒度的缓冲管理，比如把不同的音频事件（录音开始、静音段检测）用链表串联起来，实现硬件级的数据流调度。
• 如果对时延敏感，还可以开启GPDMA的异常中断（Transfer Error Interrupt），在代码里对错误状态做实时监控，避免音频流长期运行后出现静默故障。

我个人的建议是：先把基础链路跑稳，再逐层加复杂功能。音频采集这东西，前面链路通了，后面做各种花活只是时间问题。

最后分享一个小技巧：如果你手头没有独立的音频源，可以用手机播放一个1kHz正弦波的音频文件，然后把手机扬声器对着麦克风——这是一种最原始但又十分有效的测试方式。把采集到的数据算一下FFT，看到1kHz有个尖峰，整条SAI+GPDMA链路基本就稳了。我在多个项目里都靠这一招快速验证音频前端，几乎每次都能在5分钟内确认问题出在硬件还是软件。