CH582M Flash 存储与 SNV 详解¶

芯片型号：CH582M / CH583 / CH592 等 CH58x 系列
主题：片上 Flash 分区地图、BLE SNV 配对绑定机制、外接存储扩展方案
学习状态：🚧 原理已整理，待代码验证
更新日期：2026年7月18日

⚠️ 这是踩坑重灾区，也是 CH58x 系列最核心的"非直观"设计之一。建议通读本节后再动手写 Flash 相关代码。

1. 整片 Flash 地址映射总览¶

CH582M / CH583M 的 Flash 总容量为 512 KB（0x00000000 ~ 0x0007FFFF），物理上就是同一块 Flash，沁恒通过地址划分人为定义了 4 个功能区域：

📌 关键认知：CodeFlash 和 DataFlash 只是同一物理 Flash 的不同地址段，不是两块独立的芯片。它们的差异是沁恒在 SDK 里做了不同的接口封装（CodeFlash 带内核加解密，DataFlash 不加）。

2. CodeFlash 内部分区（BLE 例程视角）¶

在官方 BLE 例程中，CodeFlash 的 448 KB 并非全给用户程序，实际被划分如下：

💡 这意味着：如果你不需要 OTA 功能，理论上可以把 imageA (OTA) 这 152 KB 腾出来给主程序或数据存储。但注意——这涉及到修改链接脚本和启动文件，不是开箱即用。

3. DataFlash 内部细分手册（避坑用）¶

DataFlash 只有 32 KB（0x70000 ~ 0x77FFF），但 BLE 协议栈会自动占用尾部区域，用户可用的其实更少：

⚠️ 血泪教训：如果你往 0x7E00 之后写自己的数据，会导致 BLE 配对信息丢失，下次连接手机需要重新配对！

4. CodeFlash vs DataFlash 操作差异¶

5. Flash 擦写寿命与时间开销¶

实测：擦 1 字节和擦 4 KB 耗时几乎一样（都是 ~17 ms），因为最小擦除单位是 4 KB。写 1 字节也要 ~2 ms。所以 Flash 操作要尽量批量、减少擦写次数。

6. BLE SNV — 配对绑定信息存储（避坑重点）¶

SNV（Secure Non-Volatile） 是 BLE 协议栈用来保存配对绑定（Pairing & Bonding）信息的关键区域。这块区域躲藏在 DataFlash 尾部，新手很容易误写进去导致连接异常。

6.1 什么是配对绑定？¶

CH582M 的 BLE 协议栈在首次配对成功后，会把密钥信息（LTK、IRK、设备地址等）写入 SNV 区域。如果 SNV 被擦除或覆盖，下次手机连接时会拒绝重连（错误码 0x13：主机拒绝配对），必须删除手机端的配对记录重新配对。

6.2 SNV 在 DataFlash 中的位置¶

根据官方 EVT 包中的 CONFIG.h 定义：

#define BLE_SNV_ADDR    0x00077000   // 实质 Flash 地址
#define BLE_SNV_SIZE    0x00001000   // 分配大小 4 KB（注意：实际有效约 512 B ~ 1 KB）

但这里有个坑——0x77000 是实质地址，DataFlash 的接口函数使用的是偏移地址（减去 0x70000），所以偏移地址是 0x7000。

更常见的 EVT 版本实际使用：

#define BLE_SNV_ADDR    0x00077E00   // 实质地址，对应偏移 0x7E00

⚠️ 血泪教训：不同版本的 EVT 包、不同芯片型号（CH582/CH583/CH592），SNV 地址可能不同。务必以你当前工程 CONFIG.h 或 app_mesh_config.h 中的宏定义为准！

6.3 一次配对实际占用多少字节？¶

实测（从 DataFlash 写入记录推算）：

• 单次配对成功后的密钥数据约 224 B
• BLE 协议栈按 256 B 块 对齐存储
• 所以 BLE_SNV_SIZE = 0x1000 (4 KB) 看似很多，实际可能支持 8~16 次配对记录，或用于不同用途分区

如果你需要连接多台主机并回连（比如一个蓝牙键盘要连 3 台电脑），可以动态切换 SNV 地址实现——每次切换广播 MAC 地址时，同时切换对应的 SNV 存储区，每台主机的配对信息互不干扰。

6.4 SNV 相关操作禁忌¶

6.5 释放 SNV 空间的方法¶

如果你不需要 BLE 配对功能（比如广播传感器数据，任何手机都能连，不做安全认证）：

