Zephyr RTOS tinyML语音检测项目：微小改动致串口异常及推理卡顿

问题1：为何循环内添加延时/打印会导致串口终端无响应？ #

• 栈溢出触发系统崩溃：TFLM推理、CMSIS-DSP的MFCC计算本身会占用大量栈空间，添加k_msleep()/k_usleep()或printk()会进一步消耗栈资源，直接触发栈溢出。溢出的栈会覆盖Zephyr系统上下文（包括串口驱动的关键控制结构、线程调度数据），导致系统在启动阶段就彻底崩溃，连启动信息都无法输出。
• 上下文冲突引发死锁：如果perform_inference()运行在高优先级线程或中断上下文，调用k_msleep()这类会触发线程调度的函数，会导致调度死锁；而printk()在部分Zephyr配置下需要获取串口锁，若当前上下文无法正常获取锁，会直接引发阻塞或死锁，导致系统完全无响应。
• 内存覆盖破坏关键资源：之前曾因变量定义顺序出现类似问题，说明项目内存布局存在敏感区域。添加延时/打印后，编译生成的代码会改变内存排布，触发未定义行为（比如覆盖串口初始化的全局变量、TFLM的模型缓冲区），直接导致系统启动失败。

问题2：perform_inference()是否存在明显错误导致无法继续执行？ #

• 硬件异常触发停摆：执行到check1后停止，大概率是后续代码触发了硬 fault、总线 fault：
  • 张量越界：如果音频预处理后的输入尺寸与TFLM模型要求不匹配，访问数组越界会直接触发硬件异常，系统瞬间停摆。
  • MFCC上下文被破坏：之前因变量顺序出过问题，说明MFCC的配置变量或临时缓冲区可能被错误覆盖，导致MFCC计算过程中崩溃，而check1刚好在MFCC计算或TFLM推理启动前。
  • TFLM内存池不足：TFLM依赖静态内存池完成张量分配，如果内存池尺寸配置过小，推理时会触发内存访问错误，直接终止执行。
• 无调度点导致假死：如果perform_inference()内存在无调度点的死循环，Zephyr的低优先级线程（包括串口打印线程）无法抢占，看起来像程序停止，但添加延时/打印后触发调度，反而暴露了之前隐藏的内存问题。

问题3：微小改动引发卡顿的原因是什么？ #

• 编译优化下的内存布局敏感：Zephyr默认开启编译优化（如-O2），微小改动（函数顺序、变量定义顺序）会让编译器重新排布栈、全局变量的内存位置，刚好触发之前隐藏的栈溢出、内存越界问题。比如之前变量顺序导致MFCC出错，说明全局变量的排布存在依赖关系，某变量被覆盖后就会引发崩溃。
• 内存对齐被破坏：ARM Cortex-M系列硬件要求特定数据类型（如DSP浮点数组、TFLM张量）必须按4/8字节对齐，微小改动可能破坏内存对齐规则，触发总线错误，导致系统卡顿或崩溃。
• 静态初始化顺序异常：如果dummy.c中的函数涉及全局对象的静态初始化，调整函数顺序会改变初始化时机，导致依赖的资源（如TFLM模型缓冲区、MFCC配置参数）未完成初始化就被访问，引发未定义行为。

内容的提问来源于stack exchange，提问作者user23109979