简介MB85RC64驱动是一份面向STM32等嵌入式平台的铁电存储器FRAM驱动代码用于快速配置MB85RC64芯片并实现非易失性数据读写相比EEPROM和FlashFRAM具备高速读写、低功耗、擦写寿命长等优点特别适合频繁保存参数、日志或掉电不丢失数据的应用场景。驱动由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. 为什么是MB85RC64FRAM和普通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 A07 位基址 0x50~0x57总线写地址0xA0~0xAF总线读地址0xA1~0xAF字地址长度2 字节有效 13 位页大小32 字节页数256 页最大 I2C 时钟1MHz3. 读写协议与页边界真正决定驱动正确性的细节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 /* A2A1A00 时的7位地址 */ #define MB85RC64_I2C_ADDR (MB85RC64_ADDR7 1) /* 0xA0HAL库习惯传左移值 */这里多说一句我在代码里显式写清楚“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 w30x50 0x00 0x10 0x5A然后再读回来i2ctransfer -y 1 w20x50 0x00 0x10 r1注意这里的 0x50 是 7 位地址因为 i2c-tools 的语法就是按 7 位地址操作。如果你手边有逻辑分析仪建议把 SDA 和 SCL 都挂上抓一次写操作看第一个字节是不是 0xA0第二个字节是不是字地址高字节 0x00第三个字节是不是字地址低字节 0x10。这个检查能帮你把地址宏、HAL 库参数和实际总线行为三者快速对上省去很多猜测。我自己在实际调这块芯片时最后还会在驱动里加一个 0x0000 到 0x001F 范围的“签名区”自检上电后往里写一串固定模式再读回来比对不一致就通过错误码上报。这样一个简单的自检能把地址线虚焊、WP 电平异常、I2C 上拉电阻不合适这类硬件问题在应用层真正开始跑数据之前就暴露出来。FRAM 支持 100 亿次擦写这种每次开机都执行一次的自检对寿命几乎没有影响但排查问题的时候能省不少时间。本文还有配套的精品资源点击获取