|
|
2M的芯片,写了个程序,增加一句语音,芯片就不正常工作了。后来AI查到,是语音太多报掉了。
但是不解的是的2MB的芯片,只能放370K的语音吗? 那么4M的能放多少语音?
这个芯片存储是怎么规划的?能不能说明下?好方便我实际选型?下面AI的说法是正确的吗?如果是NV区了更改吗?怎么更改?让2M的芯片可以存更多空间。
反馈如下:
结论:对,就是 2MB Flash 不够了 — 但准确说是"静态数据把参数区(NV)压住了",不是 RAM。
机制解释(为什么差一个字就翻转):
打包布局:voice 区起始固定 0x190000,后面命令词表(user_file)紧跟在 voice 结尾向上 4K 对齐处,NV 参数区固定 0x1F0000。
语音包每跨过一个 4KB 页,命令词表整体后移 4KB。
实测:当前 voice.bin=385,918B → user_file 从 0x1EF000 到 0x1F1B5E,越界 7,006B,压进 NV 前 2 个 4K 块。
上电时 cinv_init()(SDK 源码 ci_flash_data_info.c 第231行)检测 NV 块 magic 无效 → 强制擦除 → 把命令词表尾部(0x1F0000~0x1F1B5E)一起擦掉。
命令词表内部结构:记录区到文件偏移 0x1289 结束;越界 7KB 时擦除从 0x1022 开始(记录区内)→ 解析器构建命令列表失败 → 所有命令词+唤醒词失效;越界 2.9KB 时("死机"版本)擦除从 0x2010 开始(纯文本区尾部)→ 记录区完好 → 能唤醒但学习的词条丢失。
"死机"→"死机第" 音频多约300字节,恰好把语音包顶过 0x5E000(385,024) 页界 → 表后移4KB → 越界从2.9K变7K → 翻车。这解释了"加一个字就不行"。
你修复10549是增加1,542字节 → 语音包385,918仍在坏区间 → 依旧不唤醒。方向反了,需要"减"不是"加"。
怎么判断存储用量(他们问的):
我已在工作区放好 check_flash.py,每次编译后运行: ..\toolchains\python-3.8.10-embed-win32\python.exe check_flash.py
看三个数:fw.bin 总大小 ≤ 0x1F0000(2,031,616B / 1984KB);user_file end ≤ 0x1F0000;voice.bin ≤ 0x5D000(380,928B) 才能保证命令词表不越界(当前385,918,需减 ~5KB 音频)。
也可以直接看编译输出 user_code.bin 大小(代码RAM/Flash部分)。
减肥建议(不改程序逻辑,只给方向): 最长的提示音 TOP: 10501(10,398)、10001(9,966)、10539(9,534)、10553(7,446)、10421(7,374)、10544(5,934)... 缩短前5条文案即可腾出 ~25KB;删除不用的 playid;水温四条(2,910×4)可用播数字替代省 ~8KB。给用户选择权,不动手。
|
|