我刚把两个小应用塞进同一块 ESP32 Flash 时踩过最狠的一次坑是这样的蓝牙配网模块正常写了个 SSID传感器记录模块在另一个小分区里正存着温度结果重启之后温度文件里混进了一段 WiFi 密码的字符串。你说数据怎么串过去的后来拆开看两个应用其实都写到同一个 SPIFFS 盘根目录了文件名还撞了车。这个标题问的就是所有 ESP32 多应用开发者迟早要面对的问题多个小应用共用一块 Flash 时怎么保证数据不串门很多人觉得“共用 Flash”就是各写各的天然互不干扰但 Flash 不是内存它是一整块按扇区擦写、按地址访问的存储介质所有应用看到的是同一个 4MB/16MB 空间。你在这个地址写他那个地址读中间没有任何硬件隔离。真正能拦住数据串门的只有你自己做对分区规划、命名空间划分、文件路径约定和写保护策略。这篇文章我按自己的实际项目经验把这一整套方法拆开讲清楚包括分区表 CSV 怎么写、NVS 命名空间怎么隔离、LittleFS 文件系统怎么挂、以及掉电之后数据怎么保住方便你直接照着抄。1. 先搞懂你的数据到底放在 Flash 的哪里1.1 一块 Flash 上的“虚拟房间”分区表ESP32 上的 Flash 虽然物理上是一整块但通过一份分区表partition table把它切成了多个区域。每个区域叫一个 partition有名字、类型、子类型、起始偏移量、大小。固件启动的时候bootloader 就是靠这张表找到 app 固件在哪、NVS 配置在哪、文件系统在哪。这一点特别像一栋楼里分房间每个房间有编号和用途你不能凭感觉随便住进去得先看房号。应用代码里找数据时也类似不是用“Flash 偏移地址 0x10000”这种裸地址而是用分区表里的名字label去查查到了才拿到那个区域的偏移和大小。这样万一你调整了分区布局只要名字不变代码基本不用改。不少刚入坑的朋友会问我直接在代码里写0x400000地址读写不行吗不是说完全不行但一旦某天加了个 OTA 分区、或者换了个 Flash 容量模组所有硬编码地址全部作废还可能直接写到别人的分区里把固件都擦掉。分区表存在的意义就是让你从“管裸地址”变成“管区域名”这是数据不串门的第一道防线。1.2 三种最容易出现的“串门”场景先对号入座。我总结的典型串门场景一共有三种分别对应不同的存储类型和失误方式场景一多个应用共用默认 NVS 分区键名冲突互相覆盖。比如 App A 用键ssid存 WiFi 名App B 可能也用ssid存自己的配置项两边都在同一个默认nvs分区里后写的一方会把先写的覆盖掉。场景二多个应用把文件堆在同一个文件系统根目录文件名完全撞车。比如一个应用写data.bin另一个应用也写data.bin没有目录分隔没有任何前缀互相覆盖甚至读到半个文件的脏数据。场景三有人自作聪明直接用某个固定 Flash 偏移地址写自定义数据结果覆盖了其他分区甚至覆盖了 app 分区。这种是最危险的不但数据串门整个固件都可能起不来。从现象上看串门往往不会当场报错而是表现为“重启之后配置丢了”“蓝牙改的名字过几天变回旧的”“OTA 升级之后设备变砖”。因为这些误导性现象特别强我排查的时候从来不看表面日志而是先确认每个应用到底在操作哪个分区、哪个路径、哪个键名。把这个“存储地图”画出来问题就清楚了一大半。2. 物理隔离用分区表给每个应用划好地盘2.1 分区表 CSV 到底怎么写字段和参数逐个解释ESP-IDF 使用一份 CSV 文件来定义分区表常见模板长这样# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x1F0000,每一个字段都有讲究Name分区的标签名代码里用这个字符串去查分区最长别超过 16 个字符自己起的名字最好一眼能看出归属比如wifi_nvs、ble_nvs、sensor_log。Typeapp表示存放固件data表示存放数据。类型不能乱写bootloader 和 OTA 组件都会检查。SubType对于data类型常见的有nvs、phy、spiffs、littlefs对于app类型常见的有factory、ota_0、ota_1。子类型决定了这个分区会被哪个组件自动识别。Offset分区起始地址。要求按 0x10004KB对齐因为 Flash 的扇区擦除单位通常是 4KB。不按对齐写烧录工具可能报错或者出现神奇的读写异常。Size分区大小同样按 0x1000 对齐。大小不够会导致文件系统挂载失败、NVS 页耗尽所以不要拍脑袋填。我的习惯是每个独立业务模块都给自己留一块专门的data分区即使它现在只需要存 8KB 配置也单独摘出来。这样后续一个应用疯狂写日志、频繁擦写也影响不到另一个应用的存储区域。你得到的隔离是物理层面上的两个分区之间没有任何交集串门的可能性直接从根上消除。2.2 一改分区表就翻车OTA 留退路的几个约束如果你要上 OTA 升级分区表的约束会多一层。OTA 通常要求factory分区出厂固件加上一对ota_0、ota_1轮换分区或者只有ota_0和ota_1。这一对 app 分区的大小必须足够容纳你的固件而且偏移量不能和数据分区重叠。这里有个很现实的坑很多人一开始只规划了一个 2MB 的factory分区后来想加 OTA又硬塞两个 2MB 分区进去发现 4MB Flash 根本装不下。我建议早期就把 OTA 占用的空间算进去。比如确定固件编译出来只有 1.2MB那给 app 分区留 1.5MB 到 2MB 相对稳妥同时logs这类数据分区也别贪大1MB 日志看起来很多实际写满要很久没必要为“万一不够”把整片 Flash 都占满。还有一条重要经验修改分区表之后最好全片擦除一次再烧新固件。因为分区表变了旧分区里残留的 NVS 键值、文件系统数据、OTA 索引都可能指向已经没有意义的位置。你不擦就可能出现“OTA 后起不来”或者“明明升级了固件却跑着旧配置”。在开发阶段改完 CSV 直接用esptool.py erase_flash清理一遍后续的排查会省心很多。2.3 代码里怎么定位属于自己的分区分区表只是“画地盘”真正访问时还要通过 ESP-IDF 提供的 API 来查。最常用的是按名字找分区const esp_partition_t *part esp_partition_find_first( ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_NVS, wifi_nvs ); if (part NULL) { ESP_LOGE(APP, wifi_nvs partition not found); return ESP_FAIL; } ESP_LOGI(APP, wifi_nvs at 0x%lx, size 0x%lx, (unsigned long)part-address, (unsigned long)part-size);拿到esp_partition_t结构体之后后续的读、写、擦除都基于这个句柄不再需要关心具体地址。这样分区表就算以后把wifi_nvs从 0x210000 挪到 0x300000代码一行都不用改只需要保证 Name 不变。从这段代码里也能看出为什么不建议用裸地址裸地址等于你把“房间号”写死在代码里哪天物业重新编号你所有的数据钥匙全废。用 label 相当于告诉物业“我要找的是厨房”物业自己会带你去正确房间这才是长期可维护的做法。3. 逻辑隔离NVS 键名前缀与命名空间3.1 namespace 就是你的“命名空间”NVSNon-Volatile Storage是 ESP32 标配的键值存储组件适合存配置项、设备状态这类零碎数据。它默认会有一个叫nvs的分区很多人图省事全往这里面塞这就埋下了串门隐患。NVS 本身提供了命名空间namespace的概念。你可以通过nvs_open打开一个 namespace比如nvs_handle_t handle; nvs_open(wifi_cfg, NVS_READWRITE, handle); nvs_set_str(handle, ssid, my_wifi); nvs_commit(handle); nvs_close(handle);另一个应用可以打开完全不同的 namespacenvs_handle_t handle; nvs_open(ble_cfg, NVS_READWRITE, handle); nvs_set_u8(handle, tx_power, 20); nvs_commit(handle); nvs_close(handle);两个 namespace 在逻辑上是互相隔离的键名之间不会冲突。注意 NVS 对名字长度有限制namespace 名称和 key 名都不能太长我记得基本在 15 个字符上下所以起名要短而清晰。不过我要提醒一点逻辑隔离不是绝对的物理隔离它们仍然住在同一个 NVS 分区里。如果分区坏了、键值被某个 bug 遍历后误删理论上还是会互相影响。所以对可靠性要求特别高的多应用场景我更喜欢用nvs_flash_init_partition()分别初始化不同的 NVS 分区再配合nvs_open_from_partition()指定分区打开这样两个应用的 NVS 数据在物理上就分开了彻底断了串门的念想。3.2 键名前缀、版本号和 CRC 校验有时候你没法完全控制别人代码里怎么用 NVS尤其在做模块集成的时候两个应用可能会被逼到同一个 namespace 下。这时就要靠键名前缀规避冲突比如模块 A 的所有键都叫wifi_ssid、wifi_passwd模块 B 的叫ble_name、ble_mac。虽然这能解决问题但只是“约定”没有强制力而且键名一长就容易超出 NVS 限制所以我只把它当过渡方案。更稳的做法是在写复杂结构体时同步写一个魔数magic number和 CRC 校验。比如我要存一个配网结构体typedef struct { uint32_t magic; // 固定填充 0xA5A5A5A5 uint32_t version; // 结构体版本号 uint16_t crc; // 对后续字段做的校验 char ssid[32]; char password[64]; } wifi_config_t;读的时候先检查 magic 对不对再算一遍 CRC 和存的值比对任何一样不符就认为数据无效走恢复流程而不是直接拿脏数据去干活。这能防的不只是串门还有掉电写一半、升级后结构体字段不兼容这些更隐蔽的问题。很多人觉得多写这几行代码没必要但我在实际项目里见过太多次“好不容易查出来的 bug 其实就是一个 CRC 没做读出了半个写入事务”。Flash 的写入不像内存赋值一个 commit 在断电时可能只完成了一半。没有校验机制你根本无法区分“正常数据”和“半截数据”这时候所谓的稳定运行就全靠运气。3.3 NVS 数据被污染的定位与恢复数据万一真串了怎么定位我一般这么做写一个调试命令遍历所有 namespace 和键值打印成可读文本一次性看全现场。ESP32 上可以用nvs_tool.py或者自己写一段遍历代码但核心思路是一样的把键值导出来看有没有不属于当前应用的“陌生键”同时检查值的字节长度是否符合预期。常见的 NVS 问题还包括nvs_flash_init返回ESP_ERR_NVS_NO_FREE_PAGES这代表分区空间已耗尽连新的 namespace 都开不出来。这时候不能只盯着代码要看 NVS 分区是不是太小、历史键是不是从来没清理过。我见过最夸张的例子是一个设备跑了一年把 24KB 默认 NVS 写满最后连 WiFi 配置都存不进去了。恢复手段上我会额外保留一个“出厂复位”入口。在代码里检查某个标志位比如 GPIO 长按或者串口命令一旦触发就调用nvs_flash_erase()清空指定 NVS 分区或者干脆只擦掉某个 namespace。这个能力在远程设备出了问题、无法手动改代码的时候特别有用不要省。4. 文件型数据LittleFS/SPIFFS 的目录隔离与分区挂载4.1 分区隔离还是目录隔离怎么选NVS 适合存结构化的键值配置但传感器历史数据、日志文件、固件升级包这类大块数据就得用文件系统了。ESP32 上常见的文件系统是 SPIFFS 和 LittleFS官方现在更推荐 LittleFS因为它有更好的目录支持和掉电恢复能力。这里先回答一个大家纠结很久的问题两个应用共用同一个文件系统分区时是开两个分区好还是在一个分区里建两个目录好我的判断标准很简单如果两个应用的写入频率都高、数据量都大就用两个独立分区各自挂到不同路径比如/app1和/app2。如果数据量很小只需要存几个文件那用一个分区、按约定建子目录也够用但前提是必须有明确的路径规范比如/mod1/xxx.bin、/mod2/xxx.bin谁也不能越界。不过目录隔离仍然是“软约定”应用写烂了照样可能删掉对方目录下的文件。想彻底防串门物理分区最保险。代价是分区表会被切碎、每块分区都会有一些空间浪费但这点浪费换来的是一整个开发阶段不用再提心吊胆值。4.2 挂载、卸载与掉电保护要点在 ESP-IDF 里挂载 LittleFS常见写法是esp_vfs_littlefs_conf_t conf { .base_path /logs, .partition_label sensor_log, .format_if_mount_failed true, .dont_mount false, }; esp_err_t ret esp_vfs_littlefs_register(conf); if (ret ! ESP_OK) { ESP_LOGE(APP, Failed to mount LittleFS (0x%x), ret); }这里的format_if_mount_failed是个危险的开关。开发阶段为了方便挂载失败自动格式化没什么问题但生产环境下我强烈建议把它设成false。因为一旦文件系统元数据损坏自动格式化会把整个分区抹掉如果这里恰好存着重要日志或另一个应用用来交换数据的关键文件那损失比“挂不上”更大。正确做法是挂载失败后停下来通过日志定位原因或者进入恢复模式让用户确认后再格式化。掉电保护也是文件系统场景里最容易翻车的一环。文件系统本身对“写入一半”没有魔法般的防御力所以我的习惯是写关键文件时先写临时文件完整写完后fflushfsync再rename成正式文件名。比如FILE *tmp fopen(/logs/data.tmp, w); fprintf(tmp, ...); fflush(tmp); fsync(fileno(tmp)); fclose(tmp); rename(/logs/data.tmp, /logs/data.bin);这样掉电最多丢一个临时文件不会把正式文件搞成半截。实测下来这套策略在多次拔电测试里基本都能保证最后读到的还是上一次完整写入的数据。4.3 分区大小怎么估算坏块怎么办很多人会把文件系统分区大小填成刚好够用结果运行一段时候后写入失败、挂载失败。问题在于文件系统本身有元数据开销Flash 还有磨损均衡和坏块管理机制。LittleFS 的空间利用率比 SPIFFS 好一些但也不是零开销。我从项目里总结的经验是分区大小取预期数据量的 23 倍比较合适。如果预计日志最多 300KB给 1MB 的 LittleFS 分区就够稳了如果预计要存 1MB 固件包那分 2MB 以上再挂进去。ESP32 内部 Flash 的扇区擦除次数有限频繁擦写同一个位置容易坏块磨损均衡也需要额外空间周转这个“富余量”不是浪费是安全垫。坏块这块我要特别提醒一句Flash 出厂本来就允许有少量坏块文件系统组件通常自带坏块管理你不需要也没必要自己去“扫描标记坏块”。更不要试图用esp_partition_erase_range去擦除自己分区之外的区域这在没有硬件保护的情况下等于裸奔真擦坏了只能换硬件。5. 一个能直接抄的完整案例三应用共享 Flash5.1 分区表设计4MB 无 OTA 版假设我现在有三个模块共存WiFi 配网配置、BLE 设备配置、传感器历史日志。开发阶段用 4MB ESP32 模组暂时不上 OTA。分区表我会这么写# Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x1F0000, wifi_nvs, data, nvs, 0x200000, 0x2000, ble_nvs, data, nvs, 0x202000, 0x2000, sensor_log, data, littlefs, 0x204000, 0x100000,每个模块独立 NVS 分区WiFi 配网只可能在wifi_nvs里写BLE 配置只可能在ble_nvs里写传感器日志挂到 LittleFS 的/sensor_log挂载点上。三个模块之间没有共享的键值区域路径也没有交集数据的“底盘”从一开始就是分开的。可能有朋友问为什么第一个nvs分区要留 24KB而且看起来没用这个分区是 ESP-IDF 系统组件比如 RF 校准数据默认使用的不能随便删删了 Wi-Fi 射频校准信息没地方放连接稳定性会受影响。5.2 初始化与访问代码骨架代码里对应初始化如下WiFi 配网模块用独立 NVS 分区ESP_ERROR_CHECK(nvs_flash_init_partition(wifi_nvs)); nvs_handle_t wifi_handle; esp_err_t err nvs_open_from_partition( wifi_nvs, wifi_cfg, NVS_READWRITE, wifi_handle ); if (err ESP_OK) { nvs_set_str(wifi_handle, ssid, my_wifi); nvs_set_str(wifi_handle, passwd, secret); nvs_commit(wifi_handle); nvs_close(wifi_handle); }BLE 模块照葫芦画瓢换成分区名ble_nvs、namespace 换成ble_cfg。这样两边的键名即使都叫name、value也永远不会冲突因为物理分区都不同。传感器日志模块挂载 LittleFSesp_vfs_littlefs_conf_t conf { .base_path /sensor_log, .partition_label sensor_log, .format_if_mount_failed true, .dont_mount false, }; ESP_ERROR_CHECK(esp_vfs_littlefs_register(conf));后续写日志就通过标准 C 文件 API落到/sensor_log/data_xxx.bin。这个路径只属于传感器模块自己其他模块按约定也不该碰这个目录。5.3 验证“数据没串门”的检查方法分区表规划和代码写完怎么确认真的没串门我开发期会做一次“暴力验证”设备正常跑一段时间后断电用esptool.py把整块 Flash 读出来esptool.py -p /dev/ttyUSB0 read_flash 0x00000 0x400000 flash_dump.bin然后用 binwalk 或者简单的strings命令看每个分区的边界在哪里搜一下 WiFi 密码字符串是否只在wifi_nvs区域出现、传感器日志文件内容是否都在sensor_log区域。这个方法土但非常直观能一眼看出有没有数据越界。还有一种更轻量的运行期验证在代码里周期性地读一下自家分区大小和家用分区大小如果发现某个分区数据量异常增长或者读到了不属于自己的文件路径立刻打印告警。我甚至会故意留一个“自检目录”让每个模块启动时往自己的分区写一个带魔法数字的状态文件其他模块读不到就算正常。6. 常见问题与排查技巧实录6.1 问题速查表现象可能原因检查与解决办法重启后 WiFi 配置丢失NVS 键未nvs_commit或键名被其他 namespace 覆盖检查每个键是否有 commit确认是否用独立分区蓝牙改的设备名过几天变回旧值两个应用用了同一个 NVS 分区且键名冲突改成独立 NVS 分区 独立 namespace传感器文件里读出乱码两个应用共享文件系统根目录文件名撞车或文件写到一半掉电分区隔离 子目录 临时文件 rename 策略OTA 升级后无法启动修改分区表后没有全片擦除旧 OTA 索引失效改分区表后执行erase_flash再烧录挂载 LittleFS 失败分区类型与组件不匹配或分区太小检查 CSV 的 SubType 是否为littlefs扩大分区nvs_flash_init返回NO_FREE_PAGESNVS 分区被历史键写满清理历史键或扩大 NVS 分区结构体数据偶尔读到异常掉电导致写入一半增加 magic CRC 校验读失败走恢复逻辑这张表基本覆盖了我这些年遇到的大部分 Flash 存储异常。你会发现绝大多数问题都不是“Flash 坏了”而是分区规划不合理、没有做写入时序控制、没有做数据校验。6.2 我踩过三次的坑和教训第一次是默认 NVS 分区被两个应用写炸了。早期为了省事所有配置都往同一个默认nvs分区里塞。后来集成一个第三方蓝牙库时发现它内部也用了 NVS而且键名恰好和我自定义的一个键重了。结果就是我每次配完 WiFi蓝牙库一启动就覆盖了我的配置项。排查花了两天最后定位到这个键名冲突时真想抽自己。教训很明确独立业务模块的配置存储要么独立 namespace要么干脆独立分区别给“恰好撞键名”留任何机会。第二次是为了方便开了自动格式化结果日志全没了。一个户外设备在运行中偶发断电文件系统挂载失败后自动把整个sensor_log分区格式化了一个月的温湿度记录全部蒸发。那次之后我彻底改了习惯生产固件绝不自动格式化挂载失败就停在那儿等人工处理并打印清晰的错误码到日志。数据丢失比暂时不可用更可怕这是做嵌入式存储必须建立的心理底线。第三次是改分区表没擦全片OTA 直接变砖。我把分区从factory模式改成 OTA 模式偏移量整体向后挪了但没擦 Flash旧分区表残留的内容和新 bootloader 读到的信息错位升级失败后设备一直起不来。这个经历告诉我分区表这东西是有“记忆”的它不随固件更新自动刷新你改了它就必须配套做全片擦除或至少擦掉旧分区表区域否则那一整片历史数据会持续作妖。真正经历过这些之后我才理解“数据串门”四个字的含金量。也建议大家从一开始就养成一个习惯每个模块有独立分区、独立 namespace、独立挂载路径哪怕初期看起来空着很多地方也别硬塞到一个区域里共享。嵌入式系统里最贵的不是 Flash 容量而是排查数据错乱时消耗的时间。按这套方法把存储规划清楚后面跑项目会省下非常多的救火时间。最后再提一个小技巧如果有条件给设备加一个“存储健康自检”功能启动时检查每个分区的魔数、容量和文件数异常时主动上报这比等到用户反馈“数据丢了”再排查要主动得多。
ESP32多应用Flash数据隔离：分区表+NVS+LittleFS避坑指南
我刚把两个小应用塞进同一块 ESP32 Flash 时踩过最狠的一次坑是这样的蓝牙配网模块正常写了个 SSID传感器记录模块在另一个小分区里正存着温度结果重启之后温度文件里混进了一段 WiFi 密码的字符串。你说数据怎么串过去的后来拆开看两个应用其实都写到同一个 SPIFFS 盘根目录了文件名还撞了车。这个标题问的就是所有 ESP32 多应用开发者迟早要面对的问题多个小应用共用一块 Flash 时怎么保证数据不串门很多人觉得“共用 Flash”就是各写各的天然互不干扰但 Flash 不是内存它是一整块按扇区擦写、按地址访问的存储介质所有应用看到的是同一个 4MB/16MB 空间。你在这个地址写他那个地址读中间没有任何硬件隔离。真正能拦住数据串门的只有你自己做对分区规划、命名空间划分、文件路径约定和写保护策略。这篇文章我按自己的实际项目经验把这一整套方法拆开讲清楚包括分区表 CSV 怎么写、NVS 命名空间怎么隔离、LittleFS 文件系统怎么挂、以及掉电之后数据怎么保住方便你直接照着抄。1. 先搞懂你的数据到底放在 Flash 的哪里1.1 一块 Flash 上的“虚拟房间”分区表ESP32 上的 Flash 虽然物理上是一整块但通过一份分区表partition table把它切成了多个区域。每个区域叫一个 partition有名字、类型、子类型、起始偏移量、大小。固件启动的时候bootloader 就是靠这张表找到 app 固件在哪、NVS 配置在哪、文件系统在哪。这一点特别像一栋楼里分房间每个房间有编号和用途你不能凭感觉随便住进去得先看房号。应用代码里找数据时也类似不是用“Flash 偏移地址 0x10000”这种裸地址而是用分区表里的名字label去查查到了才拿到那个区域的偏移和大小。这样万一你调整了分区布局只要名字不变代码基本不用改。不少刚入坑的朋友会问我直接在代码里写0x400000地址读写不行吗不是说完全不行但一旦某天加了个 OTA 分区、或者换了个 Flash 容量模组所有硬编码地址全部作废还可能直接写到别人的分区里把固件都擦掉。分区表存在的意义就是让你从“管裸地址”变成“管区域名”这是数据不串门的第一道防线。1.2 三种最容易出现的“串门”场景先对号入座。我总结的典型串门场景一共有三种分别对应不同的存储类型和失误方式场景一多个应用共用默认 NVS 分区键名冲突互相覆盖。比如 App A 用键ssid存 WiFi 名App B 可能也用ssid存自己的配置项两边都在同一个默认nvs分区里后写的一方会把先写的覆盖掉。场景二多个应用把文件堆在同一个文件系统根目录文件名完全撞车。比如一个应用写data.bin另一个应用也写data.bin没有目录分隔没有任何前缀互相覆盖甚至读到半个文件的脏数据。场景三有人自作聪明直接用某个固定 Flash 偏移地址写自定义数据结果覆盖了其他分区甚至覆盖了 app 分区。这种是最危险的不但数据串门整个固件都可能起不来。从现象上看串门往往不会当场报错而是表现为“重启之后配置丢了”“蓝牙改的名字过几天变回旧的”“OTA 升级之后设备变砖”。因为这些误导性现象特别强我排查的时候从来不看表面日志而是先确认每个应用到底在操作哪个分区、哪个路径、哪个键名。把这个“存储地图”画出来问题就清楚了一大半。2. 物理隔离用分区表给每个应用划好地盘2.1 分区表 CSV 到底怎么写字段和参数逐个解释ESP-IDF 使用一份 CSV 文件来定义分区表常见模板长这样# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x1F0000,每一个字段都有讲究Name分区的标签名代码里用这个字符串去查分区最长别超过 16 个字符自己起的名字最好一眼能看出归属比如wifi_nvs、ble_nvs、sensor_log。Typeapp表示存放固件data表示存放数据。类型不能乱写bootloader 和 OTA 组件都会检查。SubType对于data类型常见的有nvs、phy、spiffs、littlefs对于app类型常见的有factory、ota_0、ota_1。子类型决定了这个分区会被哪个组件自动识别。Offset分区起始地址。要求按 0x10004KB对齐因为 Flash 的扇区擦除单位通常是 4KB。不按对齐写烧录工具可能报错或者出现神奇的读写异常。Size分区大小同样按 0x1000 对齐。大小不够会导致文件系统挂载失败、NVS 页耗尽所以不要拍脑袋填。我的习惯是每个独立业务模块都给自己留一块专门的data分区即使它现在只需要存 8KB 配置也单独摘出来。这样后续一个应用疯狂写日志、频繁擦写也影响不到另一个应用的存储区域。你得到的隔离是物理层面上的两个分区之间没有任何交集串门的可能性直接从根上消除。2.2 一改分区表就翻车OTA 留退路的几个约束如果你要上 OTA 升级分区表的约束会多一层。OTA 通常要求factory分区出厂固件加上一对ota_0、ota_1轮换分区或者只有ota_0和ota_1。这一对 app 分区的大小必须足够容纳你的固件而且偏移量不能和数据分区重叠。这里有个很现实的坑很多人一开始只规划了一个 2MB 的factory分区后来想加 OTA又硬塞两个 2MB 分区进去发现 4MB Flash 根本装不下。我建议早期就把 OTA 占用的空间算进去。比如确定固件编译出来只有 1.2MB那给 app 分区留 1.5MB 到 2MB 相对稳妥同时logs这类数据分区也别贪大1MB 日志看起来很多实际写满要很久没必要为“万一不够”把整片 Flash 都占满。还有一条重要经验修改分区表之后最好全片擦除一次再烧新固件。因为分区表变了旧分区里残留的 NVS 键值、文件系统数据、OTA 索引都可能指向已经没有意义的位置。你不擦就可能出现“OTA 后起不来”或者“明明升级了固件却跑着旧配置”。在开发阶段改完 CSV 直接用esptool.py erase_flash清理一遍后续的排查会省心很多。2.3 代码里怎么定位属于自己的分区分区表只是“画地盘”真正访问时还要通过 ESP-IDF 提供的 API 来查。最常用的是按名字找分区const esp_partition_t *part esp_partition_find_first( ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_NVS, wifi_nvs ); if (part NULL) { ESP_LOGE(APP, wifi_nvs partition not found); return ESP_FAIL; } ESP_LOGI(APP, wifi_nvs at 0x%lx, size 0x%lx, (unsigned long)part-address, (unsigned long)part-size);拿到esp_partition_t结构体之后后续的读、写、擦除都基于这个句柄不再需要关心具体地址。这样分区表就算以后把wifi_nvs从 0x210000 挪到 0x300000代码一行都不用改只需要保证 Name 不变。从这段代码里也能看出为什么不建议用裸地址裸地址等于你把“房间号”写死在代码里哪天物业重新编号你所有的数据钥匙全废。用 label 相当于告诉物业“我要找的是厨房”物业自己会带你去正确房间这才是长期可维护的做法。3. 逻辑隔离NVS 键名前缀与命名空间3.1 namespace 就是你的“命名空间”NVSNon-Volatile Storage是 ESP32 标配的键值存储组件适合存配置项、设备状态这类零碎数据。它默认会有一个叫nvs的分区很多人图省事全往这里面塞这就埋下了串门隐患。NVS 本身提供了命名空间namespace的概念。你可以通过nvs_open打开一个 namespace比如nvs_handle_t handle; nvs_open(wifi_cfg, NVS_READWRITE, handle); nvs_set_str(handle, ssid, my_wifi); nvs_commit(handle); nvs_close(handle);另一个应用可以打开完全不同的 namespacenvs_handle_t handle; nvs_open(ble_cfg, NVS_READWRITE, handle); nvs_set_u8(handle, tx_power, 20); nvs_commit(handle); nvs_close(handle);两个 namespace 在逻辑上是互相隔离的键名之间不会冲突。注意 NVS 对名字长度有限制namespace 名称和 key 名都不能太长我记得基本在 15 个字符上下所以起名要短而清晰。不过我要提醒一点逻辑隔离不是绝对的物理隔离它们仍然住在同一个 NVS 分区里。如果分区坏了、键值被某个 bug 遍历后误删理论上还是会互相影响。所以对可靠性要求特别高的多应用场景我更喜欢用nvs_flash_init_partition()分别初始化不同的 NVS 分区再配合nvs_open_from_partition()指定分区打开这样两个应用的 NVS 数据在物理上就分开了彻底断了串门的念想。3.2 键名前缀、版本号和 CRC 校验有时候你没法完全控制别人代码里怎么用 NVS尤其在做模块集成的时候两个应用可能会被逼到同一个 namespace 下。这时就要靠键名前缀规避冲突比如模块 A 的所有键都叫wifi_ssid、wifi_passwd模块 B 的叫ble_name、ble_mac。虽然这能解决问题但只是“约定”没有强制力而且键名一长就容易超出 NVS 限制所以我只把它当过渡方案。更稳的做法是在写复杂结构体时同步写一个魔数magic number和 CRC 校验。比如我要存一个配网结构体typedef struct { uint32_t magic; // 固定填充 0xA5A5A5A5 uint32_t version; // 结构体版本号 uint16_t crc; // 对后续字段做的校验 char ssid[32]; char password[64]; } wifi_config_t;读的时候先检查 magic 对不对再算一遍 CRC 和存的值比对任何一样不符就认为数据无效走恢复流程而不是直接拿脏数据去干活。这能防的不只是串门还有掉电写一半、升级后结构体字段不兼容这些更隐蔽的问题。很多人觉得多写这几行代码没必要但我在实际项目里见过太多次“好不容易查出来的 bug 其实就是一个 CRC 没做读出了半个写入事务”。Flash 的写入不像内存赋值一个 commit 在断电时可能只完成了一半。没有校验机制你根本无法区分“正常数据”和“半截数据”这时候所谓的稳定运行就全靠运气。3.3 NVS 数据被污染的定位与恢复数据万一真串了怎么定位我一般这么做写一个调试命令遍历所有 namespace 和键值打印成可读文本一次性看全现场。ESP32 上可以用nvs_tool.py或者自己写一段遍历代码但核心思路是一样的把键值导出来看有没有不属于当前应用的“陌生键”同时检查值的字节长度是否符合预期。常见的 NVS 问题还包括nvs_flash_init返回ESP_ERR_NVS_NO_FREE_PAGES这代表分区空间已耗尽连新的 namespace 都开不出来。这时候不能只盯着代码要看 NVS 分区是不是太小、历史键是不是从来没清理过。我见过最夸张的例子是一个设备跑了一年把 24KB 默认 NVS 写满最后连 WiFi 配置都存不进去了。恢复手段上我会额外保留一个“出厂复位”入口。在代码里检查某个标志位比如 GPIO 长按或者串口命令一旦触发就调用nvs_flash_erase()清空指定 NVS 分区或者干脆只擦掉某个 namespace。这个能力在远程设备出了问题、无法手动改代码的时候特别有用不要省。4. 文件型数据LittleFS/SPIFFS 的目录隔离与分区挂载4.1 分区隔离还是目录隔离怎么选NVS 适合存结构化的键值配置但传感器历史数据、日志文件、固件升级包这类大块数据就得用文件系统了。ESP32 上常见的文件系统是 SPIFFS 和 LittleFS官方现在更推荐 LittleFS因为它有更好的目录支持和掉电恢复能力。这里先回答一个大家纠结很久的问题两个应用共用同一个文件系统分区时是开两个分区好还是在一个分区里建两个目录好我的判断标准很简单如果两个应用的写入频率都高、数据量都大就用两个独立分区各自挂到不同路径比如/app1和/app2。如果数据量很小只需要存几个文件那用一个分区、按约定建子目录也够用但前提是必须有明确的路径规范比如/mod1/xxx.bin、/mod2/xxx.bin谁也不能越界。不过目录隔离仍然是“软约定”应用写烂了照样可能删掉对方目录下的文件。想彻底防串门物理分区最保险。代价是分区表会被切碎、每块分区都会有一些空间浪费但这点浪费换来的是一整个开发阶段不用再提心吊胆值。4.2 挂载、卸载与掉电保护要点在 ESP-IDF 里挂载 LittleFS常见写法是esp_vfs_littlefs_conf_t conf { .base_path /logs, .partition_label sensor_log, .format_if_mount_failed true, .dont_mount false, }; esp_err_t ret esp_vfs_littlefs_register(conf); if (ret ! ESP_OK) { ESP_LOGE(APP, Failed to mount LittleFS (0x%x), ret); }这里的format_if_mount_failed是个危险的开关。开发阶段为了方便挂载失败自动格式化没什么问题但生产环境下我强烈建议把它设成false。因为一旦文件系统元数据损坏自动格式化会把整个分区抹掉如果这里恰好存着重要日志或另一个应用用来交换数据的关键文件那损失比“挂不上”更大。正确做法是挂载失败后停下来通过日志定位原因或者进入恢复模式让用户确认后再格式化。掉电保护也是文件系统场景里最容易翻车的一环。文件系统本身对“写入一半”没有魔法般的防御力所以我的习惯是写关键文件时先写临时文件完整写完后fflushfsync再rename成正式文件名。比如FILE *tmp fopen(/logs/data.tmp, w); fprintf(tmp, ...); fflush(tmp); fsync(fileno(tmp)); fclose(tmp); rename(/logs/data.tmp, /logs/data.bin);这样掉电最多丢一个临时文件不会把正式文件搞成半截。实测下来这套策略在多次拔电测试里基本都能保证最后读到的还是上一次完整写入的数据。4.3 分区大小怎么估算坏块怎么办很多人会把文件系统分区大小填成刚好够用结果运行一段时候后写入失败、挂载失败。问题在于文件系统本身有元数据开销Flash 还有磨损均衡和坏块管理机制。LittleFS 的空间利用率比 SPIFFS 好一些但也不是零开销。我从项目里总结的经验是分区大小取预期数据量的 23 倍比较合适。如果预计日志最多 300KB给 1MB 的 LittleFS 分区就够稳了如果预计要存 1MB 固件包那分 2MB 以上再挂进去。ESP32 内部 Flash 的扇区擦除次数有限频繁擦写同一个位置容易坏块磨损均衡也需要额外空间周转这个“富余量”不是浪费是安全垫。坏块这块我要特别提醒一句Flash 出厂本来就允许有少量坏块文件系统组件通常自带坏块管理你不需要也没必要自己去“扫描标记坏块”。更不要试图用esp_partition_erase_range去擦除自己分区之外的区域这在没有硬件保护的情况下等于裸奔真擦坏了只能换硬件。5. 一个能直接抄的完整案例三应用共享 Flash5.1 分区表设计4MB 无 OTA 版假设我现在有三个模块共存WiFi 配网配置、BLE 设备配置、传感器历史日志。开发阶段用 4MB ESP32 模组暂时不上 OTA。分区表我会这么写# Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x1F0000, wifi_nvs, data, nvs, 0x200000, 0x2000, ble_nvs, data, nvs, 0x202000, 0x2000, sensor_log, data, littlefs, 0x204000, 0x100000,每个模块独立 NVS 分区WiFi 配网只可能在wifi_nvs里写BLE 配置只可能在ble_nvs里写传感器日志挂到 LittleFS 的/sensor_log挂载点上。三个模块之间没有共享的键值区域路径也没有交集数据的“底盘”从一开始就是分开的。可能有朋友问为什么第一个nvs分区要留 24KB而且看起来没用这个分区是 ESP-IDF 系统组件比如 RF 校准数据默认使用的不能随便删删了 Wi-Fi 射频校准信息没地方放连接稳定性会受影响。5.2 初始化与访问代码骨架代码里对应初始化如下WiFi 配网模块用独立 NVS 分区ESP_ERROR_CHECK(nvs_flash_init_partition(wifi_nvs)); nvs_handle_t wifi_handle; esp_err_t err nvs_open_from_partition( wifi_nvs, wifi_cfg, NVS_READWRITE, wifi_handle ); if (err ESP_OK) { nvs_set_str(wifi_handle, ssid, my_wifi); nvs_set_str(wifi_handle, passwd, secret); nvs_commit(wifi_handle); nvs_close(wifi_handle); }BLE 模块照葫芦画瓢换成分区名ble_nvs、namespace 换成ble_cfg。这样两边的键名即使都叫name、value也永远不会冲突因为物理分区都不同。传感器日志模块挂载 LittleFSesp_vfs_littlefs_conf_t conf { .base_path /sensor_log, .partition_label sensor_log, .format_if_mount_failed true, .dont_mount false, }; ESP_ERROR_CHECK(esp_vfs_littlefs_register(conf));后续写日志就通过标准 C 文件 API落到/sensor_log/data_xxx.bin。这个路径只属于传感器模块自己其他模块按约定也不该碰这个目录。5.3 验证“数据没串门”的检查方法分区表规划和代码写完怎么确认真的没串门我开发期会做一次“暴力验证”设备正常跑一段时间后断电用esptool.py把整块 Flash 读出来esptool.py -p /dev/ttyUSB0 read_flash 0x00000 0x400000 flash_dump.bin然后用 binwalk 或者简单的strings命令看每个分区的边界在哪里搜一下 WiFi 密码字符串是否只在wifi_nvs区域出现、传感器日志文件内容是否都在sensor_log区域。这个方法土但非常直观能一眼看出有没有数据越界。还有一种更轻量的运行期验证在代码里周期性地读一下自家分区大小和家用分区大小如果发现某个分区数据量异常增长或者读到了不属于自己的文件路径立刻打印告警。我甚至会故意留一个“自检目录”让每个模块启动时往自己的分区写一个带魔法数字的状态文件其他模块读不到就算正常。6. 常见问题与排查技巧实录6.1 问题速查表现象可能原因检查与解决办法重启后 WiFi 配置丢失NVS 键未nvs_commit或键名被其他 namespace 覆盖检查每个键是否有 commit确认是否用独立分区蓝牙改的设备名过几天变回旧值两个应用用了同一个 NVS 分区且键名冲突改成独立 NVS 分区 独立 namespace传感器文件里读出乱码两个应用共享文件系统根目录文件名撞车或文件写到一半掉电分区隔离 子目录 临时文件 rename 策略OTA 升级后无法启动修改分区表后没有全片擦除旧 OTA 索引失效改分区表后执行erase_flash再烧录挂载 LittleFS 失败分区类型与组件不匹配或分区太小检查 CSV 的 SubType 是否为littlefs扩大分区nvs_flash_init返回NO_FREE_PAGESNVS 分区被历史键写满清理历史键或扩大 NVS 分区结构体数据偶尔读到异常掉电导致写入一半增加 magic CRC 校验读失败走恢复逻辑这张表基本覆盖了我这些年遇到的大部分 Flash 存储异常。你会发现绝大多数问题都不是“Flash 坏了”而是分区规划不合理、没有做写入时序控制、没有做数据校验。6.2 我踩过三次的坑和教训第一次是默认 NVS 分区被两个应用写炸了。早期为了省事所有配置都往同一个默认nvs分区里塞。后来集成一个第三方蓝牙库时发现它内部也用了 NVS而且键名恰好和我自定义的一个键重了。结果就是我每次配完 WiFi蓝牙库一启动就覆盖了我的配置项。排查花了两天最后定位到这个键名冲突时真想抽自己。教训很明确独立业务模块的配置存储要么独立 namespace要么干脆独立分区别给“恰好撞键名”留任何机会。第二次是为了方便开了自动格式化结果日志全没了。一个户外设备在运行中偶发断电文件系统挂载失败后自动把整个sensor_log分区格式化了一个月的温湿度记录全部蒸发。那次之后我彻底改了习惯生产固件绝不自动格式化挂载失败就停在那儿等人工处理并打印清晰的错误码到日志。数据丢失比暂时不可用更可怕这是做嵌入式存储必须建立的心理底线。第三次是改分区表没擦全片OTA 直接变砖。我把分区从factory模式改成 OTA 模式偏移量整体向后挪了但没擦 Flash旧分区表残留的内容和新 bootloader 读到的信息错位升级失败后设备一直起不来。这个经历告诉我分区表这东西是有“记忆”的它不随固件更新自动刷新你改了它就必须配套做全片擦除或至少擦掉旧分区表区域否则那一整片历史数据会持续作妖。真正经历过这些之后我才理解“数据串门”四个字的含金量。也建议大家从一开始就养成一个习惯每个模块有独立分区、独立 namespace、独立挂载路径哪怕初期看起来空着很多地方也别硬塞到一个区域里共享。嵌入式系统里最贵的不是 Flash 容量而是排查数据错乱时消耗的时间。按这套方法把存储规划清楚后面跑项目会省下非常多的救火时间。最后再提一个小技巧如果有条件给设备加一个“存储健康自检”功能启动时检查每个分区的魔数、容量和文件数异常时主动上报这比等到用户反馈“数据丢了”再排查要主动得多。
