简介：MB85RC64驱动是一份面向STM32等嵌入式平台的铁电存储器FRAM驱动代码，用于快速配置MB85RC64芯片并实现非易失性数据读写；相比EEPROM和Flash，FRAM具备高速读写、低功耗、擦写寿命长等优点，特别适合频繁保存参数、日志或掉电不丢失数据的应用场景。驱动由C语言编写，压缩包内共2个文件——1个C源文件实现I2C或SPI总线通信、读写函数及错误处理，1个头文件提供接口声明与数据结构定义，结构轻量，便于阅读和移植；资源包仅3KB，可直接复制到现有工程，开发者只需配置对应外设引脚并调用初始化、读、写等接口函数即可访问FRAM，无需关心底层总线时序与校验细节。该驱动代码接口清晰，配合STM32开发环境可快速集成，能帮助电子工程师和嵌入式爱好者缩短开发周期，降低存储器选型与驱动调试成本，快速验证铁电存储方案。目前已有1748人学习浏览，适合正在学习FRAM技术或项目中需要可靠掉电存储的开发者参考。 上周帮朋友带一块MB85RC64的驱动，i2cdetect 很顺利地扫出了 0x50 这个设备地址，我心里想着，不就是一颗 I2C 存储器嘛，按 EEPROM 那套直接写就行了。结果呢，片内数据回读永远是全 0xFF，写入再读也是全 0xFF。查了半小时，最后发现是 WP 脚在原理图上被默认拉高了，芯片的写保护根本没关掉。这种问题，驱动代码里永远看不出故障，只能靠对芯片行为的了解去猜。
MB85RC64 是一颗 64Kbit 的 I2C FRAM，也就是铁电存储器，容量换算过来是 8KB，相比普通 EEPROM，它的写入寿命和写入速度完全是另一个量级。这篇文章我会把这块芯片的引脚、I2C 器件地址、页边界行为、驱动实现和实测中的坑一次说清楚，适合正在用 STM32 HAL 库、或者准备把 EEPROM 驱动迁移到 FRAM 上的人做参考。
1. 为什么是MB85RC64：FRAM和普通EEPROM的本质差异
很多第一次接触 FRAM 的人会下意识把它当成“快一点的 EEPROM”，这个理解方向对了，但低估了它带来的设计习惯变化。FRAM 最核心的区别是写入机制完全不一样：EEPROM 靠电荷泵往浮栅里注入电荷，写之前要擦除，写一次要等 3~5 毫秒；FRAM 靠铁电晶体极化翻转存数据，写入几乎是瞬时完成的，对 MCU 来说，I2C 总线上的 ACK 一回来，数据就落定了。
这个差异最直接的价值在频繁掉电记录场景。比如电表里的断电时间记录、工控设备里的运行日志、工业现场的参数备份，这类数据可能每次断电前都要写一笔，而且设备可能一天掉电几十次。普通 EEPROM 的擦写寿命一般是 10 万次到 100 万次，如果每秒写一次，几天就可能顶到寿命上限；MB85RC64 的读写耐久是 10 的 10 次方，也就是 100 亿次，比 EEPROM 高出四个数量级，短时间频繁读写几乎不用考虑磨损问题。
再一个差别是写等待时间。EEPROM 写入一页数据后，如果继续发下一条 I2C 指令，从机不会 ACK，驱动里必须做“写轮询”或者等待固定延时，这是很多 EEPROM 驱动里必备的逻辑。而 MB85RC64 这类 FRAM 不需要写轮询，你按普通 I2C 内存地址写入，传输完成即写入完成，驱动代码干净很多。
最重要的反倒是 FRAM 的短板：数据保持时间。MB85RC64 在 85 摄氏度环境下数据保持约 10 年，而普通 EEPROM 通常标称 100 年。如果你做的是长期静态存储，比如出厂写死序列号、校准参数，一年到头也不会重写几次，那 EEPROM 依然是更稳妥也更有性价比的选择。FRAM 的适用场景一定是“写得多、掉电勤、数据量不大”这一类。
所以选型逻辑很简单：要长期静态保存，用 EEPROM；要高频写入和断电扛造，用 FRAM。搞清楚这个背景，写驱动时你才会理解为什么很多 FRAM 驱动看起来比 EEPROM 驱动“简单”很多——那不是芯片功能弱，而是它的可靠性阈值足够高，你可以把原来用来处理写磨损和写轮询的代码全部扔掉。
2. 引脚和器件地址：驱动移植前必须确认的三件事
MB85RC64 常见封装是 SOP-8，总共 8 个引脚，硬件上没太多玄机，但有三件事必须确认清楚，否则代码写得再对，上板也是白搭。
第一件事是器件地址选择脚。芯片的 I2C 从机地址是 7 位，格式固定为 1010 A2 A1 A0，其中高四位 1010 是芯片本身定义好的，低三位由外部引脚 A2、A1、A0 的电平决定。三根地址线全部接地时，7 位地址是 0x50；如果 A2 接高、A1 接低、A0 接低，地址就是 0x54。这意味着一根 I2C 总线上最多可以挂 8 颗 MB85RC64，地址范围 0x50 到 0x57。
很多驱动出问题就出在这里：不同代码库对“设备地址”这个参数的约定不一样。I2C 总线上真实传输的那个字节，写操作是 7 位地址左移一位再补 0，也就是 0xA0；读操作是 0xA1。而 STM32 HAL 库的HAL_I2C_Master_Transmit这类函数，文档里写的是要传“7 位地址左移后的值”，所以你传给 HAL 的应该是 0xA0，不是 0x50。反过来，Linux 的 i2c-tools 工具和很多老式驱动里填的是 7 位原值 0x50。这两个约定如果混用，总线上的地址就会完全错位，从机自然不应答。
第二件事是 WP 写保护脚。MB85RC64 的 WP 引脚拉高时整片写保护，所有写操作都会被芯片内部忽略；拉低时允许正常写入。很多开发板的原理图里 WP 脚默认连到了高电平，或者悬空没处理，结果就是初始化时能正常读到设备 ACK，但写进去的数据全是无效的。驱动代码里 I2C 通信正常、ACK 也正常、读回却永远是旧值或 0xFF，八成就是 WP 脚的问题。量产设计时我会要求硬件把 WP 通过电阻默认接到地，只在需要加上位机写保护时才由 GPIO 拉高。
第三件事是工作电压。MB85RC64 常见版本工作电压范围是 2.7V 到 3.6V，典型供电 3.3V。如果你的 MCU 是 5V 系统，I2C 引脚电平也要跟着注意，不能直接硬连，需要加电平转换。这个电源范围在芯片手册里写得很清楚，但不少人拿到板子第一反应是查驱动代码，忘了先看一眼 VDD 上实际多少伏。
内存组织方面，MB85RC64 是 8192 字节，内部按 13 位地址访问，物理地址范围 0x0000 到 0x1FFF。I2C 传输时用两个字节表示字地址，高字节的有效位只需要用到低 5 位，高 3 位芯片会忽略。驱动代码里最好主动限制地址不超过 0x1FFF，因为一旦超过这个值，芯片的地址计数器会回卷到 0x0000，你本意是写 0x2000，结果写到了 0x0000，这种错误在调试时非常隐蔽。
| 项目 | 数值 |
|---|---|
| 容量 | 64Kbit / 8192 字节 |
| I2C 从机地址 | 1010 A2 A1 A0，7 位基址 0x50~0x57 |
| 总线写地址 | 0xA0~0xAF |
| 总线读地址 | 0xA1~0xAF |
| 字地址长度 | 2 字节，有效 13 位 |
| 页大小 | 32 字节 |
| 页数 | 256 页 |
| 最大 I2C 时钟 | 1MHz |
3. 读写协议与页边界：真正决定驱动正确性的细节
MB85RC64 的 I2C 读写在协议上和普通 24C64 这类 EEPROM 非常像，写操作是“从机地址 + 2 字节字地址 + 数据”，读操作是“先写 2 字节字地址，然后重新开始传输并切换为读方向”。如果你拿现成的 EEPROM 驱动过来改，大部分代码逻辑可以直接复用，但有几个细节必须单独处理，否则就会出现“能读不能写”或者“中间一段数据错乱”的怪问题。
第一个细节是多字节写入的跨页问题。MB85RC64 内部页大小是 32 字节，芯片在连续写操作时，如果地址从页内最后一个字节继续往后走，不会自动进入下一页，而是会回卷到当前页的首地址。也就是说，你想从 0x001F 写两个字节，第二个字节实际会写到 0x0000，而不是 0x0020。普通 EEPROM 也有这个行为，但很多人在 EEPROM 驱动里因为写长度短、恰好没踩到边界，从来没触发过；换成 FRAM 后数据量一大，这个问题立刻暴露。
驱动里处理跨页有两种思路。一种简单粗暴：单次写入长度不超过 32 字节，并且调用方保证传入地址加长度永远不会跨页。另一种更稳妥：驱动内部把一次长写入拆成若干次页写入，每次最多写到当前页末尾。第二种做法才叫真正的驱动，因为上层应用没必要关心物理页边界在哪，谁内存分布谁负责。
第二个细节是没有写轮询。EEPROM 驱动里常见的写法是写入后发一个“ACK 轮询”或延时 5 毫秒，而 MB85RC64 不需要这一步。如果你沿用 EEPROM 驱动，会白白浪费大量时间在等待上，不过一般也不会出错，只是性能难看。这里真正的注意点反而是：不要因此认为 FRAM 可以无限制地连续写，它毕竟还有 I2C 总线时序约束，连续写时要注意总线上主机的时钟延展和从机响应速度，不能无脑快发。
第三个细节是连续读的地址回卷。MB85RC64 支持顺序读，如果读长度超过了 0x1FFF，地址计数器也会回卷到 0x0000 继续读。这对某些应用可能是有用的循环读功能，但如果你只是想读 8192 字节以内的数据，驱动里最好加一个边界检查，避免读超长时不报错、悄悄读到开头的数据，给上层造成诡异的数据错乱。
还有一个细节是 WP 脚和写保护逻辑。MB85RC64 的写保护是针对整个芯片的，不像有些存储芯片支持按块保护。所以驱动初始化时如果发现完全写不进去，先不要怀疑 I2C 时序，直接用万用表量一下 WP 引脚电平，比在代码里加几百行 debug 输出都管用。
4. 可复用的MB85RC64驱动实现（STM32 HAL版）
下面这套驱动我在 STM32 HAL 库环境下验证过，逻辑上分成两层：底层是单次页写入，上层是根据地址自动拆页的连续写入。读取相对简单，因为 MB85RC64 的顺序读不需要考虑页边界，但依然保留了地址越界检查。
先看头文件：
/* mb85rc64.h */ #ifndef MB85RC64_H #define MB85RC64_H #include <stdint.h> #include <stddef.h> #define MB85RC64_MEM_SIZE 8192U #define MB85RC64_PAGE_SIZE 32U int8_t mb85rc64_write(I2C_HandleTypeDef *hi2c, uint16_t addr, const uint8_t *data, uint16_t len); int8_t mb85rc64_read(I2C_HandleTypeDef *hi2c, uint16_t addr, uint8_t *data, uint16_t len); #endif这里的I2C_HandleTypeDef是 STM32 HAL 库的句柄类型，如果你用其他平台，把这两个函数里的底层 I2C 发送接收替换成你自己的平台接口就行。地址我用了一个比较保守的宏定义：
/* mb85rc64.c */ #include "mb85rc64.h" #include <string.h> #define MB85RC64_ADDR7 0x50U /* A2=A1=A0=0 时的7位地址 */ #define MB85RC64_I2C_ADDR (MB85RC64_ADDR7 << 1) /* 0xA0，HAL库习惯传左移值 */这里多说一句：我在代码里显式写清楚“7 位地址”和“左移后的地址”，就是为了防止移植时搞混。如果你在其它平台，总线地址填 0x50 还是 0xA0，以该平台驱动接口的文档为准。
然后是实现文件：
static int8_t mb85rc64_write_page(I2C_HandleTypeDef *hi2c, uint16_t addr, const uint8_t *data, uint16_t len) { uint8_t buf[MB85RC64_PAGE_SIZE + 2]; if (len > MB85RC64_PAGE_SIZE) { return -1; } buf[0] = (uint8_t)(addr >> 8); buf[1] = (uint8_t)(addr & 0xFF); memcpy(&buf[2], data, len); if (HAL_I2C_Master_Transmit(hi2c, MB85RC64_I2C_ADDR, buf, (uint16_t)(len + 2), 100) != HAL_OK) { return -2; } return 0; } int8_t mb85rc64_write(I2C_HandleTypeDef *hi2c, uint16_t addr, const uint8_t *data, uint16_t len) { uint16_t chunk; if (addr >= MB85RC64_MEM_SIZE || len == 0U) { return -3; } if ((uint32_t)addr + len > MB85RC64_MEM_SIZE) { return -4; } while (len > 0U) { chunk = MB85RC64_PAGE_SIZE - (addr % MB85RC64_PAGE_SIZE); if (chunk > len) { chunk = len; } if (mb85rc64_write_page(hi2c, addr, data, chunk) != 0) { return -5; } addr += chunk; data += chunk; len -= chunk; } return 0; }核心逻辑在mb85rc64_write的 while 循环里：先计算当前地址到页末尾还剩多少字节，形成本次写入的 chunk，写完一次就把地址偏移到下一页边界。这样上层应用无论传入多长的数据，驱动都能保证每一笔写操作都在页边界内结束，不会出现芯片自动回卷覆盖页首的问题。
读取函数类似，但不需要拆页：
int8_t mb85rc64_read(I2C_HandleTypeDef *hi2c, uint16_t addr, uint8_t *data, uint16_t len) { uint8_t addr_buf[2]; if (addr >= MB85RC64_MEM_SIZE || len == 0U) { return -3; } if ((uint32_t)addr + len > MB85RC64_MEM_SIZE) { return -4; } addr_buf[0] = (uint8_t)(addr >> 8); addr_buf[1] = (uint8_t)(addr & 0xFF); if (HAL_I2C_Master_Transmit(hi2c, MB85RC64_I2C_ADDR, addr_buf, 2, 100) != HAL_OK) { return -1; } if (HAL_I2C_Master_Receive(hi2c, MB85RC64_I2C_ADDR | 0x01U, data, len, 100) != HAL_OK) { return -2; } return 0; }这段读取实现是先发 2 字节字地址，再重新发送起始条件并切到读方向。你如果更习惯 HAL 库的封装，也可以直接用HAL_I2C_Mem_Read(hi2c, MB85RC64_I2C_ADDR, addr, I2C_MEMADD_SIZE_16BIT, data, len, 100)，效果一样，只是把地址字节的拼装过程藏到了库里。我个人比较喜欢手写这段，因为排查硬件问题时，逻辑分析仪抓到的时序和代码是一一对应的，少一层封装就少一层怀疑对象。
实际调用时也很简单：
uint8_t log_buf[64]; for (uint16_t i = 0; i < sizeof(log_buf); i++) { log_buf[i] = (uint8_t)i; } /* 从 0x0100 地址写入 64 字节，驱动内部会自动拆成两页 */ mb85rc64_write(&hi2c1, 0x0100, log_buf, sizeof(log_buf)); /* 读回来做校验 */ uint8_t check[64]; mb85rc64_read(&hi2c1, 0x0100, check, sizeof(check));这段代码在 STM32 上跑完，check数组里的内容应该和log_buf完全一致。如果读回来前 32 个字节一致、后 32 个字节跑到别处去了，多半就是没做页拆分的旧驱动直接用了长写；如果完全没写进去，先量 WP 引脚。
5. 实测中的三个坑：从“扫描不到”到“写入失败”
前面讲了那么多原理和代码，实际调试时你大概率还是会遇到一些看起来不符合常理的问题。我把这几个坑按出现频率排个序，每一个都是我或者周围同事真实踩过的。
第一个坑是地址参数填错，表现是 i2cdetect 或总线扫描看不到设备。如果你用 Linux i2c-tools 扫描，工具默认接收的是 7 位地址 0x50；如果你在写一个裸机驱动，直接往 I2C 外设寄存器里填地址，很多参考代码填的是 0xA0。二者差了一位，但总线上动作完全不同。我见过不止一个工程师把 0xA0 直接传给一个期望 7 位地址的函数，结果总线上发出去的地址变成了 0x140 这样的值，从机自然不回应。解决办法很简单：在代码里把两个宏都定义出来，写清楚用途，不要靠心算。
第二个坑是 WP 脚电平不对，表现是设备能 ACK、能读到数据、但写入不生效。MB85RC64 的写保护是整片级的，WP 为高时所有写操作都被忽略。很多第一次用 FRAM 的人沿用 EEPROM 的习惯，把 WP 脚空着不接，结果芯片内部逻辑不稳定，有时候能写有时候不能，或者一直不能写。我在设计时一般直接把 WP 用 10K 电阻拉到 GND，确保默认允许写；如果有软件写保护需求，再让一个 GPIO 控制它。调试时一旦出现“写不进”，第一步就是确认 WP 电压不是高电平。
第三个坑是跨页写入悄悄覆盖页首，表现是长数据写入后，读回来中间有一段被旧数据或者重复数据覆盖。这个在逻辑分析仪上看起来非常正常，因为 I2C 时序完全正确、ACK 也都正常，问题出在芯片内部页地址回卷。加上驱动层的拆页逻辑后，这个坑基本就消失了。我的建议是写驱动时不光要处理“当前页剩余空间不够”，还要在测试用例里故意构造跨页边界的数据，比如从 0x001F 写 4 个字节，验证读回来是否符合预期。这类边界测试比重复读写几百次普通地址更能暴露问题。
调试工具方面，我习惯在 Linux 上用 i2c-tools 做快速验证，不用单独写上位机。比如往 0x0010 地址写一个字节 0x5A，可以在树莓派或任意带 i2c-dev 的设备上执行：
i2ctransfer -y 1 w3@0x50 0x00 0x10 0x5A然后再读回来：
i2ctransfer -y 1 w2@0x50 0x00 0x10 r1注意这里的 0x50 是 7 位地址，因为 i2c-tools 的语法就是按 7 位地址操作。如果你手边有逻辑分析仪，建议把 SDA 和 SCL 都挂上，抓一次写操作，看第一个字节是不是 0xA0，第二个字节是不是字地址高字节 0x00，第三个字节是不是字地址低字节 0x10。这个检查能帮你把地址宏、HAL 库参数和实际总线行为三者快速对上，省去很多猜测。
我自己在实际调这块芯片时，最后还会在驱动里加一个 0x0000 到 0x001F 范围的“签名区”自检：上电后往里写一串固定模式，再读回来比对，不一致就通过错误码上报。这样一个简单的自检，能把地址线虚焊、WP 电平异常、I2C 上拉电阻不合适这类硬件问题，在应用层真正开始跑数据之前就暴露出来。FRAM 支持 100 亿次擦写，这种每次开机都执行一次的自检对寿命几乎没有影响，但排查问题的时候能省不少时间。
本文还有配套的精品资源，点击获取
