企业官网建设流程全解析

1. 这不是一次普通代码扫描：为什么 ML-KWS-for-MCU 的静态评测值得花三天时间抠细节

你手头有一块 Cortex-M4 的开发板，想跑个关键词唤醒——“Hey Jarvis”或者“小智同学”。你从 GitHub 拉下 ML-KWS-for-MCU 这个仓库，make all一敲，烧录进去，LED 亮了，麦克风收音了，但唤醒率只有 62%，误触发每小时 3.7 次。你开始怀疑是模型太浅？数据集太偏？还是硬件麦克风增益没调好？——其实问题可能藏在第 187 行kws_model.c里一个未初始化的int16_t buffer[128]数组里。这个数组在每次推理前被memset(buffer, 0, sizeof(buffer))覆盖，但编译器优化级别-O2下，GCC 6.3.1（ARM Embedded Toolchain）会把它识别为“dead store”，直接删掉这条指令。结果 buffer 里残留着上一轮 FFT 计算的残余数据，导致 Mel 频谱图出现周期性噪声，模型把“洗衣机”误判成“小智同学”。

这就是 ML-KWS-for-MCU 的真实战场：它不是 TensorFlow Lite Micro 那种“开箱即用”的玩具框架，而是一套为资源极限（<256KB Flash、<64KB RAM）量身定制的、高度手工调优的嵌入式语音识别流水线。它的源码里没有一行废话，每个#define都对应着一块物理内存的边界，每个__attribute__((section(".ram_code")))都是在和 Cache Line 对齐搏斗。所谓“静态评测”，绝不是用 SonarQube 扫出几个null pointer dereference就交差的事。它要回答的是：这段代码在 Cortex-M4 上跑满 1000 小时后，会不会因为某处未对齐访问触发 HardFault？某个中断服务函数里调用的malloc是否真的被链接器重定向到了静态分配池？arm-none-eabi-gcc -mcpu=cortex-m4 -mfpu=fpv4-d16 -mfloat-abi=hard这串参数背后，有多少浮点寄存器被隐式压栈又没恢复？这些，才是 ARM 边缘 AI 工程师每天睁眼第一件事要确认的。

我过去三年做过 17 个基于 MCU 的 KWS 项目，其中 12 个在量产前卡在“唤醒率突降”这个坑里。最后发现，有 9 个问题根源不在模型训练，而在 ML-KWS-for-MCU 的工程架构设计里——比如它的特征提取模块硬编码了 16kHz 采样率，但客户用的 ADC 实际输出是 15.98kHz；再比如它的量化表生成脚本默认用int8_t，可某些 Cortex-M0+ 内核对int8_t的乘加指令支持不全，必须回退到int16_t。这些细节不会写在 README.md 里，也不会出现在任何 CI 测试报告中。它们只活在.ld链接脚本的MEMORY区段定义里，在startup_stm32f407xx.s的向量表偏移计算中，在arm-none-eabi-gdb单步调试时寄存器窗口一闪而过的SP值变化里。所以这次静态评测，我决定不碰任何运行时工具，就用ctags+cscope+grep -r+ 纸笔，把整个工程像解剖一只机械手表一样，一层层拆开齿轮、游丝和发条盒。这不是炫技，而是因为——在边缘 AI 的世界里，最危险的 bug 往往没有堆栈跟踪，它只会在电池电量剩 12% 时，让设备永远沉默。

2. 工程架构全景：从顶层目录到寄存器映射的七层结构拆解

2.1 目录树即架构图：每个文件夹都是一个内存域的宣言

ML-KWS-for-MCU 的目录结构不是随意组织的，它本身就是一份内存布局说明书。我们先看顶层：

├── application/ # 用户业务逻辑区（RAM 中执行） │ ├── kws_main.c # 主循环，含状态机与唤醒后动作 │ └── audio_input.c # 麦克风 DMA 回调，数据搬运工 ├── core/ # 核心算法区（Flash 中执行，部分常驻 RAM） │ ├── model/ # 量化模型权重（.bin 文件，加载到 RAM） │ ├── feature/ # MFCC 特征提取（C 语言手工汇编混合） │ └── inference/ # 推理引擎（TinyEngine 改写版） ├── drivers/ # 外设驱动区（Flash 中执行） │ ├── adc/ # ADC 驱动（含采样率校准补偿） │ └── gpio/ # GPIO 控制（LED、按键） ├── middleware/ # 中间件区（Flash 中执行） │ └── cmsis/ # CMSIS-DSP 库（已裁剪，仅保留 arm_rfft_fast_f32） ├── platform/ # 平台抽象层（Flash 中执行） │ ├── stm32f407xx/ # STM32F407 具体实现（含启动文件、系统时钟配置） │ └── generic/ # 通用接口（如 platform_timer_init()） ├── tools/ # 构建与测试工具（Host 端运行） │ ├── quantize/ # 量化脚本（Python，生成 .bin 权重） │ └── testbench/ # PC 端仿真测试（验证特征提取一致性） └── Makefile # 构建入口，定义所有内存段

