1. 聊聊这次为什么选 I2C AT24C02 这套组合很多刚接触 STM32F103 的朋友第一块外设往往不是 LED 就是串口等到真正需要“掉电不丢数据”的时候才意识到 EEPROM 这种东西是绕不开的。AT24C02 是 I2C 接口 EEPROM 里最经典的一颗芯片2Kbit 容量也就是 256 字节价格几毛钱市面上几乎所有开发板上都焊着它。拿它练手 I2C既便宜又直观写完代码能立刻看到效果比对着协议栈空想半天实在得多。先说清楚这套组合解决什么问题STM32F103 的 I2C 外设历来口碑不算好很多人反映硬件 I2C 容易卡死、不好调试所以初学者经常被劝退。但实际项目中I2C 又是一个绕不开的通信手段传感器、显示屏、存储芯片都在用它。AT24C02 作为最简单的一种 I2C 从设备非常适合用来把 I2C 协议彻底跑通起始条件、停止条件、应答、地址帧、数据帧、写周期延时这些概念全部能在一次读写过程中对应上。这篇文章主要面向三类人一是刚点亮过 STM32F103 最小系统、准备接触通信协议的初学者二是用 CubeMX 配过 I2C 但卡在读写时序上的朋友三是想搞清楚硬件 I2C 和软件模拟 I2C 到底怎么选、调试时从哪里入手的工程师。内容会从硬件接线开始讲一直到 CubeMX 配置、读写代码、异常排查尽量做到看完就能照着复现。我在这篇文章里硬件 I2C 和模拟 I2C 都会讲到因为实际项目中两者都有人用而且踩坑的点完全不一样。模拟 I2C 适合快速验证、不依赖外设状态硬件 I2C 适合低功耗和 DMA 场景但 STM32F103 的硬件 I2C 用不好真的会卡死这一点不提前说清楚后面写代码时会很痛苦。2. 硬件准备与接线细节2.1 器件引脚对应关系AT24C02 是 SOP-8 封装八个引脚功能很简单A0、A1、A2 是地址选择脚WP 是写保护脚SCL、SDA 是 I2C 总线VCC 和 GND 供电。在使用前必须先搞明白器件地址是怎么算出来的否则代码里写错地址数据根本进不去。AT24C02 的设备地址是 7 位组成格式是1010 A2 A1 A0。比如三个地址引脚都接地那 7 位地址就是1010000换算成 8 位写地址最低位补 0就是0xA0读地址就是0xA1。如果 A0 接了高电平写地址就变成0xA2。这个点非常容易忽略因为很多开发板出厂时 A0、A1、A2 已经固定接地了但如果你自己画板子或者飞线必须确认这三个引脚的接法最好在代码里用一个宏定义把地址显式写出来方便后面调整。引脚对应关系总结如下SCL接 STM32F103 的 PB6I2C1_SCL部分板子用 PB8需查原理图确认SDA接 STM32F103 的 PB7I2C1_SDAVCC接 3.3VGND接 GNDWP接 GND允许写入接 3.3V 则只能读不能写A0/A1/A2接 GND地址为 0xA0写/0xA1读2.2 电源与上拉电阻的注意事项AT24C02 的工作电压范围在 1.8V 到 5.5V 之间接 3.3V 完全没问题。但这里有个关键点I2C 总线的 SCL 和 SDA 是开漏输出必须接上拉电阻才能输出高电平。STM32F103 的 I2C 引脚内部虽然有上拉但阻值偏大在高速通信时信号边沿不够陡容易出现通信不稳定。常规做法是在外部接两个 4.7kΩ 上拉电阻分别接 SCL 和 SDA 到 VCC。如果你的开发板已经集成了上拉电阻就不用额外加。热词里出现“stm32f103 5v转3.3v电路”这里顺便提醒一句如果你的系统里有 5V 器件而且 I2C 总线上的从设备是 5V 供电的那么 STM32F103 的 3.3V GPIO 不能直接承受 5V 电平需要考虑电平转换。不过 AT24C02 通常都是 3.3V 供电这就不存在电平兼容问题可以直接连接。互联网上有些教程会用 5V 给 AT24C02 供电然后 SCL/SDA 直接连 STM32F103。这种接法虽然大多数时候能工作因为 AT24C02 的 SCL/SDA 引脚对输入高电平的阈值比较宽容但从设计角度看不够严谨长期可靠性存疑。建议统一用 3.3V 供电省心。2.3 关于 STM32F103 最小系统的提醒如果你用的是最小系统板而不是现成的开发板接线时要特别注意排针的丝印。很多“ STM32F103C8T6 最小系统板”上的 PB6/PB7 旁边可能没有标 I2C 字样自己对照芯片数据手册确认引脚即可。另外最小系统板上的 3.3V 电源通常是由板载 LDO 从 USB 5V 转出来的电流余量足够驱动 AT24C02 这种低功耗芯片但如果你同时挂了好几路传感器和显示屏建议用外部稳压供电避免 LDO 过热导致电压跌落。上电顺序也很重要先给 STM32F103 上电确认系统启动正常后再接入 I2C 从设备这样能避免总线冲突导致初始化失败。3. I2C 协议核心概念从时序图到代码逻辑3.1 为什么必须理解时序图很多人写 I2C 代码喜欢直接抄例程能跑通就算完事但一旦芯片换成另一型号就抓瞎。I2C 通信的核心在于时序什么时候 SDA 变化什么时候 SCL 拉高采样主机和从机之间如何握手。这些内容在时序图里体现得非常清楚看懂一张图胜过硬背十段代码。I2C 总线只有两根线SCL时钟线和 SDA数据线。空闲时两根线都是高电平。主机通过拉低 SDA 来发起起始条件然后逐个字节地发送数据。每个字节 8 位高位先发。每发送完一个字节从机要回一个 ACK应答位如果从机没回 ACK主机就知道从机不在线或者忙。发送完所有数据后主机拉低 SCL再让 SDA 从低变高形成停止条件总线释放。模拟 I2C 的代码套路大致是这样起始SCL 高电平时SDA 由高到低数据位SCL 低电平时改变 SDASCL 高电平时保持 SDA 稳定从机采样停止SCL 高电平时SDA 由低到高3.2 起始、停止、应答的代码映射在 I2C 驱动代码里这三个动作是基础中的基础。用 GPIO 模拟时可以直接用宏定义控制引脚高低电平。下面是我用过的一套很经典的模拟 I2C 代码结构示例#define SDA_H() GPIOB-BSRR GPIO_PIN_7 #define SDA_L() GPIOB-BRR GPIO_PIN_7 #define SCL_H() GPIOB-BSRR GPIO_PIN_6 #define SCL_L() GPIOB-BRR GPIO_PIN_6 #define SDA_READ() ((GPIOB-IDR GPIO_PIN_7) ! 0) static void I2C_Delay(void) { for (volatile int i 0; i 20; i); } void I2C_Start(void) { SDA_H(); SCL_H(); I2C_Delay(); SDA_L(); I2C_Delay(); SCL_L(); } void I2C_Stop(void) { SCL_L(); SDA_L(); I2C_Delay(); SCL_H(); I2C_Delay(); SDA_H(); } uint8_t I2C_WaitAck(void) { uint8_t ack 0; SDA_H(); // 释放SDA让从机控制 I2C_Delay(); SCL_H(); I2C_Delay(); if (SDA_READ()) { ack 1; // 没有应答 } SCL_L(); return ack; }这套代码是纯软件模拟的不依赖 STM32F103 的 I2C 外设好处是逻辑完全掌握在自己手里遇到问题容易查。I2C_Delay 的时间直接决定通信速率大约 20 次空循环在 72MHz 主频下大概能产生几百纳秒的延时可以跑在 100kHz 到 400kHz 之间。3.3 七位地址与读写位的组织I2C 的总线通信是以字节为单位的第一个字节是设备地址加读写位。写操作时地址字节的最低位是 0读操作时最低位是 1。AT24C02 的设备地址是 7 位记作 A6...A0实际发送时左移一位最低位填 R/W 位。很多初学者在这里搞混把 0xA0 当成了“唯一地址”其实 0xA0 已经是写地址字节了如果直接把它当作 7 位地址发送帧结构就错了。一个标准的写命令帧如下主机发起始条件发 0xA010100000其中 A2/A1/A0 都接地最低位为 0 表示写AT24C02 收到后比对前 7 位确认匹配后拉低 SDA 回复 ACK。接着主机发要写入的字节地址0~255再发数据字节。每个字节后从机都会回 ACK。最后主机发停止条件触发 EEPROM 内部写周期大约 5ms 内完成写入。读命令帧则复杂一点分两种当前地址读和随机读。随机读需要先发一个伪写命令来指定地址主机发起始、发 0xA0、发内存地址然后主机发重复起始条件、发 0xA1此时 AT24C02 切换方向开始向主机发送数据。这里“重复起始条件”是 I2C 协议里的关键动作模拟 I2C 代码里其实就是再调用一次起始函数但 SCL/SDA 的状态转换必须正确否则从机可能不识别。4. CubeMX 初始化配置与工程搭建4.1 CubeMX 中的 I2C 配置项说明用 STM32CubeMX 配置 STM32F103 的 I2C1 外设非常快但里面几个参数不搞清楚后面调代码会莫名其妙地出问题。打开 CubeMX 后先把 PB6 和 PB7 配置为 I2C1_SCL 和 I2C1_SDA然后在 I2C1 的 Mode 里选择 I2C下面的参数基本保持默认即可有几个值值得解释一下I2C Speed Mode标准模式100kHz或快速模式400kHz。AT24C02 支持 400kHz但建议前期先用 100kHz 跑通降低信号干扰对调试的影响。I2C Clock Speed这个值和 PCLK1 的时钟频率密切相关。F103 的 APB1 最高 36MHzCubeMX 会自动算分频系数不用手动干预。Rise Time / Fall Time输入输出信号的边沿转换时间AT24C02 的数据手册上会给出范围默认值通常都能用。配置完成后记得在 Project Manager 里勾选 Generate peripheral initialization as a pair of .c/.h files这样生成的代码结构更清晰后面添加自己的驱动函数也方便。4.2 HAL 库读写函数签名与用法STM32F103 的 HAL 库提供了一组 I2C 读写函数HAL_I2C_Master_Transmit、HAL_I2C_Master_Receive、HAL_I2C_Mem_Write、HAL_I2C_Mem_Read。前两个是直接读写设备寄存器用的后两个带 MemAddress 参数正是为 EEPROM 这类“先指定内部地址再传数据”的器件设计的所以直接用 Mem_Write 和 Mem_Read 最合适。关键在于HAL_I2C_Mem_Write 的 I2C_HandleTypeDef 参数是 hi2c1DevAddress 参数是 AT24C02 的 8 位设备地址写地址 0xA0MemAddress 是 EEPROM 内部字节地址MemAddSize 是 I2C_MEMADD_SIZE_8BIT因为 AT24C02 的地址只有 8 位Buffer 是数据缓冲区指针Size 是传输数据长度。看一下 HAL 库源码就会发现它内部会自动帮你组织起始条件、地址字节、内存地址字节和数据字节不需要你手动操作 I2C_Start 这些底层函数。这大大降低了代码复杂度也是推荐 HAL 的主要原因之一。4.3 Keil MDK 工程搭建与 ST-Link 调试要点热词里有一条“stm32f103 keil mdk工程搭建与st-link调试全流程”说明很多人卡在工程搭建阶段。从 CubeMX 生成的工程可以直接用 Keil MDK 打开但前提是你得在 CubeMX 里选对工具链版本建议选 MDK-ARM V5。打开工程后第一个要做的事是检查魔术棒里的 Debug 设置选择 ST-Link Debugger然后在 Settings 里确认 SW 模式连接正常设备 ID 能识别出来。涉及 I2C 调试强烈建议在代码里加一个软件延时不是 Hack而是缓解调试器连接时对时序的影响。当你全速跑的时候写 EEPROM 后没有等待写周期就立刻去读大概率读出来是 0xFF。这种情况不是代码逻辑错而是 AT24C02 还没写完。HAL 库的 HAL_I2C_Mem_Write 函数并不会自动等待内部写周期结束所以写入之后要 delay 5~10ms再执行读操作。调试时 ST-Link 的 RTT 或者串口打印都行我习惯用串口把读出来的数据打印出来配合十六进制显示一眼就能看出写入是否成功。但注意 ST-Link 的 SWD 引脚和 I2C 引脚如果碰巧复用了调试时会影响 I2C 波形。5. 读写代码实现从单字节到页写5.1 单字节写入与读取的实现先写最基础的单字节写入函数。AT24C02 内部写单个字节的流程是主机发起始、发 0xA0、发内存地址、发数据、发停止。下面这段代码在我的工程里测试过可以直接套用#define AT24C02_ADDR_W 0xA0 #define AT24C02_ADDR_R 0xA1 uint8_t AT24C02_WriteByte(uint8_t memAddr, uint8_t data) { uint8_t buf[1]; buf[0] data; if (HAL_I2C_Mem_Write(hi2c1, AT24C02_ADDR_W, memAddr, I2C_MEMADD_SIZE_8BIT, buf, 1, HAL_MAX_DELAY) ! HAL_OK) { return 1; } HAL_Delay(5); return 0; } uint8_t AT24C02_ReadByte(uint8_t memAddr) { uint8_t buf[1]; if (HAL_I2C_Mem_Read(hi2c1, AT24C02_ADDR_R, memAddr, I2C_MEMADD_SIZE_8BIT, buf, 1, HAL_MAX_DELAY) ! HAL_OK) { return 0xFF; } return buf[0]; }HAL_MAX_DELAY 表示阻塞等待传输完成不设超时。实际项目中建议换成具体的超时值比如 100避免 I2C 总线异常时程序卡死。第 5ms 的 HAL_Delay 是为了等待 EEPROM 内部写周期这个时间来自 AT24C02 数据手册中的 tWR 参数最小 5ms。读过一遍数据手册就能理解这个延时不能省。5.2 页写入与页边界陷阱AT24C02 的页大小是 8 字节页写功能可以一次连续写入最多 8 个字节。页写的逻辑和单字节写差不多只是数据长度变成 n。但这里有一个几乎所有初学者都会踩的坑跨页问题。如果从地址 7 开始连续写 4 字节这 4 字节会跨过第 0 页和第 1 页的边界此时如果芯片内部没有做跨页保护数据会回绕到页首导致数据错乱。AT24C02 手册明确说明页写不允许跨页。跨页问题的本质是内部地址计数器的自增行为每收到一个字节内部地址自动加 1但如果地址到了页边界并不会自动进位到下一页而是回绕到当前页的起始地址。所以程序里必须自己判断剩余字节数是否会跨页需要分两次写。我的习惯是写一个封装的页写函数内部自动拆分上层不用管uint8_t AT24C02_WritePage(uint8_t memAddr, const uint8_t *data, uint8_t len) { uint8_t firstPageBytes 8 - (memAddr % 8); uint8_t offset 0; if (len firstPageBytes) { if (HAL_I2C_Mem_Write(hi2c1, AT24C02_ADDR_W, memAddr, I2C_MEMADD_SIZE_8BIT, (uint8_t *)data, len, 100) ! HAL_OK) { return 1; } HAL_Delay(5); return 0; } if (HAL_I2C_Mem_Write(hi2c1, AT24C02_ADDR_W, memAddr, I2C_MEMADD_SIZE_8BIT, (uint8_t *)data, firstPageBytes, 100) ! HAL_OK) { return 1; } HAL_Delay(5); offset firstPageBytes; // 剩余部分再写 if (HAL_I2C_Mem_Write(hi2c1, AT24C02_ADDR_W, memAddr offset, I2C_MEMADD_SIZE_8BIT, (uint8_t *)(data offset), len - offset, 100) ! HAL_OK) { return 1; } HAL_Delay(5); return 0; }两次页写之间留 5ms 写周期延时能让每次写入都稳定完成。对于 256 字节的整片写入也可以用类似思路拆分成 32 次页写循环。5.3 连续读取与地址自增连续读相对简单AT24C02 支持顺序读你指定起始地址后它会自动把后续地址的数据一个个推出来。HAL 库的 HAL_I2C_Mem_Read 天然支持多字节读取只要 Size 大于 1 即可。比如从 0 地址连续读 256 字节代码如下uint8_t buffer[256]; HAL_I2C_Mem_Read(hi2c1, AT24C02_ADDR_R, 0, I2C_MEMADD_SIZE_8BIT, buffer, 256, 100);这里需要理解的是当 Size 大于 1 时HAL 库会在最后一个字节之前发送 NACK。I2C 协议规定主机在连续读取时最后一个字节要回 NACK 告诉从机不要继续发了。HAL 库自动处理了这一点所以直接用即可。如果你的代码是纯软件模拟 I2C那就必须手动管理这些细节否则最后一个字节之后总线状态会乱。6. 硬件 I2C 与模拟 I2C选型、调试和常见坑6.1 硬件 I2C 卡死的原因分析STM32F103 的硬件 I2C 在外设初始化后如果总线被拉低主设备会一直等待总线释放程序就卡死在 HAL_I2C_Mem_Write 里。这种情况我在调试初期遇到过好几次每次都是因为从设备没有正确回应 ACK。原因通常有两类一是地址写错从机不认二是总线上的上拉电阻缺失SDA 被某个设备钳低。此外STM32F103 的硬件 I2C 对时序的要求比较苛刻如果 SCL 的频率配置过高从机跟不上也会表现为总线异常。一旦进入硬件 I2C 卡死的状态看门狗又没开的话整个系统就挂住了。解决办法有两个方向一是尽量把 I2C 通信的失败检测机制做出来比如 HAL_OK 判断不通过就复位外设二是在调试阶段直接用模拟 I2C等逻辑全部跑通了再切换回硬件 I2C比对两种实现的差异。6.2 模拟 I2C 的调试优势模拟 I2C 本质上是纯粹的 GPIO 操作不依赖外设状态机代码里每一拍都有明确的延时所以非常容易用示波器或逻辑分析仪对应起来。把 SCL 和 SDA 接到逻辑分析仪上可以看到每一字节的波形跟 AT24C02 数据手册上的时序图一一对照。这个体验是硬件 I2C 没有的硬件外设把时序细节藏在状态机里出问题时很难定位。我推荐的开发路径是先用模拟 I2C 把读写 AT24C02 的代码跑通再用逻辑分析仪记录一次完整的写命令帧和读命令帧跟时序图校验。确认无误后再切换到 HAL 库的硬件 I2C此时你会对每个字节的传输过程有很强的直觉遇到硬件 I2C 的异常也更容易猜测到原因。6.3 常见问题与排查实录以下是我在实际调试过程中遇到的几个典型问题整理成了速查表。故障现象可能原因排查思路写完后读出来全是 0xFF写周期未等待数据根本没写入在写操作后加 5~10ms 延时再读指定地址前几个字节正常页写时跨页地址回绕把长度限制在 8 字节内按页边界拆分偶尔写入失败复位后数据丢失写保护引脚 WP 被拉高检查 WP 是否接 GND确认允许写入SCL/SDA 其中一个始终为低上拉电阻缺失或某设备拉死总线加 4.7kΩ 上拉电阻断电排查从设备设备地址写 0xA0 但无应答A0/A1/A2 引脚电平与代码不一致用万用表测引脚电平核对 7 位地址硬件 I2C 初始化后卡死总线忙标志未被清除尝试复位 I2C 外设或改用模拟 I2C 验证连续读多字节时数据错位主机未在最后字节回 NACK用 HAL_I2C_Mem_Read 自动处理不要手动逐字节读还有一个很多人忽略的点AT24C02 的 WP 引脚如果悬空内部默认可能是高电平也可能被外部干扰拉高导致写操作无效。硬件设计时建议把 WP 明确接 GND不要悬空。另外AT24C02 的 SCL/SDA 引脚没有内置钳位二极管如果总线上有其他设备在另一路供电下保持电平可能出现漏电问题所以共地很关键。7. 扩展到 256 字节存储管理和掉电保存场景7.1 字节分配与磨损均衡思路AT24C02 只有 256 字节放在现代嵌入式项目里实在不算大但也足以承担关键参数存储任务。分配内存时要有意识地做区域规划0x00~0x0F 存系统配置项0x10~0x1F 存用户设置0x20~0xFF 做数据区。不要把所有东西一股脑塞在一起因为后续固件升级要预留扩展空间。EEPROM 的擦写寿命在 100 万次左右虽然对大多数产品够用但如果程序里频繁写入同一个地址比如设备计数就需要考虑磨损均衡。做法很简单把计数器存到多个字节每次递增时写到下一个地址写满一轮后再统一处理。uint8_t counterAddr 0x20; uint8_t counterValue; // 读取当前计数 counterValue AT24C02_ReadByte(counterAddr); if (counterValue 0xFF) { counterValue; } else { // 此地址已写满换下一个 counterAddr; counterValue 0; } AT24C02_WriteByte(counterAddr, counterValue);这个例子虽然简单但思路值得推广。EEPROM 的写入时间远大于 RAM 操作批量写入时注意控制写次数。7.2 掉电保存的注意事项很多产品需要在掉电瞬间保存关键数据。STM32F103 检测掉电的方式有 ADC 监控电源电压、EXTI 外部中断、PVD 可编程电压检测器等。这里要提醒的是掉电瞬间系统时间有限必须优先写入最重要的数据然后立刻进入低功耗模式。写入 AT24C02 时需要 5ms 以上的写周期能否完成取决于掉电检测的触发电压和电源电容的放电时间。我自己用过的一个方案是在 12V 输入处用电容储能当 PVD 检测到 3.0V 以下时触发中断停止其他任务立即把关键数据写入 EEPROM。写入完成后把 GPIO 全部拉低系统进入停机模式。这个方案的经验是主电源电容要预留足够余量至少保证 10ms 的供电时间否则 5ms 的 EEPROM 写周期都撑不过去。7.3 数据校验与突发写失败的补救EEPROM 在写入过程中掉电可能导致该字节数据不完整表现为某些位变成 0xFF。解决的办法是给数据加校验和。比如每 16 字节数据后面跟一个校验字节读写时计算校验和不一致就认为数据损坏可以回退到默认值。我习惯的做法是定义一个存储结构体包含前导标志、数据体和校验字节。读取时先检查前导标志再检查校验都通过才使用数据typedef struct { uint16_t magic; uint8_t data[32]; uint8_t checksum; } ConfigBlock; uint8_t validConfig(ConfigBlock *blk) { uint8_t sum 0; if (blk-magic ! 0x5A5A) return 0; for (int i 0; i 32; i) sum blk-data[i]; return (sum blk-checksum); }这个结构体内的字节数最好对齐到页大小边界减少写次数。256 字节的存储容量虽然有限但配合校验和分段管理足够应付大多数简单产品的需求。8. 实测记录与最终建议我的测试环境是 STM32F103C8T6 最小系统板CubeMX 生成 HAL 库工程PB6/PB7 接 AT24C02 模块外接两个 4.7kΩ 上拉电阻。先跑模拟 I2C把单字节读写、页写、连续读都验证过然后用逻辑分析仪抓波形对比手册时序确认无误后再切换到 CubeMX 生成的硬件 I2C 工程做了同样的测试。硬件 I2C 起初也出现了一次卡死原因是我把 I2C 时钟频率设到 400kHz 后总线上有干扰降到 100kHz 后稳定运行。之后我测试了连续写入 256 字节再读回数据完全一致验证了页写拆分逻辑的正确性。这里补一个细节用逻辑分析仪抓 I2C 波形时触发条件要设为 SDA 下降沿采样率至少是 I2C 时钟的 10 倍也就是 4MHz 以上否则波形上的边沿会被采模糊。另外逻辑分析仪的通道区分要清楚CH0 接 SCLCH1 接 SDA否则解码出来的结果是没有意义的。如果你也在做类似项目我有几个建议供参考第一先用模拟 I2C 跑通别急着调硬件外设调试体验完全不同第二AT24C02 的器件地址要在代码里用宏集中定义不要散落各处后续改地址只改一处第三写后延时 5ms 这个动作不要省哪怕你用硬件 I2CHAL 函数不会帮你等内部写周期第四硬件上 WP 引脚一定要明确接 GND 或 3.3V不要悬空。从 STM32F103 到其他 M 系列芯片这套 I2C 操作思路基本通用。I2C 协议本身并不复杂复杂度主要来自时序细节和不同器件的差异。把 AT24C02 玩透之后再去接 OLED 屏比如 SSD1306、传感器比如 HMC5883L、BMP280都会轻松很多因为套路是相通的。后续如果想深入可以尝试看 I2C 的 DMA 传输、多主机仲裁或者把 AT24C02 换成更大容量的 AT24C256地址变成了 16 位那时候你会更深刻地理解地址计数器的差异。
