之前给一套温度采集设备加掉电保存功能我选了AT24C02这颗几乎每个开发板都会标配的EEPROM。原以为一个下午就能搞定结果从“写入后读回来全是0xFF”到“硬件I2C在等待标志位时永久卡死”前后折腾了两天。回头看问题不在AT24C02而在于STM32F103的硬件I2C外设和初始化细节——这个外设的脾气比想象中多。这篇文章把整个流程彻底拆开I2C总线硬件怎么搭、寄存器怎么配、AT24C02的每个字节时序到底是什么意思、HAL库怎么写最后还有几个典型的调试现场。不论你是刚接触嵌入式通信还是被F1的I2C坑过应该都能找到有用的东西。1. I2C物理层与AT24C02的硬件连接为什么上拉电阻才是主角1.1 I2C是“线与”逻辑开漏输出带来哪些约束I2C总线的SDA和SCL都工作在开漏状态。开漏的含义是设备只能主动把线路拉低不能主动输出高电平。高电平是依靠上拉电阻把线路“顶”上去的。可以这么理解总线就像一根绳子每个设备都只能向下拽它谁都不拽的时候绳子被弹簧拉回高位。所以“释放总线”其实就是把所有设备的输出晶体管关断让线路自然回到高。这个物理结构带来两个直接后果。第一总线不能同时被两个设备拉低否则产生总线冲突所以需要协议上的仲裁机制。第二上拉电阻是必须的没有它SDA和SCL永远无法回到高电平通信根本建立不起来。很多人软件调不通拿示波器一看SCL波形要么一条低电平要么边沿和圆顶一样大概率就是上拉电阻的问题。还有一个细节STM32F103的I2C引脚必须配置为开漏复用输出不能配置成推挽输出。推挽输出会主动拉高破坏线与逻辑轻则通信异常重则长时间拉低导致器件发热。标准库里的GPIO_Mode_AF_ODHAL库里的GPIO_MODE_AF_OD都是开漏模式这一点在代码初始化时要格外注意。1.2 上拉电阻取值经验值4.7k但也算一下更踏实AT24C02的数据手册通常建议上拉电阻范围在1k到10k之间实际开发板最常见的是4.7k和10k。但“能用”和“稳定用”是两回事最好还是按总线条件算一算。计算分为两个约束。最小电阻取决于低电平输出电压当设备拉低总线时电阻上的压降不能超过逻辑低电平的上限。公式是 Rmin (Vcc - Vol_max) / Iol其中Vol_max是低电平输出最大电压Iol是灌入电流。以3.3V供电、Vol_max0.4V、Iol3mA为例Rmin(3.3-0.4)/0.003≈966Ω所以选1k以上。最大电阻取决于上升沿时间总线电容越大上升沿越慢超过时序要求就从机采样不到稳定电平。标准模式100kHz要求上升时间不超过1000ns快速模式400kHz要求不超过300ns。估算公式是 Rmax Trise / (0.8473 * Cbus)。假设总线电容400pF100kHz时Trise1000nsRmax≈2.95kΩ。也就是说在比较长的走线或较多器件挂载下4.7k上拉可能已经临界了。实际我习惯先画个示波器看上升沿尽量控制在上升时间允许范围内。多数时候单片机和一颗EEPROM近距离连接总线电容很小4.7k完全够用。但如果你把排线延长到10cm以上建议考虑2.2k到3.3k的上拉。1.3 接线细节WP引脚、电源滤波与器件地址AT24C02是8脚封装接线逻辑很简单SCL接SCLSDA接SDAA0-A2接地或者接高电平VCC接电源GND接地WP写保护引脚接GND才能正常写入。有些板子把WP通过10k电阻接地这也是对的但如果你看到写不进去先查WP是不是被意外拉高了。在3.3V系统里上拉电阻接3.3V电源在5V系统里如果AT24C02的VCC也是5V可以上拉到5V。不要出现3.3V芯片和5V上拉混用。另外AT24C02的VCC旁最好放一颗0.1uF去耦电容尽量靠近器件引脚。虽然这颗芯片本身功耗极低但电源引脚如果没有去耦在写周期内部电荷泵工作时可能引起小幅掉电导致数据写入不稳定。A0到A2引脚决定器件地址。它们都接地时7位地址是0x508位写地址是0xA0读地址是0xA1。如果同一总线上挂多颗EEPROM可以通过这三根引脚区分最多挂8颗。硬件上不用的地址引脚不要悬空要么接GND要么接VCC免得受到干扰后地址漂移。按经验这些细节比软件配置更容易被忽略。2. STM32F103的I2C外设初始化从时钟使能到总线状态确认2.1 时钟与引脚复用顺序错了总线就卡死很多人在标准库或者寄存器版本上栽跟头是因为初始化顺序不对。I2C1外设挂在APB1总线上引脚默认是PB6和PB7但这两个引脚要复用为I2C功能必须先使能GPIOB时钟再把PB6和PB7配置成开漏复用输出。标准库下的顺序应该是RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); GPIO_InitTypeDef GPIO_InitStructure; GPIO_InitStructure.GPIO_Pin GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_InitStructure.GPIO_Mode GPIO_Mode_AF_OD; GPIO_Init(GPIOB, GPIO_InitStructure);这里最容易犯的错是把I2C外设时钟使能放在引脚复用之后。虽然最后结果可能也没问题但在某些复位时序下外设时钟还没打开时引脚已经拉低容易把总线拖进异常状态。更保险的做法是先把GPIO时钟和外设时钟都打开再配置GPIO最后初始化I2C外设。另一个容易踩的是配置完GPIO后直接读总线的SDA电平结果发现是低。这不一定是你配置错了也可能是因为外部EEPROM在上电复位期间把SDA拉低了。EEPROM上电后会进入默认状态通常不会占用总线但如果电源或时钟不稳定确实可能露出一小段时间。所以硬件设计时要保证电源上电速度足够快软件里也可以在初始化后加几十毫秒延时再开始通信。2.2 速率与时序寄存器100kHz和400kHz怎么配标准库初始化I2C1的代码框架如下I2C_InitTypeDef I2C_InitStructure; I2C_InitStructure.I2C_Mode I2C_Mode_I2C; I2C_InitStructure.I2C_DutyCycle I2C_DutyCycle_2; I2C_InitStructure.I2C_OwnAddress 0x30; I2C_InitStructure.I2C_Ack I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress I2C_AcknowledgedAddress_7bit; I2C_InitStructure.I2C_ClockSpeed 100000; I2C_Init(I2C1, I2C_InitStructure); I2C_Cmd(I2C1, ENABLE);I2C_ClockSpeed直接影响CCR寄存器而CCR的计算取决于PCLK1的频率和总线速率。假设系统时钟72MHzAPB1分频器为2PCLK1是36MHz。标准模式100kHz时时钟控制寄存器CCR的值是 PCLK1 / (2 * 100kHz) 36000000 / 200000 180对应十六进制0xB4。上升时间寄存器TRISE则需要按“最长上升时间 / PCLK1周期 1”计算。标准模式下最长上升时间1000nsPCLK1周期约27.8ns所以TRISE 36 1 37也就是0x25。如果改成400kHz快速模式CCR和TRISE都要重新算并且还要关注I2C_DutyCycle。快速模式下如果选择了2:1占空比则频率与CCR的关系变为 PCLK1 / (3 * CCR)400kHz对应CCR30TRISE12快速模式最长上升时间300ns300/27.8≈11再加1为12。实际项目中如果只是读写EEPROM用100kHz标准模式稳定性最高。400kHz能省一半时间但上升沿余量变小我遇到过在窄板边缘时有偶发通信错误最后又降回100kHz。2.3 上电后的总线状态自检初始化完成后不要急着写数据。先确认总线是不是空闲也就是SCL和SDA都为高。寄存器层面可以读I2C1-SR2的BUSY位如果BUSY为0说明总线空闲。但有时候BUSY位会卡在1这就是后面要讲的硬件I2C锁死问题。我习惯在上电后先做一次总线扫描延时几十毫秒读取两个引脚电平确认都高位。如果不是就执行一次总线恢复序列。具体方法放到调试部分详细说。这个自检对量产阶段的稳定性特别重要因为按钮上电瞬间电源上升波形可能会让EEPROM进入不确定状态进而把总线拉低。3. AT24C02的读写指令逐字节拆解从地址字节到页边界3.1 设备地址0xA0和0xA1是怎么来的AT24C02的I2C设备地址是7位高4位固定为1010低3位由A2、A1、A0引脚决定。全部接地时7位地址是1010000也就是0x50。I2C协议规定7位地址之后紧跟一个读写位0表示写1表示读。所以把0x50左移1位得到0xA0此时最低位是0再置最低位为1得到0xA1作为读地址。这里要区分清楚设备地址和存储地址不是一回事。设备地址用于选中芯片存储地址用于选中芯片内某个单元。AT24C02容量只有2Kbit256字节所以存储地址只需要8位从0x00到0xFF。在HAL库的Mem接口里这个8位地址就是MemAddress参数。3.2 单字节写读的完整时序与应答位处理往某个地址写一个字节完整时序是起始条件主机发送设备写地址0xA0等待从机ACK主机发送内存地址等待ACK主机发送数据字节等待ACK主机发送停止条件。每一个等待都要注意从机是否真正应答。如果EEPROM正在进行内部写操作它会忽略总线上的一切信号导致主机等不到ACK。写一个字节通常需要5ms左右的内部擦写时间Datasheet上写作tWR所以在写操作之后一定要延时。我一般写10ms留出余量。严格来讲主机发送停止条件后EEPROM才开始内部写周期。在写周期内不能对该芯片发起任何访问否则总线可能一直收不到ACK。很多人把延时放在停止条件之前那就白等了。读操作分两种随机读和当前地址读。随机读最常用它先发一个写命令把存储地址“预置”进去然后发一个重复起始条件再发设备读地址0xA1之后连续读取数据。为什么需要两次START因为第一次START只是告知EEPROM“我接下来要访问这个内存地址”并没有真正写入第二次START才切到读模式。如果从机无法识别重复起始条件就会一直停在写状态返回的数据全部是FF。3.3 页写与跨页环绕容易踩的边界规则AT24C02把256字节的存储阵列分为32页每页8字节。页写允许一次性向同一页连续写入最多8字节第8个字节之后如果继续写地址会自动回卷到页首。也就是说从页面地址0x06开始写4个字节会写入0x06、0x07、0x08、0x09没有跨页一切正常。但从0x07开始写4个字节第四个字会写到0x00页首把之前存的0x00地址内容覆盖掉。这就是最经典的“跨页覆盖”问题。所以任何多字节写入都必须考虑剩余页空间。一个安全的策略是每次写入的字节数不超过当前地址到页尾的长度。实际写多字节时要先计算 page_left 8 - (addr % 8)然后取 min(page_left, len) 作为本次页写长度写完后地址跨到下一页继续循环。3.4 当前地址读、随机读和顺序读的差异当前地址读是指设备上电或者最近一次访问后芯片内部维护了一个地址指针主机直接发读地址就能从该指针位置读数据。这个模式适合恢复掉电前的最后状态但不适合随机访问数据。随机读就是我们前面讲的两段式读先写地址再读。顺序读则是在随机读的基础上不停止地从寄存器连续读出多个字节每读一个字节地址自动加1直到255后回卷到0。在实际代码里HAL库的HAL_I2C_Mem_Read函数会替你把“伪写入地址再读”的逻辑处理好你要做的只是告诉它MemAddress是多少。但底层原理如果不懂遇到某些异常时就不知道怎么分析。4. 基于HAL库的EEPROM驱动实现阻塞轮询与中断实测4.1 HAL的I2C Mem接口为什么更贴合EEPROMSTM32F103的HAL库提供了两个层次的接口通用接口HAL_I2C_Master_Transmit/Receive以及内存接口HAL_I2C_Mem_Write/Read。通用接口要自己拼装设备地址内存地址对EEPROM不友好。Mem接口自带内存地址参数和地址宽度参数更适合AT24C02这类存储芯片。一个单字节写读的最小示例uint8_t val 0xA5; // 写设备写地址0xA0内存地址0x00 HAL_I2C_Mem_Write(hi2c1, 0xA0, 0x00, I2C_MEMADD_SIZE_8BIT, val, 1, 100); HAL_Delay(10); // 等待内部写周期完 // 读设备读地址0xA1内存地址0x00 HAL_I2C_Mem_Read(hi2c1, 0xA1, 0x00, I2C_MEMADD_SIZE_8BIT, val, 1, 100);注意HAL库里的DevAddress是8位地址已经包含了读写位所以写传0xA0读传0xA1不要只传0x50。4.2 页边界安全写入函数拆包循环为了让写入任意长度的数据都不会踩到页边界我封装了一个跨页安全写函数。核心思路是先算剩余页空间每次只写不超过一个页的数据写完后加延时再继续下一页。#define EEPROM_BASE_ADDR 0xA0 #define EEPROM_PAGE_SIZE 8 HAL_StatusTypeDef EEPROM_WriteBytes(I2C_HandleTypeDef *hi2c, uint16_t memAddr, uint8_t *data, uint16_t len) { HAL_StatusTypeDef status HAL_OK; while (len 0) { uint16_t pageLeft EEPROM_PAGE_SIZE - (memAddr % EEPROM_PAGE_SIZE); uint16_t chunk (len pageLeft) ? pageLeft : len; status HAL_I2C_Mem_Write(hi2c, EEPROM_BASE_ADDR, memAddr, I2C_MEMADD_SIZE_8BIT, data, chunk, 100); if (status ! HAL_OK) { break; } HAL_Delay(10); // 等待tWR周期完成 memAddr chunk; data chunk; len - chunk; } return status; }使用的时候直接传起始地址、数据指针和数据长度函数会自动处理页边界。比如从地址0x06写10个字节第一次写0x06和0x07共2字节第二次写0x08开始的8字节第三次写0x10开始的剩余字节。因为阻塞模式下每次写完都等待所以不需要额外状态机。4.3 读写自检数据回读对比和时间开销写驱动写完一定要做回读测试。简单做法往0x00到0xFF全部写入递增数再逐个读回比对。这个测试能同时暴露页写、地址指针、ACK处理、延时是否足够的问题。#define TEST_ADDR 0x10 uint8_t txBuf[4] {0x11, 0x22, 0x33, 0x44}; uint8_t rxBuf[4] {0}; if (EEPROM_WriteBytes(hi2c1, TEST_ADDR, txBuf, 4) HAL_OK) { HAL_Delay(10); HAL_I2C_Mem_Read(hi2c1, 0xA1, TEST_ADDR, I2C_MEMADD_SIZE_8BIT, rxBuf, 4, 100); } // 比较txBuf和rxBuf是否完全一致如果测试发现某一段固定错位比如读到的是上一页数据基本可以确定是页边界问题回头检查写入地址。如果读回来全是0xFF先查写保护引脚再查写周期延时不要上来就怀疑芯片坏了。我还顺手测过时间开销100kHz下写完256字节需要32次页写每次等待10ms总计约320ms。如果对写入速度有要求可以把延时压缩到6ms左右但前提是电源纹波和温度环境不能太恶劣。追求高可靠时宁可多留余量。5. 调试中的几个坑总线锁死、首字节丢失与页覆盖5.1 硬件I2C总线锁死的完整排查路径STM32F103的硬件I2C有一个被讨论很多的问题总线忙检测失效。现象是程序第一次调用HAL_I2C_Master_Transmit就直接返回HAL_BUSY或者卡在等待TXIS的while循环里。用示波器看SCL和SDA可能都是高电平但外设认为总线还在忙。原因是I2C外设的状态机在异常时序下跑飞BUSY位被置位后没有合理路径清除。我遇到过一次特别典型EEPROM处于内部写周期时主机发送了停止条件随即又立刻发起下一次读操作。由于EEPROM还没写完它在上次停止后没有正常释放总线SCL被拉低。接下来硬件I2C外设根本无法产生有效时序BUSY位越来越乱。最后的解决办法是执行一次官方文档提到的总线恢复流程禁用I2C外设把PB6和PB7配置成普通GPIO开漏输出手动翻转SCL产生9个时钟脉冲同时保持SDA为高让从机释放总线然后再重新初始化I2C。// 总线恢复示例伪代码根据平台调整 I2C_Cmd(I2C1, DISABLE); GPIO_InitStructure.GPIO_Pin GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_OD; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOB, GPIO_InitStructure); GPIO_SetBits(GPIOB, GPIO_Pin_6 | GPIO_Pin_7); for (int i 0; i 9; i) { GPIO_ResetBits(GPIOB, GPIO_Pin_6); delay_us(5); GPIO_SetBits(GPIOB, GPIO_Pin_6); delay_us(5); } // 恢复复用功能并重新初始化这个序列的原理是I2C从机检测到SCL连续跳变但SDA保持高会认为主机正在给它发送时钟从而把内部状态机复位到空闲状态。9个脉冲是标准做法因为地址读写位刚好8位再加一个停止条件足够让任何从机退出半途状态。之后我的调试策略改成每次写周期后至少延时10ms任何I2C错误出现时都先执行总线恢复再重新初始化。实测整个系统连续跑了一周再没出现过锁死。5.2 首字节丢失写入流程中的相位错位另一个常见问题写数据时偶尔第一个字节写不进去后面的字节都正常。如果用的是软件I2C很多人会以为是速度太快于是拼命加延时结果问题没有解决。实际上罪魁祸首往往是发送内存地址和发送数据字节之间的时钟相位没有对齐。硬件上AT24C02要求主机在收到内存地址的ACK后再发送数据字节。如果主机在ACK尚未稳定时就切到发送数据模式数据线上可能仍残留内存地址的最后一位EEPROM会把它当成第一个数据字节。HAL库在底层已经做了标志位检查理论上不会出现这种问题但如果你用的是寄存器版本而且发送数据前没有等待TXIS标志被置位就会丢首字节。正确的做法是在每个字节发送前确认发送数据寄存器为空发送后确认移位寄存器正在发送完成。等待标志位本身不会增加多少时间但能保证每个字节都在正确的相位上被采样。如果发现HAL库也丢字节建议检查I2C时钟沿和总线上拉的上升沿是否过慢。用示波器看SDA波形如果边沿成了弧形说明上拉电阻偏大或者总线电容太高适当降低上拉电阻往往立竿见影。5.3 页边界覆盖数据被“环绕”覆盖的定位与根治某次测试中我一个连续写了10字节的数据结构起始地址在0x05。按照我的代码第一次页写把0x05、0x06、0x07三个地址写完理论上应该跳到下一页但我忘了拆包直接把剩下7字节也灌进去了。结果EEPROM内部地址从0x07回卷到0x00前5个字节被覆盖。回读时发现0x05处的数据是对的0x00处的旧数据却变了。这种问题用逻辑分析仪最容易定位。观察主机连续发送的内存地址如果出现0x07之后接着0x00而不是0x08就说明是页回卷。技术上讲页写最多只能写入8字节但如果你用单字节写方式从0x07写到0x08是允许的只是每次都要发完整地址速度慢一点。稳妥的做法是写函数里老老实实按页拆包而不是试图依赖EEPROM的地址回卷。5.4 调试器干扰与高速模式的兼容性问题最后说两个相对隐蔽的问题。第一个是仿真器干扰。用ST-Link连接目标板调试时如果断点打在了I2C读写函数中间冻结会暂停CPU但I2C外设的时钟可能还在走或者SCL/SDA电平卡在半空。全速继续执行后EEPROM和主机状态就不一致了。所以调I2C时尽量不要在数据传输过程中下断点真要调试等一次完整的读写结束之后再停下。第二个是400kHz快速模式的兼容性。AT24C02本身支持400kHz但快速模式对上升沿时间更敏感要求不超过300ns。如果PCB走线较长或上拉电阻偏大信号边沿会变缓偶尔出现数据错位。遇到这种情况第一检查示波器上SDA/SCL的上升沿第二尝试把时钟降到100kHz。不要在还没确认硬件余量的情况下强行上400kHz。以前我为一个长排线方案调试无论怎么修正ACK就是1050kHz偶尔出错最后降到100kHz彻底稳定。我在实际项目里最终采用的策略是软件上把EEPROM读写封装成独立的模块每次调用都检查返回值出错时执行总线恢复并重新初始化。硬件上把上拉电阻从4.7k调整到3.3k并把I2C速率固定在100kHz。这一套组合下来AT24C02的读写才算真正让人放心。如果你也正在被STM32F103的硬件I2C折腾不妨从硬件和初始化顺序开始排查很多时候问题并不在代码本身。
之前给一套温度采集设备加掉电保存功能我选了AT24C02这颗几乎每个开发板都会标配的EEPROM。原以为一个下午就能搞定结果从“写入后读回来全是0xFF”到“硬件I2C在等待标志位时永久卡死”前后折腾了两天。回头看问题不在AT24C02而在于STM32F103的硬件I2C外设和初始化细节——这个外设的脾气比想象中多。这篇文章把整个流程彻底拆开I2C总线硬件怎么搭、寄存器怎么配、AT24C02的每个字节时序到底是什么意思、HAL库怎么写最后还有几个典型的调试现场。不论你是刚接触嵌入式通信还是被F1的I2C坑过应该都能找到有用的东西。1. I2C物理层与AT24C02的硬件连接为什么上拉电阻才是主角1.1 I2C是“线与”逻辑开漏输出带来哪些约束I2C总线的SDA和SCL都工作在开漏状态。开漏的含义是设备只能主动把线路拉低不能主动输出高电平。高电平是依靠上拉电阻把线路“顶”上去的。可以这么理解总线就像一根绳子每个设备都只能向下拽它谁都不拽的时候绳子被弹簧拉回高位。所以“释放总线”其实就是把所有设备的输出晶体管关断让线路自然回到高。这个物理结构带来两个直接后果。第一总线不能同时被两个设备拉低否则产生总线冲突所以需要协议上的仲裁机制。第二上拉电阻是必须的没有它SDA和SCL永远无法回到高电平通信根本建立不起来。很多人软件调不通拿示波器一看SCL波形要么一条低电平要么边沿和圆顶一样大概率就是上拉电阻的问题。还有一个细节STM32F103的I2C引脚必须配置为开漏复用输出不能配置成推挽输出。推挽输出会主动拉高破坏线与逻辑轻则通信异常重则长时间拉低导致器件发热。标准库里的GPIO_Mode_AF_ODHAL库里的GPIO_MODE_AF_OD都是开漏模式这一点在代码初始化时要格外注意。1.2 上拉电阻取值经验值4.7k但也算一下更踏实AT24C02的数据手册通常建议上拉电阻范围在1k到10k之间实际开发板最常见的是4.7k和10k。但“能用”和“稳定用”是两回事最好还是按总线条件算一算。计算分为两个约束。最小电阻取决于低电平输出电压当设备拉低总线时电阻上的压降不能超过逻辑低电平的上限。公式是 Rmin (Vcc - Vol_max) / Iol其中Vol_max是低电平输出最大电压Iol是灌入电流。以3.3V供电、Vol_max0.4V、Iol3mA为例Rmin(3.3-0.4)/0.003≈966Ω所以选1k以上。最大电阻取决于上升沿时间总线电容越大上升沿越慢超过时序要求就从机采样不到稳定电平。标准模式100kHz要求上升时间不超过1000ns快速模式400kHz要求不超过300ns。估算公式是 Rmax Trise / (0.8473 * Cbus)。假设总线电容400pF100kHz时Trise1000nsRmax≈2.95kΩ。也就是说在比较长的走线或较多器件挂载下4.7k上拉可能已经临界了。实际我习惯先画个示波器看上升沿尽量控制在上升时间允许范围内。多数时候单片机和一颗EEPROM近距离连接总线电容很小4.7k完全够用。但如果你把排线延长到10cm以上建议考虑2.2k到3.3k的上拉。1.3 接线细节WP引脚、电源滤波与器件地址AT24C02是8脚封装接线逻辑很简单SCL接SCLSDA接SDAA0-A2接地或者接高电平VCC接电源GND接地WP写保护引脚接GND才能正常写入。有些板子把WP通过10k电阻接地这也是对的但如果你看到写不进去先查WP是不是被意外拉高了。在3.3V系统里上拉电阻接3.3V电源在5V系统里如果AT24C02的VCC也是5V可以上拉到5V。不要出现3.3V芯片和5V上拉混用。另外AT24C02的VCC旁最好放一颗0.1uF去耦电容尽量靠近器件引脚。虽然这颗芯片本身功耗极低但电源引脚如果没有去耦在写周期内部电荷泵工作时可能引起小幅掉电导致数据写入不稳定。A0到A2引脚决定器件地址。它们都接地时7位地址是0x508位写地址是0xA0读地址是0xA1。如果同一总线上挂多颗EEPROM可以通过这三根引脚区分最多挂8颗。硬件上不用的地址引脚不要悬空要么接GND要么接VCC免得受到干扰后地址漂移。按经验这些细节比软件配置更容易被忽略。2. STM32F103的I2C外设初始化从时钟使能到总线状态确认2.1 时钟与引脚复用顺序错了总线就卡死很多人在标准库或者寄存器版本上栽跟头是因为初始化顺序不对。I2C1外设挂在APB1总线上引脚默认是PB6和PB7但这两个引脚要复用为I2C功能必须先使能GPIOB时钟再把PB6和PB7配置成开漏复用输出。标准库下的顺序应该是RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); GPIO_InitTypeDef GPIO_InitStructure; GPIO_InitStructure.GPIO_Pin GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_InitStructure.GPIO_Mode GPIO_Mode_AF_OD; GPIO_Init(GPIOB, GPIO_InitStructure);这里最容易犯的错是把I2C外设时钟使能放在引脚复用之后。虽然最后结果可能也没问题但在某些复位时序下外设时钟还没打开时引脚已经拉低容易把总线拖进异常状态。更保险的做法是先把GPIO时钟和外设时钟都打开再配置GPIO最后初始化I2C外设。另一个容易踩的是配置完GPIO后直接读总线的SDA电平结果发现是低。这不一定是你配置错了也可能是因为外部EEPROM在上电复位期间把SDA拉低了。EEPROM上电后会进入默认状态通常不会占用总线但如果电源或时钟不稳定确实可能露出一小段时间。所以硬件设计时要保证电源上电速度足够快软件里也可以在初始化后加几十毫秒延时再开始通信。2.2 速率与时序寄存器100kHz和400kHz怎么配标准库初始化I2C1的代码框架如下I2C_InitTypeDef I2C_InitStructure; I2C_InitStructure.I2C_Mode I2C_Mode_I2C; I2C_InitStructure.I2C_DutyCycle I2C_DutyCycle_2; I2C_InitStructure.I2C_OwnAddress 0x30; I2C_InitStructure.I2C_Ack I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress I2C_AcknowledgedAddress_7bit; I2C_InitStructure.I2C_ClockSpeed 100000; I2C_Init(I2C1, I2C_InitStructure); I2C_Cmd(I2C1, ENABLE);I2C_ClockSpeed直接影响CCR寄存器而CCR的计算取决于PCLK1的频率和总线速率。假设系统时钟72MHzAPB1分频器为2PCLK1是36MHz。标准模式100kHz时时钟控制寄存器CCR的值是 PCLK1 / (2 * 100kHz) 36000000 / 200000 180对应十六进制0xB4。上升时间寄存器TRISE则需要按“最长上升时间 / PCLK1周期 1”计算。标准模式下最长上升时间1000nsPCLK1周期约27.8ns所以TRISE 36 1 37也就是0x25。如果改成400kHz快速模式CCR和TRISE都要重新算并且还要关注I2C_DutyCycle。快速模式下如果选择了2:1占空比则频率与CCR的关系变为 PCLK1 / (3 * CCR)400kHz对应CCR30TRISE12快速模式最长上升时间300ns300/27.8≈11再加1为12。实际项目中如果只是读写EEPROM用100kHz标准模式稳定性最高。400kHz能省一半时间但上升沿余量变小我遇到过在窄板边缘时有偶发通信错误最后又降回100kHz。2.3 上电后的总线状态自检初始化完成后不要急着写数据。先确认总线是不是空闲也就是SCL和SDA都为高。寄存器层面可以读I2C1-SR2的BUSY位如果BUSY为0说明总线空闲。但有时候BUSY位会卡在1这就是后面要讲的硬件I2C锁死问题。我习惯在上电后先做一次总线扫描延时几十毫秒读取两个引脚电平确认都高位。如果不是就执行一次总线恢复序列。具体方法放到调试部分详细说。这个自检对量产阶段的稳定性特别重要因为按钮上电瞬间电源上升波形可能会让EEPROM进入不确定状态进而把总线拉低。3. AT24C02的读写指令逐字节拆解从地址字节到页边界3.1 设备地址0xA0和0xA1是怎么来的AT24C02的I2C设备地址是7位高4位固定为1010低3位由A2、A1、A0引脚决定。全部接地时7位地址是1010000也就是0x50。I2C协议规定7位地址之后紧跟一个读写位0表示写1表示读。所以把0x50左移1位得到0xA0此时最低位是0再置最低位为1得到0xA1作为读地址。这里要区分清楚设备地址和存储地址不是一回事。设备地址用于选中芯片存储地址用于选中芯片内某个单元。AT24C02容量只有2Kbit256字节所以存储地址只需要8位从0x00到0xFF。在HAL库的Mem接口里这个8位地址就是MemAddress参数。3.2 单字节写读的完整时序与应答位处理往某个地址写一个字节完整时序是起始条件主机发送设备写地址0xA0等待从机ACK主机发送内存地址等待ACK主机发送数据字节等待ACK主机发送停止条件。每一个等待都要注意从机是否真正应答。如果EEPROM正在进行内部写操作它会忽略总线上的一切信号导致主机等不到ACK。写一个字节通常需要5ms左右的内部擦写时间Datasheet上写作tWR所以在写操作之后一定要延时。我一般写10ms留出余量。严格来讲主机发送停止条件后EEPROM才开始内部写周期。在写周期内不能对该芯片发起任何访问否则总线可能一直收不到ACK。很多人把延时放在停止条件之前那就白等了。读操作分两种随机读和当前地址读。随机读最常用它先发一个写命令把存储地址“预置”进去然后发一个重复起始条件再发设备读地址0xA1之后连续读取数据。为什么需要两次START因为第一次START只是告知EEPROM“我接下来要访问这个内存地址”并没有真正写入第二次START才切到读模式。如果从机无法识别重复起始条件就会一直停在写状态返回的数据全部是FF。3.3 页写与跨页环绕容易踩的边界规则AT24C02把256字节的存储阵列分为32页每页8字节。页写允许一次性向同一页连续写入最多8字节第8个字节之后如果继续写地址会自动回卷到页首。也就是说从页面地址0x06开始写4个字节会写入0x06、0x07、0x08、0x09没有跨页一切正常。但从0x07开始写4个字节第四个字会写到0x00页首把之前存的0x00地址内容覆盖掉。这就是最经典的“跨页覆盖”问题。所以任何多字节写入都必须考虑剩余页空间。一个安全的策略是每次写入的字节数不超过当前地址到页尾的长度。实际写多字节时要先计算 page_left 8 - (addr % 8)然后取 min(page_left, len) 作为本次页写长度写完后地址跨到下一页继续循环。3.4 当前地址读、随机读和顺序读的差异当前地址读是指设备上电或者最近一次访问后芯片内部维护了一个地址指针主机直接发读地址就能从该指针位置读数据。这个模式适合恢复掉电前的最后状态但不适合随机访问数据。随机读就是我们前面讲的两段式读先写地址再读。顺序读则是在随机读的基础上不停止地从寄存器连续读出多个字节每读一个字节地址自动加1直到255后回卷到0。在实际代码里HAL库的HAL_I2C_Mem_Read函数会替你把“伪写入地址再读”的逻辑处理好你要做的只是告诉它MemAddress是多少。但底层原理如果不懂遇到某些异常时就不知道怎么分析。4. 基于HAL库的EEPROM驱动实现阻塞轮询与中断实测4.1 HAL的I2C Mem接口为什么更贴合EEPROMSTM32F103的HAL库提供了两个层次的接口通用接口HAL_I2C_Master_Transmit/Receive以及内存接口HAL_I2C_Mem_Write/Read。通用接口要自己拼装设备地址内存地址对EEPROM不友好。Mem接口自带内存地址参数和地址宽度参数更适合AT24C02这类存储芯片。一个单字节写读的最小示例uint8_t val 0xA5; // 写设备写地址0xA0内存地址0x00 HAL_I2C_Mem_Write(hi2c1, 0xA0, 0x00, I2C_MEMADD_SIZE_8BIT, val, 1, 100); HAL_Delay(10); // 等待内部写周期完 // 读设备读地址0xA1内存地址0x00 HAL_I2C_Mem_Read(hi2c1, 0xA1, 0x00, I2C_MEMADD_SIZE_8BIT, val, 1, 100);注意HAL库里的DevAddress是8位地址已经包含了读写位所以写传0xA0读传0xA1不要只传0x50。4.2 页边界安全写入函数拆包循环为了让写入任意长度的数据都不会踩到页边界我封装了一个跨页安全写函数。核心思路是先算剩余页空间每次只写不超过一个页的数据写完后加延时再继续下一页。#define EEPROM_BASE_ADDR 0xA0 #define EEPROM_PAGE_SIZE 8 HAL_StatusTypeDef EEPROM_WriteBytes(I2C_HandleTypeDef *hi2c, uint16_t memAddr, uint8_t *data, uint16_t len) { HAL_StatusTypeDef status HAL_OK; while (len 0) { uint16_t pageLeft EEPROM_PAGE_SIZE - (memAddr % EEPROM_PAGE_SIZE); uint16_t chunk (len pageLeft) ? pageLeft : len; status HAL_I2C_Mem_Write(hi2c, EEPROM_BASE_ADDR, memAddr, I2C_MEMADD_SIZE_8BIT, data, chunk, 100); if (status ! HAL_OK) { break; } HAL_Delay(10); // 等待tWR周期完成 memAddr chunk; data chunk; len - chunk; } return status; }使用的时候直接传起始地址、数据指针和数据长度函数会自动处理页边界。比如从地址0x06写10个字节第一次写0x06和0x07共2字节第二次写0x08开始的8字节第三次写0x10开始的剩余字节。因为阻塞模式下每次写完都等待所以不需要额外状态机。4.3 读写自检数据回读对比和时间开销写驱动写完一定要做回读测试。简单做法往0x00到0xFF全部写入递增数再逐个读回比对。这个测试能同时暴露页写、地址指针、ACK处理、延时是否足够的问题。#define TEST_ADDR 0x10 uint8_t txBuf[4] {0x11, 0x22, 0x33, 0x44}; uint8_t rxBuf[4] {0}; if (EEPROM_WriteBytes(hi2c1, TEST_ADDR, txBuf, 4) HAL_OK) { HAL_Delay(10); HAL_I2C_Mem_Read(hi2c1, 0xA1, TEST_ADDR, I2C_MEMADD_SIZE_8BIT, rxBuf, 4, 100); } // 比较txBuf和rxBuf是否完全一致如果测试发现某一段固定错位比如读到的是上一页数据基本可以确定是页边界问题回头检查写入地址。如果读回来全是0xFF先查写保护引脚再查写周期延时不要上来就怀疑芯片坏了。我还顺手测过时间开销100kHz下写完256字节需要32次页写每次等待10ms总计约320ms。如果对写入速度有要求可以把延时压缩到6ms左右但前提是电源纹波和温度环境不能太恶劣。追求高可靠时宁可多留余量。5. 调试中的几个坑总线锁死、首字节丢失与页覆盖5.1 硬件I2C总线锁死的完整排查路径STM32F103的硬件I2C有一个被讨论很多的问题总线忙检测失效。现象是程序第一次调用HAL_I2C_Master_Transmit就直接返回HAL_BUSY或者卡在等待TXIS的while循环里。用示波器看SCL和SDA可能都是高电平但外设认为总线还在忙。原因是I2C外设的状态机在异常时序下跑飞BUSY位被置位后没有合理路径清除。我遇到过一次特别典型EEPROM处于内部写周期时主机发送了停止条件随即又立刻发起下一次读操作。由于EEPROM还没写完它在上次停止后没有正常释放总线SCL被拉低。接下来硬件I2C外设根本无法产生有效时序BUSY位越来越乱。最后的解决办法是执行一次官方文档提到的总线恢复流程禁用I2C外设把PB6和PB7配置成普通GPIO开漏输出手动翻转SCL产生9个时钟脉冲同时保持SDA为高让从机释放总线然后再重新初始化I2C。// 总线恢复示例伪代码根据平台调整 I2C_Cmd(I2C1, DISABLE); GPIO_InitStructure.GPIO_Pin GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_OD; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOB, GPIO_InitStructure); GPIO_SetBits(GPIOB, GPIO_Pin_6 | GPIO_Pin_7); for (int i 0; i 9; i) { GPIO_ResetBits(GPIOB, GPIO_Pin_6); delay_us(5); GPIO_SetBits(GPIOB, GPIO_Pin_6); delay_us(5); } // 恢复复用功能并重新初始化这个序列的原理是I2C从机检测到SCL连续跳变但SDA保持高会认为主机正在给它发送时钟从而把内部状态机复位到空闲状态。9个脉冲是标准做法因为地址读写位刚好8位再加一个停止条件足够让任何从机退出半途状态。之后我的调试策略改成每次写周期后至少延时10ms任何I2C错误出现时都先执行总线恢复再重新初始化。实测整个系统连续跑了一周再没出现过锁死。5.2 首字节丢失写入流程中的相位错位另一个常见问题写数据时偶尔第一个字节写不进去后面的字节都正常。如果用的是软件I2C很多人会以为是速度太快于是拼命加延时结果问题没有解决。实际上罪魁祸首往往是发送内存地址和发送数据字节之间的时钟相位没有对齐。硬件上AT24C02要求主机在收到内存地址的ACK后再发送数据字节。如果主机在ACK尚未稳定时就切到发送数据模式数据线上可能仍残留内存地址的最后一位EEPROM会把它当成第一个数据字节。HAL库在底层已经做了标志位检查理论上不会出现这种问题但如果你用的是寄存器版本而且发送数据前没有等待TXIS标志被置位就会丢首字节。正确的做法是在每个字节发送前确认发送数据寄存器为空发送后确认移位寄存器正在发送完成。等待标志位本身不会增加多少时间但能保证每个字节都在正确的相位上被采样。如果发现HAL库也丢字节建议检查I2C时钟沿和总线上拉的上升沿是否过慢。用示波器看SDA波形如果边沿成了弧形说明上拉电阻偏大或者总线电容太高适当降低上拉电阻往往立竿见影。5.3 页边界覆盖数据被“环绕”覆盖的定位与根治某次测试中我一个连续写了10字节的数据结构起始地址在0x05。按照我的代码第一次页写把0x05、0x06、0x07三个地址写完理论上应该跳到下一页但我忘了拆包直接把剩下7字节也灌进去了。结果EEPROM内部地址从0x07回卷到0x00前5个字节被覆盖。回读时发现0x05处的数据是对的0x00处的旧数据却变了。这种问题用逻辑分析仪最容易定位。观察主机连续发送的内存地址如果出现0x07之后接着0x00而不是0x08就说明是页回卷。技术上讲页写最多只能写入8字节但如果你用单字节写方式从0x07写到0x08是允许的只是每次都要发完整地址速度慢一点。稳妥的做法是写函数里老老实实按页拆包而不是试图依赖EEPROM的地址回卷。5.4 调试器干扰与高速模式的兼容性问题最后说两个相对隐蔽的问题。第一个是仿真器干扰。用ST-Link连接目标板调试时如果断点打在了I2C读写函数中间冻结会暂停CPU但I2C外设的时钟可能还在走或者SCL/SDA电平卡在半空。全速继续执行后EEPROM和主机状态就不一致了。所以调I2C时尽量不要在数据传输过程中下断点真要调试等一次完整的读写结束之后再停下。第二个是400kHz快速模式的兼容性。AT24C02本身支持400kHz但快速模式对上升沿时间更敏感要求不超过300ns。如果PCB走线较长或上拉电阻偏大信号边沿会变缓偶尔出现数据错位。遇到这种情况第一检查示波器上SDA/SCL的上升沿第二尝试把时钟降到100kHz。不要在还没确认硬件余量的情况下强行上400kHz。以前我为一个长排线方案调试无论怎么修正ACK就是1050kHz偶尔出错最后降到100kHz彻底稳定。我在实际项目里最终采用的策略是软件上把EEPROM读写封装成独立的模块每次调用都检查返回值出错时执行总线恢复并重新初始化。硬件上把上拉电阻从4.7k调整到3.3k并把I2C速率固定在100kHz。这一套组合下来AT24C02的读写才算真正让人放心。如果你也正在被STM32F103的硬件I2C折腾不妨从硬件和初始化顺序开始排查很多时候问题并不在代码本身。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