关键点在于：application/和core/的代码默认编译进 Flash，但application/kws_main.c中的static int16_t audio_buffer[512]会被链接器自动分配到.bss段（RAM），而core/feature/mfcc.c中的const float32_t mel_filterbank[20][129]则强制放在.rodata段（Flash）。这种分离不是约定俗成，而是由platform/stm32f407xx/STM32F407VGTx_FLASH.ld链接脚本明确定义的：

MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K } SECTIONS { .text : { *(.text) *(.text.*) } > FLASH .rodata : { *(.rodata) *(.rodata.*) } > FLASH .data : { *(.data) *(.data.*) } > RAM AT > FLASH .bss : { *(.bss) *(.bss.*) } > RAM }

提示：.data段的> RAM AT > FLASH是精髓——它表示变量初始值存于 Flash，启动时由SystemInit()后的__data_start拷贝到 RAM。如果你在application/audio_input.c里声明static uint32_t sample_counter = 0;，这个0存在 Flash 里，上电后才复制到 RAM 地址0x20000000。如果sample_counter被 ISR 修改，而主循环读取时恰好遇到拷贝过程（极小概率），就会读到脏数据。这是很多“偶发计数错误”的根源。

2.2 内存段战争：.ram_code、.fast_data与.stack的生死博弈

真正体现 ARM 边缘 AI 工程深度的，是那些非标准内存段的定义。在core/inference/tinymodel.c开头，你会看到：

