音频算法移植与算法高效协同开发方法论

你的理解完全正确：**算法在 Linux 端运行正常，但移植到音箱的 RTOS 后出现死机重启，这是典型的跨平台移植问题**。算法团队改动较多，而你作为嵌入式集成方不清楚具体修改点，导致风险不可控。下面提供一套**高效移植的方法论**，以及针对当前死机的快速解决思路。

一、为什么 Linux 正常而 RTOS 死机？

|--------|-----------|--------------------------|----------|

**结论**：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 清零，进而引发指针错乱。

立即执行以下三步（不需要理解算法细节）：

**修复段属性**（见上一轮回答中的 `sed` 命令或手动修改）。
**增大 yj_kws 任务栈**（从 2KB 至少增加到 4KB）。
**暂时禁用 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` 段的内容，可以进一步精准定位。

音频算法移植与算法高效协同开发方法论

一、为什么 Linux 正常而 RTOS 死机？

二、高效移植方法论（减少风险）

1. **分阶段集成，每一步都验证**

2. **接口隔离与平台抽象层（PAL）**

3. **内存预算与静态分配**

4. **栈分析工具**

5. **异常捕获与日志增强**

6. **最小化复现环境**