音频算法移植与算法高效协同开发方法论
你的理解完全正确：**算法在 Linux 端运行正常，但移植到音箱的 RTOS 后出现死机重启，这是典型的跨平台移植问题**。算法团队改动较多，而你作为嵌入式集成方不清楚具体修改点，导致风险不可控。下面提供一套**高效移植的方法论**，以及针对当前死机的快速解决思路。
---
## 一、为什么 Linux 正常而 RTOS 死机？
| 差异点 | Linux 环境 | RTOS 环境（杰里 AC7016） | 潜在风险 |
|--------|-----------|--------------------------|----------|
| 内存管理 | MMU + 虚拟内存，堆栈动态扩展，访问越界通常只 segment fault | 无 MMU 或固定映射，栈空间固定且较小，越界直接覆盖关键数据 | **栈溢出、堆破坏** |
| 任务调度 | 进程/线程，栈空间通常 8MB+ | 任务栈通常 2~4KB，且任务数量多 | 栈溢出导致死机 |
| 库函数 | glibc 功能完整 | 嵌入式 libc（如 newlib）可能裁剪 | 某些函数行为不一致 |
| 浮点运算 | 硬件 FPU 或软件模拟 | 可能无 FPU 或需特殊编译选项 | 浮点异常 |
| 内存对齐 | 自动对齐 | 需要手动指定对齐（如 `ALIGNED`） | 未对齐访问异常 |
| 段属性 | 无特殊要求 | 需要 `AT()` 指定内存段（如 `.asr.save`、`.bss`） | **段错误导致数据被清零** |
| 调试手段 | gdb、valgrind 丰富 | 仅日志、有限仿真器 | 问题难以定位 |
**结论**：RTOS 对内存、栈、对齐的要求更苛刻，算法在 Linux 下的“侥幸正常”往往掩盖了这些隐患。
---
## 二、高效移植方法论（减少风险）
### 1. **分阶段集成，每一步都验证**
不要一次性合并所有算法改动，而是按功能拆分：
| 阶段 | 集成内容 | 验证目标 |
|------|----------|----------|
| 阶段0 | 空函数桩（只返回成功） | 确认集成流程、编译链接、任务创建正常 |
| 阶段1 | 仅 KWS 模块（无 AEC、无 VAD） | 测试基础唤醒功能，确保无崩溃 |
| 阶段2 | KWS + AEC（无 NS、无其他后处理） | 测试回声消除稳定性 |
| 阶段3 | 全功能 | 压力测试 |
**每阶段至少运行 24 小时压力测试**（连续唤醒、播放音乐同时唤醒等）。
### 2. **接口隔离与平台抽象层（PAL）**
为算法定义清晰的平台接口，封装所有 OS 相关调用：
```c
// pal.h
void* pal_malloc(size_t size);
void pal_free(void* ptr);
void pal_printf(const char* fmt, ...);
void* pal_thread_create(const char* name, void (*entry)(void*), void* arg, size_t stack_size);
void pal_sleep_ms(uint32_t ms);
// 内存段属性也通过宏抽象
#if defined(RTOS_JIELLI)
#define ALGO_DATA_SAVE __attribute__((section(".asr.save")))
#else
#define ALGO_DATA_SAVE
#endif
```
算法内部**严禁直接调用 `malloc`、`printf`、`memcpy` 等**，统一通过 PAL 调用。这样移植时只需修改 PAL 实现，算法代码零改动。
### 3. **内存预算与静态分配**
- 要求算法团队提供**最大内存使用量**（包括临时缓冲、模型权重、状态变量）。
- 在 RTOS 中**全部静态分配**（避免堆碎片），并使用专用内存段（如 `.asr.matrix`、`.asr.save`）。
- 增加内存边界检查：在每个 buffer 前后添加 guard bytes，定期校验。
```c
#define GUARD_SIZE 4
static uint32_t guard = 0xDEADBEEF;
void* algo_alloc(size_t size) {
uint8_t *p = (uint8_t*)pal_malloc(size + GUARD_SIZE*2);
*(uint32_t*)p = guard;
*(uint32_t*)(p + size + GUARD_SIZE) = guard;
return p + GUARD_SIZE;
}
void algo_check(void *ptr) {
uint32_t *p = (uint32_t*)((uint8_t*)ptr - GUARD_SIZE);
if (*p != guard || *(p + size/4 + 1) != guard) pal_printf("Memory corrupted!\n");
}
```
### 4. **栈分析工具**
- 为每个算法任务**增加栈溢出检测**：在任务栈底填充 magic number（如 `0xABABABAB`），定期检查是否被改写。
- 使用 RTOS 提供的栈使用率统计（如 uCOS 的 `OSTaskStkChk`，FreeRTOS 的 `uxTaskGetStackHighWaterMark`）。
- **初始栈大小至少翻倍**，稳定后再逐步减小。
### 5. **异常捕获与日志增强**
- 在 RTOS 异常处理中打印 RETS/RETI，并自动输出**调用栈**（如果有栈回溯功能）。
- 在算法每个入口/出口增加**状态日志**（如 `[ALGO] enter KWS process`、`[ALGO] exit AEC`），便于定位死机发生的函数。
- 利用 `sdk.lst` 将 RETS/RETI 解析为函数名（使用 `addr2line` 或手动对照）。
### 6. **最小化复现环境**
当死机发生时，**创建一个最小工程**：只保留算法任务 + 必要的驱动（如 MIC 输入、DAC 输出），去掉蓝牙、UI、升级等所有无关功能。这样能快速判断是算法本身问题还是与其他模块冲突。
---
## 三、当前死机问题的快速解决路径
根据你之前提供的异常信息（RETS=0x12085E 在 `get_task_info_handle`，RETI=0x120946 在 `vcopy_`），可以确定：
- **死机根因**：某个任务 TCB 或堆内存被写坏，导致系统在执行任务切换或内存复制时访问非法地址。
- **最可能的元凶**：ET 模块中 `AT(.bss.my_et_buf)` 错误使用，导致已初始化变量被 BSS 清零，进而引发指针错乱。
### 立即执行以下三步（不需要理解算法细节）：
1. **修复段属性**（见上一轮回答中的 `sed` 命令或手动修改）。
2. **增大 yj_kws 任务栈**（从 2KB 至少增加到 4KB）。
3. **暂时禁用 AEC 功能**（在配置中 `#define ET_ASR_UI_AEC_TYPE 0`），只保留 KWS。
如果仍死机，继续禁用 KWS（仅保留空任务），确认基础系统稳定。然后逐步开启功能，定位到具体哪个算法模块导致问题。
### 与算法团队的协作要求
要求算法团队提供：
- **内存布局表**：每个全局变量的大小、预期内存段（`.data`、`.bss`、专用段）。
- **栈深度估算**：每个线程/任务的最大栈使用量（可通过 Linux 下 `valgrind --tool=stackgrind` 或静态分析）。
- **单元测试套件**：在 Linux 下编译时启用 `-fsanitize=address` 和 `-fsanitize=undefined`，确保无内存越界和未定义行为。
- **接口文档**：所有外部调用的函数、参数含义、返回值、可重入性。
---
## 四、长期建议：建立 CI 环境
在 RTOS 模拟器（如 QEMU 模拟杰里 CPU）上运行算法单元测试，或使用 **硬件在环测试**（每天自动编译烧录，运行冒烟测试）。这样任何算法改动都会立即触发崩溃，倒逼算法团队在合入前修复兼容性问题。
---
## 总结
你的描述完全准确。高效移植的关键是 **分阶段集成 + 平台抽象层 + 内存/栈保护 + 快速定位工具**。对于当前死机，按上述“立即执行三步”大概率能解决。如果问题依然，请提供修改后的 `sdk.lst` 中 `.bss.my_et_buf` 和 `.asr.save` 段的内容，可以进一步精准定位。