__attribute__((section(".ram_code"))) int8_t tinymodel_run(const int16_t* input, int8_t* output) { // 关键推理循环，必须在 RAM 中执行以规避 Flash 等待周期 }

而drivers/adc/adc_stm32.c里则有：

__attribute__((section(".fast_data"))) static uint16_t adc_buffer[256]; // ADC DMA 直接写入此缓冲区，需 Cache 可用

这些自定义段不是装饰品。它们对应着 STM32F407 的 SRAM 分区特性：

实测数据：在16kHz采样率下，MFCC 特征提取耗时2.1ms（Flash 执行） vs0.8ms（.ram_code执行）。差距来自 Flash 的120ns读取延迟 vs CCM RAM 的0ns。但代价是——CCM RAM 不能被 DMA 访问！所以adc_buffer必须放在.fast_data，而tinymodel_run()的中间变量又必须放在.fast_data，这就要求你在STM32F407VGTx_FLASH.ld里精确划分：

_ccm_ram_start = 0x10000000; _ccm_ram_size = 64K; _ram_start = 0x20000000; _ram_size = 128K; SECTIONS { .ram_code (NOLOAD) : { *(.ram_code) } > CCM_RAM .fast_data (NOLOAD) : { *(.fast_data) } > RAM .stack (NOLOAD) : { *(.stack) } > RAM }

注意：NOLOAD属性意味着这些段不占用 Flash 空间，只在 RAM 中分配。如果你忘了加NOLOAD，链接器会试图把.ram_code内容也塞进 Flash，导致LENGTH不足报错。

2.3 中断向量表：从startup_stm32f407xx.s到NVIC_SetPriority()的信任链

platform/stm32f407xx/startup_stm32f407xx.s是整个系统的信任根。它的向量表定义了所有中断的入口地址：

__Vectors: .word _estack .word Reset_Handler .word NMI_Handler .word HardFault_Handler .word MemManage_Handler .word BusFault_Handler .word UsageFault_Handler .word 0 .word 0 .word 0 .word SVC_Handler .word DebugMon_Handler .word 0 .word PendSV_Handler .word SysTick_Handler .word WWDG_IRQHandler /* Window Watchdog */ .word PVD_IRQHandler /* PVD through EXTI Line detect */ .word TAMP_STAMP_IRQHandler /* Tamper and Time Stamp */ .word RTC_WKUP_IRQHandler /* RTC Wakeup */ .word FLASH_IRQHandler /* FLASH */ .word RCC_IRQHandler /* RCC */ .word EXTI0_IRQHandler /* EXTI Line 0 */ .word EXTI1_IRQHandler /* EXTI Line 1 */ .word EXTI2_IRQHandler /* EXTI Line 2 */ .word EXTI3_IRQHandler /* EXTI Line 3 */ .word EXTI4_IRQHandler /* EXTI Line 4 */ .word DMA1_Stream0_IRQHandler /* DMA1 Stream 0 */ .word DMA1_Stream1_IRQHandler /* DMA1 Stream 1 */ .word DMA1_Stream2_IRQHandler /* DMA1 Stream 2 */ .word DMA1_Stream3_IRQHandler /* DMA1 Stream 3 */ .word DMA1_Stream4_IRQHandler /* DMA1 Stream 4 */ .word DMA1_Stream5_IRQHandler /* DMA1 Stream 5 */ .word DMA1_Stream6_IRQHandler /* DMA1 Stream 6 */ .word ADC_IRQHandler /* ADC1, ADC2 and ADC3s */ .word CAN1_TX_IRQHandler /* CAN1 TX */ .word CAN1_RX0_IRQHandler /* CAN1 RX0 */ .word CAN1_RX1_IRQHandler /* CAN1 RX1 */ .word CAN1_SCE_IRQHandler /* CAN1 SCE */ .word EXTI9_5_IRQHandler /* External Line[9:5] */ .word TIM1_BRK_TIM9_IRQHandler /* TIM1 Break and TIM9 */ .word TIM1_UP_TIM10_IRQHandler /* TIM1 Update and TIM10 */ .word TIM1_TRG_COM_TIM11_IRQHandler /* TIM1 Trigger and Commutation and TIM11 */ .word TIM1_CC_IRQHandler /* TIM1 Capture Compare */ .word TIM2_IRQHandler /* TIM2 */ .word TIM3_IRQHandler /* TIM3 */ .word TIM4_IRQHandler /* TIM4 */ .word I2C1_EV_IRQHandler /* I2C1 Event */ .word I2C1_ER_IRQHandler /* I2C1 Error */ .word I2C2_EV_IRQHandler /* I2C2 Event */ .word I2C2_ER_IRQHandler /* I2C2 Error */ .word SPI1_IRQHandler /* SPI1 */ .word SPI2_IRQHandler /* SPI2 */ .word USART1_IRQHandler /* USART1 */ .word USART2_IRQHandler /* USART2 */ .word USART3_IRQHandler /* USART3 */ .word EXTI15_10_IRQHandler /* External Line[15:10] */ .word RTC_Alarm_IRQHandler /* RTC Alarm (A and B) through EXTI Line 17 */ .word OTG_FS_WKUP_IRQHandler /* USB OTG FS Wakeup through EXTI Line 18 */ .word TIM8_BRK_TIM12_IRQHandler /* TIM8 Break and TIM12 */ .word TIM8_UP_TIM13_IRQHandler /* TIM8 Update and TIM13 */ .word TIM8_TRG_COM_TIM14_IRQHandler /* TIM8 Trigger and Commutation and TIM14 */ .word TIM8_CC_IRQHandler /* TIM8 Capture Compare */ .word DMA1_Stream7_IRQHandler /* DMA1 Stream 7 */ .word FSMC_IRQHandler /* FSMC */ .word SDIO_IRQHandler /* SDIO */ .word TIM5_IRQHandler /* TIM5 */ .word SPI3_IRQHandler /* SPI3 */ .word UART4_IRQHandler /* UART4 */ .word UART5_IRQHandler /* UART5 */ .word TIM6_DAC_IRQHandler /* TIM6 and DAC1&2 underrun errors */ .word TIM7_IRQHandler /* TIM7 */ .word DMA2_Stream0_IRQHandler /* DMA2 Stream 0 */ .word DMA2_Stream1_IRQHandler /* DMA2 Stream 1 */ .word DMA2_Stream2_IRQHandler /* DMA2 Stream 2 */ .word DMA2_Stream3_IRQHandler /* DMA2 Stream 3 */ .word DMA2_Stream4_IRQHandler /* DMA2 Stream 4 */ .word CAN2_TX_IRQHandler /* CAN2 TX */ .word CAN2_RX0_IRQHandler /* CAN2 RX0 */ .word CAN2_RX1_IRQHandler /* CAN2 RX1 */ .word CAN2_SCE_IRQHandler /* CAN2 SCE */ .word OTG_FS_IRQHandler /* USB OTG FS */ .word DMA2_Stream5_IRQHandler /* DMA2 Stream 5 */ .word DMA2_Stream6_IRQHandler /* DMA2 Stream 6 */ .word DMA2_Stream7_IRQHandler /* DMA2 Stream 7 */ .word USART6_IRQHandler /* USART6 */ .word I2C3_EV_IRQHandler /* I2C3 Event */ .word I2C3_ER_IRQHandler /* I2C3 Error */ .word OTG_HS_EP1_OUT_IRQHandler /* USB OTG HS End Point 1 Out */ .word OTG_HS_EP1_IN_IRQHandler /* USB OTG HS End Point 1 In */ .word OTG_HS_WKUP_IRQHandler /* USB OTG HS Wakeup */ .word OTG_HS_IRQHandler /* USB OTG HS */ .word DCMI_IRQHandler /* DCMI */ .word CRYP_IRQHandler /* CRYP crypto */ .word HASH_RNG_IRQHandler /* Hash and Rng */ .word FPU_IRQHandler /* FPU */

注意第 41 行ADC_IRQHandler—— 这就是你的麦克风数据入口。但ADC_IRQHandler在drivers/adc/adc_stm32.c中被弱定义：

void ADC_IRQHandler(void) __attribute__((weak)); void ADC_IRQHandler(void) { // 默认空实现，用户需在 application/ 中重定义 }

真正的处理逻辑在application/audio_input.c：

extern void ADC_IRQHandler(void) { if (__HAL_ADC_GET_FLAG(&hadc1, ADC_FLAG_EOC)) { // 读取 ADC_DR 寄存器 uint16_t sample = HAL_ADC_GetValue(&hadc1); // 写入 .fast_data 缓冲区 adc_buffer[buffer_index++] = sample; if (buffer_index >= 256) buffer_index = 0; } }

这里的关键是：HAL_ADC_GetValue()内部调用READ_REG(ADC->DR)，而ADC->DR地址是0x4001204C。如果你在platform/stm32f407xx/stm32f4xx_hal_conf.h中启用了HAL_ADC_MODULE_ENABLED，HAL 库会初始化 ADC 时设置ADC_CR2_CONT位，使 ADC 进入连续转换模式。但ADC_IRQHandler的优先级必须高于DMA1_Stream0_IRQHandler（因为 DMA 也在搬运 ADC 数据），否则 DMA 请求会抢占 ADC 中断，导致采样丢失。这通过NVIC_SetPriority(ADC_IRQn, 5)设置，而5这个值必须小于DMA1_Stream0_IRQn的优先级（通常设为6）。

3. 静态评测实战：用三类工具穿透 1278 行 C 代码的每一层

3.1 第一层：cppcheck—— 揭露内存泄漏与未定义行为的显微镜

cppcheck是静态分析的基石，但它需要正确配置才能在嵌入式场景下有效。直接cppcheck --enable=all ./core/会报出 200+ 警告，其中 90% 是误报（比如对__attribute__的不理解）。我们必须定制规则：

# 创建自定义配置 cppcheck.cfg cat > cppcheck.cfg << 'EOF' <?xml version="1.0"?> <def> <function name="HAL_ADC_GetValue"> <arg nr="1"> <not-uninit/> </arg> </function> <function name="memset"> <arg nr="1"> <not-null/> </arg> </function> </def> EOF cppcheck --config-exclude=platform/ \ --suppress=uninitvar:core/feature/mfcc.c:187 \ --suppress=memleak:core/inference/tinymodel.c:45 \ --library=cppcheck.cfg \ --platform=unix64 \ --enable=warning,style,performance,portability \ --inconclusive \ ./core/

重点检查项及修复：

1. core/feature/mfcc.c第 187 行：

   int16_t mfcc_buffer[128]; memset(mfcc_buffer, 0, sizeof(mfcc_buffer)); // cppcheck 报 warning: uninitvar

   原因：mfcc_buffer是栈变量，memset前未初始化，但memset本身会覆盖。cppcheck误判。解决方案：添加--suppress=uninitvar:core/feature/mfcc.c:187，或改用int16_t mfcc_buffer[128] = {0};（更安全）。

2. core/inference/tinymodel.c第 45 行：

   int8_t* weights = malloc(model_size); // cppcheck 报 error: memleak

   原因：malloc分配的内存未被free。但在嵌入式环境，malloc实际被重定向到静态内存池（见platform/stm32f407xx/system_stm32f4xx.c中的_sbrk实现）。cppcheck不知道这点。解决方案：确认platform/下存在malloc重定义，并在cppcheck.cfg中声明：

   <function name="malloc"> <use-retval/> </function>

3. drivers/adc/adc_stm32.c第 89 行：

   uint32_t timeout = HAL_MAX_DELAY; while (!(__HAL_ADC_GET_FLAG(&hadc1, ADC_FLAG_EOC)) && (timeout-- > 0));

   cppcheck报dangerous usage of 'timeout'—— 因为HAL_MAX_DELAY是0xFFFFFFFF，timeout--会导致无符号整数回绕。实际代码中，timeout会被HAL_GetTick()替换，但cppcheck看不到宏展开。解决方案：用for (uint32_t i = 0; i < 10000; i++)替代。

3.2 第二层：coccinelle—— 自动化重构的手术刀

coccinelle用于发现模式化缺陷。我们编写kws_rules.cocci：

// 规则1：检测未校验的 ADC 读取 @@ expression e; @@ - HAL_ADC_GetValue(e) + ({ uint16_t _val = HAL_ADC_GetValue(e); \ if (_val == 0xFFFF) { /* ADC 过载 */ \ handle_adc_overflow(); \ } \ _val; }) // 规则2：检测未对齐的指针访问 @@ type T; T* t; @@ - *t + ({ \ if (((uintptr_t)t & (sizeof(T)-1)) != 0) { \ handle_unaligned_access((uintptr_t)t); \ } \ *t; })

运行：

spatch --sp-file kws_rules.cocci --in-place ./drivers/adc/adc_stm32.c

结果：adc_stm32.c中 3 处HAL_ADC_GetValue()被自动包裹，新增溢出处理；core/feature/mfcc.c中 1 处int16_t* ptr解引用被加固。这比人工 review 快 10 倍，且保证一致性。

3.3 第三层：ctags+cscope—— 构建代码关系图谱的考古学

ctags和cscope不是独立工具，而是构建代码认知地图的基础设施。在项目根目录执行：

ctags -R --fields=+niaz --c-kinds=+p --c++-kinds=+p --language-force=C . cscope -Rbqk

然后在 Vim 中：

• Ctrl-]跳转到符号定义
• :ts查看所有符号引用
• :cs find g HAL_ADC_GetValue查找所有调用点

关键发现：

• HAL_ADC_GetValue()被drivers/adc/adc_stm32.c、testbench/test_mfcc.c、application/audio_input.c三处调用，但只有audio_input.c中的调用在 ISR 里，其他两处在 Host 端仿真，无需考虑实时性。
• tinymodel_run()的调用链：application/kws_main.c→core/inference/tinymodel.c→middleware/cmsis/arm_rfft_fast_f32.c→platform/stm32f407xx/system_stm32f4xx.c。这意味着 RFFT 函数的性能直接受system_stm32f4xx.c中SystemCoreClock设置影响——如果SystemCoreClock被误设为84MHz（实际是168MHz），RFFT 的arm_rfft_fast_f32会因时钟分频错误导致计算偏差。

实操心得：我曾在一个项目中发现tinymodel_run()返回值始终为0。用cscope追踪发现，arm_rfft_fast_f32()内部调用的arm_cfft_radix4_f32()依赖SystemCoreClock计算 twiddle factor。而platform/stm32f407xx/system_stm32f4xx.c中SystemCoreClock被硬编码为168000000，但实际 PLL 配置只输出84MHz。修正system_stm32f4xx.c后，唤醒率从 41% 提升到 89%。

4. 核心模块深度解析：MFCC、量化、推理引擎的魔鬼细节

4.1 MFCC 特征提取：从 16-bit PCM 到 12-Dim 向量的 17 步炼金术

core/feature/mfcc.c是整个 KWS 的瓶颈所在。它把 16kHz 采样率的int16_tPCM 流，转换为 12 维 MFCC 向量。流程如下：

1. 预加重（Pre-emphasis）：y[n] = x[n] - 0.97 * x[n-1]，提升高频分量。系数0.97是经验值，但mfcc.c中写死为0.97f，未做定点化。在 Cortex-M4 上，float运算比int32_t慢 3 倍。应改为y[n] = (x[n] << 7) - ((x[n-1] * 124) >> 7)（0.97 ≈ 124/128）。

2. 分帧（Framing）：25ms 帧长 →400个采样点（16000 * 0.025）。mfcc.c使用#define FRAME_LEN 400，但未校验FRAME_LEN是否为 2 的幂。CMSIS-DSP 的arm_rfft_fast_f32()要求输入长度为 2 的幂，否则会崩溃。FRAME_LEN必须是512或256，400是非法值！修复：#define FRAME_LEN 512，并在preemphasis后补零。

3. 加窗（Windowing）：汉明窗w[n] = 0.54 - 0.46 * cos(2πn/(N-1))。mfcc.c用查表法，但表大小256，而FRAME_LEN=512，导致索引越界。应动态生成窗函数或扩大查表尺寸。

4. FFT（Fast Fourier Transform）：调用arm_rfft_fast_f32()。关键参数：

   arm_rfft_fast_instance_f32 S; arm_rfft_fast_init_f32(&S, 512); // 必须与 FRAME_LEN 一致 arm_rfft_fast_f32(&S, frame, fft_out, 0); // 0 表示正向变换

   fft_out是复数数组，长度512，但arm_rfft_fast_f32输出的是512个实数（前半实部，后半虚部），需手动重组。

5. Mel 滤波器组（Mel Filter Bank）：core/feature/mel_filterbank.c定义了20个三角滤波器。每个滤波器覆盖f_low=0Hz到f_high=8000Hz。计算公式：

   m(k) = 1127 * ln(1 + f(k)/700)

   mfcc.c中f(k)用k * (sample_rate / FRAME_LEN)计算，但sample_rate是16000，FRAME_LEN是512，k最大255，f(255)=7968Hz，刚好覆盖。但mel_filterbank.c的filterbank[20][129]数组，第二维129来自FFT_SIZE/2 + 1 = 256 + 1，而FRAME_LEN=512时，FFT_SIZE/2 + 1 = 257，数组越界！修复：#define MEL_FILTERBANK_SIZE 257。

6. 对数能量（Log Energy）：log10(sum(pow(abs(fft_bin), 2)))。mfcc.c用arm_log10_f32()，但该函数在CMSIS-DSP v1.8.0中有精度 bug（x<1e-6时返回NaN）。应改用arm_sqrt_f32()+arm_log10_f32()组合，或直接查表。

7. DCT（Discrete Cosine Transform）：arm_dct4_f32()计算 12 阶 DCT。mfcc.c中#define NUM_CEPS 12，但arm_dct4_f32要求输入长度为2^N，12不合法。必须用arm_dct4_init_f32(&S, 16)初始化，然后截取前 12 个系数。

注意：以上 7 步中，步骤 2、4、5、7 的参数必须严格匹配。FRAME_LEN=512→FFT_SIZE=512→MEL_FILTERBANK_SIZE=257→DCT_SIZE=16。任何一处不匹配，都会导致 MFCC 向量失真，模型无法识别。

4.2 量化策略：INT8 与 INT16 的生存抉择

tools/quantize/quantize.py是模型压缩的核心。它把训练好的 FP32 模型转换为 INT8 权重。关键参数：

# quantize.py def quantize_weights(weights, scale, zero_point): # weights: FP32 numpy array # scale: FP32, 例如 0.00392156862745098 (1/255) # zero_point: INT32, 例如 128 q_weights = np.round(weights / scale + zero_point).astype(np.int8) return q_weights

问题在于：scale和zero_point如何确定？quantize.py默认用min-max法：

scale = (max_val - min_val) / 255.0 zero_point = int(128 - min_val / scale)

但min_val和max_val是从训练数据中统计的，而 MCU 上的实际输入 MFCC 范围可能不同。实测发现，mfcc.c输出的 MFCC 值范围是[-15.2, 28.7]，而量化脚本假设范围是[-20.0, 30.0]，导致scale偏大，INT8 表达精度不足。解决方案：在tools/testbench/中运行test_mfcc.c生成真实 MFCC 分布，用其min/max重新计算scale和zero_point。

更致命的是：core/inference/tinymodel.c中的推理引擎假设权重是int8_t，但某些层（如第一个卷积层）的输入通道数C_in=32，C_in * kernel_h * kernel_w = 32 * 3 * 3 = 288，int8_t累加和最大288 * 127 = 36576，超出int16_t范围（32767）。此时必须用int32_t累加，但tinymodel.c用int16_t acc，导致溢出。修复：在tinymodel.c中为高通道层启用int32_t累加，或降低kernel_size。

4.3 推理引擎：TinyEngine 的寄存器级优化陷阱

core/inference/tinymodel.c的核心是tinymodel_run()函数。它用纯 C 实现卷积，但关键循环被__attribute__((optimize("O3")))修饰。问题在于 GCC