1. 在 CONFIG.h 中查找配对使能宏，如 BLE_BONDING_ENABLE 或 SNV_ENABLE
2. 关闭后，SNV 区域变为普通 DataFlash 可用空间
3. 但注意：关闭配对后，BLE 连接将没有加密，在敏感场景（如键鼠）不建议

💡 一句话：SNV 是 BLE 的"通讯录"，别乱动。要动之前先确认你的配对策略，再决定要不要释放这块空间。

6.6 SNV 绑定设备数量上限 — 128 个的真相¶

来自论坛官方技术支持（WCH TECH_Lpc）的确认：

CH592 的 BLE_SNV_NUM 最大值为 32 × 4 = 128 个，改宏与 BLE_SNV_ADDR 配合使用，每 256 字节可以多存放一个设备。

算术验证¶

结论：128 个绑定的理论上限是 32 KB DataFlash 全部给 SNV 用时实现的。

但"理论上"不等于"实际工程可用"¶

实际工程建议¶

📌 核心认知：Deepseek 说的"理论上最多 128 个"数字本身是对的，但隐含的"全占 DataFlash"条件必须明确。实际工程中，128 个绑定 = 放弃 MESH、放弃 OTA DataFlash 标志、放弃所有用户数据存储——绝大多数场景下做不到。按需调整 BLE_SNV_NUM，不要盲从理论上限。

7. 能扩展 Flash 容量吗？¶

实用策略：

1. CodeFlash 不够：如果程序超过 152 KB（APP 区），要么换 CH585（128 KB SRAM，但 CodeFlash 也是 448 KB），要么优化代码、关闭不需要的 BLE 功能，或者外接 SPI Flash 存储大资源（如字库、图片）。
2. DataFlash 不够：32 KB 对于配置参数、历史数据很快会满。推荐做法：
3. 频繁变化的数据 → 外接 SPI Flash（如 W25Q128，16 MB）
4. 小量配置参数 → 用 DataFlash 的 0x3000 ~ 0x6FFF 区域（约 16 KB 可用）
5. 极简配置 → 直接复用 OTA 标志位附近的空闲区（谨慎）
6. RAM 不够：32 KB SRAM 跑 BLE 协议栈后只剩约 10~15 KB 给用户。如果不够，直接升级 CH585（128 KB SRAM）或 CH592（26 KB SRAM，反而更小）。

8. 外接存储扩展方案¶

既然片上 Flash 和 DataFlash 都受限于物理容量，外接存储芯片就成了扩展的核心手段。CH582M 有 1 组 SPI 和 4 组 UART，可以通过 SPI 接口挂载各种存储器。

8.1 三种主流外接存储方案对比¶

📌 核心差异：EEPROM 和 FRAM 都是字节可改写，不用先擦除；Flash 必须先擦 4 KB 再写。FRAM 的寿命和速度碾压前两者，但价格也贵。

8.2 选型决策树¶

需要存什么？
├── 配置参数（几十 ~ 几百字节）
│   ├── 更新频率低（一天几次）  →  DataFlash 或 AT24C02
│   └── 更新频率高（一秒几次）  →  FRAM（FM25L256）
├── 日志/历史数据（KB ~ MB 级）
│   ├── 只追加、不频繁擦写       →  SPI Flash（W25Q64）
│   └── 频繁覆盖、循环记录       →  SPI Flash + 磨损均衡算法
├── 字库/图片/音频资源（MB 级）
│   └── 只读、偶尔更新           →  SPI Flash（W25Q128）
└── 固件备份/OTA 包
    └── 大容量、一次性写入       →  SPI Flash（W25Q64 / W25Q128）

8.3 与 CH582M 的接口对接建议¶

8.4 实用策略：分级存储架构¶

最成熟的方案是把存储按访问频率和重要性分层：

💡 示例：一个 BLE 温湿度传感器 - DataFlash：存设备名称、广播间隔、配对密钥 - 外接 W25Q64：存 30 天的温湿度历史数据（每 10 分钟一条） - 如果需要 1 秒级高频记录 → 换 FRAM，或做 RAM 缓冲 + 定期批量写入 Flash

8.5 关于"扩展"的最终总结¶

🔑 核心心法：CH582M 的片上存储是"精打细算型"，用 DataFlash 存关键的、掉电必须保的少量配置；用外接存储兜底大容量和频繁写入。不要试图把所有东西塞进 32 KB DataFlash 里——那是给自己找不痛快。

参考文献¶

本文内容基于以下资料整理与验证：