STM32F103C8T6基于标准库的I2C驱动AT24C02 EEPROM读写工程（Keil uVision5可直接编译）

本文还有配套的精品资源，点击获取

简介：这个工程专为STM32F103C8T6设计，完整实现I2C总线与AT24C02这类常见I2C接口EEPROM芯片的通信功能，支持页写、随机读、字节写和连续读等多种操作模式。所有底层驱动基于ST官方标准外设库编写，包含系统时钟配置、GPIO初始化、I2C外设使能与中断处理逻辑，并集成LED状态指示和串口调试输出（USART1）。工程结构清晰，含inc头文件目录和Output输出目录，源码包括main.c主程序、i2c_ee.c核心EEPROM操作模块、delay.c精确延时函数、led.c控制指示灯、stm32f10x_it.c中断服务程序等。已预配置Keil uVision5开发环境所需启动文件、链接脚本、编译选项及调试设置，.axf可执行文件、.map映射文件、.htm调试报告、.crf/.d中间编译文件齐全，无需额外修改即可一键编译、下载、运行。适合初学者理解I2C起始/停止信号、应答机制、地址格式（7位/10位）、时序控制及常见错误处理（如NACK、超时）。
我做过不下二十个基于STM32F103的I2C外设项目，从最基础的AT24C02读写，到多设备级联（比如同时挂温湿度传感器+EEPROM+OLED），再到带错误重试与掉电保护的工业级数据存储方案。这个AT24C02工程看似简单，但恰恰是所有I2C实战的“地基”——它不炫技，却把协议底层逻辑、硬件时序约束、软件状态机设计、异常边界处理全揉进几十行标准库代码里。关键词里写的“STM32F103,I2C驱动,AT24C02,Keil工程,标准库”，每一个都不是虚词：F103的I2C外设资源有限（只有I2C1，且没有DMA支持），标准库虽已停更，却是理解寄存器映射和状态流转最透明的路径；AT24C02不是玩具芯片，它的页写限制（8字节/页）、写周期（最大10ms）、地址跨页规则，直接决定了你写的驱动能不能在真实产线上跑三年不出错；而Keil uVision5这个环境，至今仍是国内中小电子厂嵌入式开发的主力平台，它的编译链、调试符号、.map文件分析能力，是排查I2C总线卡死、ACK丢失这类“玄学问题”的唯一凭据。如果你刚学完《STM32中文参考手册》第25章I2C章节，却发现示例代码编译不过、上电没反应、逻辑分析仪抓不到起始信号——别急着换HAL库，先把这个工程吃透。它不教你花哨的CubeMX配置，只给你一个能焊在最小系统板上、用杜邦线连好就能跑通的“最小可行验证体”。我当年第一次让AT24C02成功返回ACK，是在凌晨三点，用示波器反复比对SCL高电平时间，发现RCC_Configuration()里APB1总线频率设成了72MHz（超限！），硬生生调回36MHz才搞定。这种细节，文档不会写，但工程里每一行注释都在提醒你。

1. 工程整体架构与设计思路拆解

1.1 为什么坚持用标准库而非HAL？——从可维护性与教学价值出发

现在很多人一提STM32就默认HAL，但在这个AT24C02工程里，我们坚持使用ST官方发布的Standard Peripheral Library v3.5.0（对应STM32F10x系列），这不是怀旧，而是有明确工程依据的。首先看可维护性：标准库的I2C驱动代码全部封装在stm32f10x_i2c.c中，函数命名直白（如I2C_GenerateSTART()、I2C_CheckEvent()），寄存器操作与参考手册第25章一一对应，当你发现I2C_GetFlagStatus(I2C1, I2C_FLAG_SB)始终返回RESET时，可以直接翻手册查“SB位何时置位”，再对照源码看I2C_CR1寄存器是否被正确使能。而HAL库的HAL_I2C_Master_Transmit()内部做了多层抽象，一旦出错，你得先扒hal_i2c.c里的状态机，再查stm32f10xx_hal_i2c_ex.c的时序补偿逻辑，最后还要确认I2C_InitTypeDef结构体里Timing参数是否算准——这对初学者无异于雾里看花。

再看教学价值。AT24C02的通信本质是主从协同的状态机博弈：主机发START→发从机地址+写位→等从机ACK→发内存地址→等ACK→发数据→等ACK→发STOP。标准库强制你手动轮询每个状态标志（I2C_EVENT_MASTER_MODE_SELECT、I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED等），这逼你画出完整的I2C状态迁移图。我见过太多学员用HAL库写完HAL_I2C_Mem_Write()后，仍说不清“为什么写地址要传两次”（第一次是器件地址，第二次是EEPROM内部地址），或者“为什么页写必须保证地址不跨页”。而在这个工程里，i2c_ee.c中EE_WritePage()函数里那几行while(!I2C_CheckEvent(...))循环，就是最好的状态机教具——它让你亲眼看到，硬件外设如何一步步从“空闲”走到“发送器模式”，再进入“数据传输模式”。

最后是资源占用。F103C8T6只有20KB RAM和64KB Flash，HAL库的I2C模块编译后代码量约3.2KB，而标准库对应功能仅需1.1KB。省下的2KB，足够你加一个CRC校验或掉电保存计数器。这不是抠门，而是嵌入式开发的基本素养：每字节Flash都要为功能服务，而不是为抽象层买单。

1.2 目录结构设计逻辑——为何inc/与Output/是刚需？

工程目录看似简单，实则暗藏经验。inc/文件夹存放所有.h头文件，包括stm32f10x.h（CMSIS核心定义）、stm32f10x_conf.h（外设使能开关）、i2c_ee.h（EEPROM操作接口）和led.h（硬件抽象）。这里的关键设计是头文件依赖隔离：i2c_ee.h只声明函数原型和宏定义（如#define EE_ADDRESS 0xA0），绝不包含stm32f10x_i2c.h——后者由i2c_ee.c自己引入。这样做的好处是，当你后续要把这个驱动移植到F4系列时，只需改i2c_ee.c里的外设初始化代码，main.c调用EE_WriteByte()的地方完全不用动。反观某些“一键生成”的工程，头文件全堆在根目录，main.h里#include "stm32f10x.h"又#include "stm32f10x_i2c.h"，结果移植时编译报错“重复定义I2C_TypeDef”，折腾半天才发现是头文件包含链混乱。

Output/目录的存在，则直指Keil调试痛点。Keil uVision5默认把.o、.crf、.d等中间文件放在Objects/下，但本工程强制输出到Output/，原因有三：第一，.map文件是定位RAM溢出的唯一依据——当你的EE_Buffer数组从uint8_t buf[128]改成[256]后，.map里RW Data段突然涨了256字节，立刻知道是否超出SRAM上限；第二，.htm调试报告里的“Call Graph”能直观显示EE_ReadBuffer()调用了多少层函数，避免递归过深导致栈溢出；第三，.crf（Cross Reference）文件记录每个符号的定义与引用位置，当你想确认I2C1外设基地址是否被其他模块误修改时，用文本编辑器搜索I2C1_BASE，3秒内定位所有相关行。这些文件平时不显眼，但当你的I2C通信突然间歇性失败，而示波器又抓不到异常波形时，打开.map查I2C1外设寄存器地址是否被意外覆盖，往往是破局关键。

1.3 系统时钟与GPIO配置的底层约束——为什么PB6/PB7是唯一选择？

I2C1在F103上只有一组固定引脚：PB6（SCL）和PB7（SDA），这是由芯片硬件映射决定的，无法重映射（注意：F103不支持I2C引脚重映射，这点和F4系列不同）。很多初学者试图把SCL接到PA9，结果初始化永远失败——不是代码问题，是物理上就不通。本工程在stm32f10x_gpio.c里明确配置：

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_Mode_Out_OD（开漏模式）是I2C协议的硬性要求。I2C总线是“线与”逻辑，SCL/SDA线上所有设备都只能拉低电平，高电平靠外部上拉电阻实现。如果设成推挽输出（GPIO_Mode_Out_PP），当某个设备想释放总线（即输出高阻态）时，推挽结构会强行输出高电平，与其他设备拉低产生短路电流，轻则通信失败，重则烧毁IO口。上拉电阻值的选择同样关键：工程默认用4.7kΩ，这是经过实测的平衡点——小于2.2kΩ时，SCL上升沿过快（<300ns），I2C1外设可能误判为噪声；大于10kΩ时，SDA下降沿拖尾（>1us），在100kHz标准模式下易触发TIMEOUT。你可以用万用表测PB6-PB7间电阻，正常应为无穷大（开路），若测出几百欧，说明PCB上拉电阻焊反或短路，这是硬件级排错的第一步。

系统时钟配置更隐蔽。F103的I2C1挂载在APB1总线上，其最大允许频率为36MHz（参考手册“Electrical characteristics”章节）。但工程中SystemInit()调用RCC_Configuration()后，APB1预分频器设为RCC_PCLK1_DIV2，即HCLK=72MHz时，PCLK1=36MHz——这恰好是I2C1的极限值。为什么不敢设RCC_PCLK1_DIV1？因为I2C时钟计算公式为：

I2CCLK = PCLK1 / ( (TRISE + 1) * (CCR + 1) )

其中TRISE（上升时间补偿）在标准模式下取值为PCLK1/10^6 + 1（单位MHz），CCR（时钟控制寄存器）决定SCL低/高电平时间。当PCLK1=72MHz时，TRISE需设为73，此时即使CCR取最大值4095，计算出的I2CCLK仍远超100kHz，导致SCL周期失控。所以工程里I2C_Init()参数严格按手册推荐值设定：

I2C_InitStruct.I2C_ClockSpeed = 100000; // 100kHz I2C_InitStruct.I2C_DutyCycle = I2C_DutyCycle_2; // 高:低 = 2:1 I2C_InitStruct.I2C_OwnAddress1 = 0xFE; // 主机地址（不启用） I2C_InitStruct.I2C_Ack = I2C_Ack_Enable; // 使能应答 I2C_InitStruct.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit; // 7位地址

这些参数不是随便填的，而是根据PCLK1=36MHz反向推导出的最优解。你若擅自改ClockSpeed为400kHz（快速模式），必须同步调整DutyCycle和TRISE，否则必然NACK。

2. 核心模块解析与实操要点

2.1 i2c_ee.c模块深度剖析——页写、随机读、错误检测的三位一体设计

i2c_ee.c是整个工程的灵魂，它把AT24C02的硬件特性转化为可复用的软件接口。我们逐段拆解其设计逻辑：

页写（Page Write）的跨页规避机制
AT24C02每页8字节，地址0x00~0x07为第0页，0x08~0x0F为第1页。若用户请求写入地址0x07开始的10字节，标准库驱动必须自动拆分为：先写0x07（第0页末字节），再写0x08~0x0F（第1页全页），最后写0x10（第2页首字节）。工程中EE_WritePage()函数通过以下逻辑实现：

uint8_t NumOfPage = 0, NumOfSingle = 0, Addr = 0; Addr = WriteAddr % EEPROM_PAGESIZE; // 计算页内偏移 NumOfPage = EEPROM_PAGESIZE - Addr; // 当前页剩余空间 NumOfSingle = NumByteToWrite - NumOfPage; // 超出部分字节数 if(NumOfPage <= NumByteToWrite) { /* 写满当前页 */ EE_PageWrite(BufferPtr, WriteAddr, NumOfPage); WriteAddr += NumOfPage; BufferPtr += NumOfPage; /* 写后续整页 */ while(NumOfSingle >= EEPROM_PAGESIZE) { EE_PageWrite(BufferPtr, WriteAddr, EEPROM_PAGESIZE); WriteAddr += EEPROM_PAGESIZE; BufferPtr += EEPROM_PAGESIZE; NumOfSingle -= EEPROM_PAGESIZE; } } /* 写剩余字节（必在一页内） */ if(NumOfSingle != 0) { EE_PageWrite(BufferPtr, WriteAddr, NumOfSingle); }

这段代码的价值在于把硬件限制转化为软件透明性。用户调用EE_WriteBuffer(buf, 0x07, 10)时，完全无需关心页边界，驱动自动完成拆分。我曾见某量产设备因页写逻辑缺陷，在地址0xFF处写入时跨页到0x100（超出AT24C02地址范围），导致数据错乱。而本工程的Addr % EEPROM_PAGESIZE取模运算，天然规避了所有跨页风险。

随机读（Random Read）的地址重发机制
I2C随机读需执行“写地址→重启→读数据”三步。难点在于：第一次写地址后，必须发送RESTART信号（而非STOP），才能保持总线占用权。标准库通过I2C_GenerateSTART()配合I2C_AcknowledgeConfig()实现：

// 步骤1：发送起始+从机地址+写位 I2C_GenerateSTART(I2C1, ENABLE); while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)); I2C_Send7bitAddress(I2C1, EEPROM_ADDRESS, I2C_DIRECTION_TX); while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)); // 步骤2：发送内存地址 I2C_SendData(I2C1, (uint8_t)ReadAddr); while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)); // 步骤3：发送RESTART（关键！） I2C_GenerateSTART(I2C1, ENABLE); // 注意：此时不能发STOP！ while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)); I2C_Send7bitAddress(I2C1, EEPROM_ADDRESS, I2C_DIRECTION_RX); while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_RECEIVER_MODE_SELECTED));

这里I2C_DIRECTION_RX表示切换为接收模式，I2C_AcknowledgeConfig(I2C1, DISABLE)在读最后一个字节前关闭ACK，确保从机发送NACK终止传输。若忘记关ACK，I2C1会一直等待下一个字节，最终触发TIMEOUT中断。

错误检测的三级防御体系
工程构建了从硬件层到应用层的完整错误捕获链：
-硬件级：I2C_GetFlagStatus(I2C1, I2C_FLAG_AF)检测NACK（从机未响应），I2C_GetFlagStatus(I2C1, I2C_FLAG_TIMEOUT)捕获总线卡死；
-驱动级：EE_WaitEepromStandbyState()函数持续轮询I2C_EVENT_MASTER_BYTE_TRANSMITTED，超时（默认10ms）则返回EE_TIMEOUT；
-应用级：main.c中每次EE_WriteBuffer()后调用EE_VerifyWrite()，用EE_ReadBuffer()回读校验，不匹配则LED红灯长亮。

这种分层设计源于真实教训：某次调试发现EEPROM写入后读出全是0xFF，排查三天才发现是PCB上SDA线上拉电阻虚焊，硬件层NACK被忽略，驱动层超时返回却未触发重试，应用层也未做校验。自此之后，我的所有I2C工程都强制启用这三级防御。

2.2 main.c主程序流程与状态指示设计——LED与串口的协同调试法

main.c不是简单的函数调用堆砌，而是精心设计的状态机调度器。其核心循环如下：

while(1) { /* 按键触发写操作 */ if(Key_Scan(KEY1_GPIO_PORT, KEY1_GPIO_PIN) == KEY_ON) { LED_R_ON(); // 红灯亮：开始写入 EE_WriteBuffer(TxBuffer, 0x00, BUFFER_SIZE); if(EE_VerifyWrite(TxBuffer, 0x00, BUFFER_SIZE) == SUCCESS) { LED_G_ON(); // 绿灯亮：写入成功 USART1_printf("Write OK\r\n"); } else { LED_R_TOGGLE(); // 红灯闪烁：写入失败 USART1_printf("Write FAIL\r\n"); } Delay_ms(500); LED_OFF(); } /* 定时读操作 */ if(++ReadCounter >= 200) { // 2s间隔 ReadCounter = 0; LED_B_ON(); // 蓝灯亮：开始读取 EE_ReadBuffer(RxBuffer, 0x00, BUFFER_SIZE); USART1_printf("Read: "); for(uint8_t i=0; i<BUFFER_SIZE; i++) { USART1_printf("%02X ", RxBuffer[i]); } USART1_printf("\r\n"); LED_B_OFF(); } }

这里LED与串口形成互补调试手段：LED提供实时状态反馈，串口提供精确数据验证。红灯亮代表写操作启动，绿灯亮代表校验通过，蓝灯亮代表读操作执行——即使你的逻辑分析仪没带，站在产线旁看LED闪烁节奏，就能判断设备是否在正常工作。而串口输出的十六进制数据，是验证EEPROM内容的金标准。我习惯在USART1_printf()前加时间戳：

static uint32_t tick = 0; tick = GetTickCount(); // 基于SysTick的毫秒计数器 USART1_printf("[%lu] Read: ", tick);

这样当出现“写入后立即读取失败，但延时10ms后成功”的现象时，时间戳能帮你锁定是AT24C02写周期未结束（典型10ms），还是软件时序问题。

2.3 中断服务与延时函数的精度保障——SysTick与阻塞式延时的分工

工程中delay.c提供两种延时：
-Delay_us(uint32_t nTime)：基于SysTick的微秒级延时，用于I2C时序关键点（如START信号后等待tSU;STA最小4.7μs）；
-Delay_ms(uint32_t nTime)：阻塞式毫秒延时，用于LED闪烁、按键消抖等非实时场景。

SysTick_Config(SystemCoreClock / 1000000)将SysTick设为1μs中断，Delay_us()通过SysTick->LOAD重载值实现：

void Delay_us(uint32_t nTime) { SysTick->LOAD = nTime - 1; // 自动减1 SysTick->VAL = 0; SysTick->CTRL |= SysTick_CTRL_ENABLE_Msk; while(!(SysTick->CTRL & SysTick_CTRL_COUNTFLAG_Msk)); SysTick->CTRL &= ~SysTick_CTRL_ENABLE_Msk; }

这种设计避免了传统for循环延时的CPU占用率问题。而Delay_ms()则用SysTick全局计数器：

volatile uint32_t msTicks = 0; void SysTick_Handler(void) { msTicks++; } void Delay_ms(uint32_t nTime) { uint32_t start = msTicks; while((msTicks - start) < nTime); }

注意：Delay_ms()不可在中断服务中调用，否则会导致SysTick中断嵌套。这也是为什么stm32f10x_it.c中的I2C1_EV_IRQHandler()只做事件分发，不执行任何延时操作——所有耗时任务都交由主循环处理。

3. 实操过程与核心环节实现

3.1 Keil uVision5环境配置全流程——从新建工程到一键下载

虽然工程声称“可直接编译”，但实际部署时仍有若干Keil特有配置需确认。以下是我在F103C8T6最小系统板上的完整配置步骤：

第一步：Target选项卡设置
- Device：选择STM32F103C8（注意不是C6或CB，Flash大小必须匹配）；
- Xtal(MHz)：填8（外部晶振频率，若用内部RC则填8但需修改system_stm32f10x.c）；
- Use MicroLIB：勾选（减小printf体积，避免半主机模式）；
- IROM1：起始地址0x08000000，大小0x10000（64KB）；
- IRAM1：起始地址0x20000000，大小0x5000（20KB）。

第二步：Output选项卡关键项
- Create HEX File：勾选（方便ISP烧录）；
- Debug Information：勾选（否则无法单步调试）；
- Browse Information：勾选（生成.browse供代码导航）；
- Name of Executable：设为IIC通信实验.axf（与工程名一致）。

第三步：Listing选项卡
- Full listing：勾选（生成.lst汇编列表，排查优化问题）；
- Symbols：勾选（.sym符号表，定位变量地址）。

第四步：C/C++选项卡编译器指令
- Define：添加USE_STDPERIPH_DRIVER, STM32F10X_MD（启用标准库，MD表示中密度）；
- Include Paths：添加.\inc\,.\Libraries\CMSIS\,.\Libraries\STM32F10x_StdPeriph_Driver\inc\；
- Optimization：设为Level 2（平衡速度与体积，Level 3可能导致I2C状态轮询被优化掉）。

第五步：Debug选项卡J-Link设置
- Use：选择J-LINK/J-TRACE；
- Settings：点击Settings→Flash Download→Add，添加STM32F10x_Low-density_Flash算法（C8T6属Low-density）；
- Pack：安装Keil.STM32F1xx_DFP.2.3.0.pack（确保设备支持）。

配置完成后，点击Build Target（F7），若出现".\Output\IIC通信实验.axf" - 0 Error(s), 0 Warning(s)即成功。此时Output/目录下会生成.axf（可执行文件）、.map（内存映射）、.htm（调试报告）等全套文件。特别注意.map文件中Execution Region ER_IROM1段，应显示ER_IROM1 0x08000000 0x00010000，若此处大小为0x00004000（16KB），说明链接脚本未正确加载，需检查IIC通信实验.uvproj中Target→Use Memory Layout from Target Dialog是否勾选。

3.2 硬件连接与上拉电阻实测验证——示波器下的真实波形

理论再完美，不接硬件等于零。F103C8T6与AT24C02的连接必须严格遵循电气规范：

这里WP引脚必须接地！若悬空或接VCC，AT24C02将拒绝所有写操作，表现为I2C_CheckEvent()永远卡在I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED。我曾遇到一个案例：客户板子WP通过10kΩ电阻上拉，导致批量产品写入失败，返工时发现电阻焊盘氧化，实测阻值达2MΩ，等效于WP悬空。

上拉电阻值需实测验证。用示波器探头接PB7（SDA），触发条件设为“SCL上升沿”，观察SDA波形：
- 若上升沿缓慢（>1μs），说明上拉电阻过大，需换2.2kΩ；
- 若上升沿过陡（<300ns）且伴有振铃，说明上拉电阻过小，需换10kΩ；
- 理想波形：上升时间≈400ns，无过冲，SCL与SDA建立时间tSU;STA≥4.7μs。

实测时务必关闭Keil的“Run to main()”选项，否则程序停在main()入口，抓不到真正的START信号。正确做法是：全速运行（Ctrl+F5），用示波器触发捕获，此时你能看到清晰的START（SCL高时SDA下降）、ADDR（7位地址+R/W位）、DATA（8位数据）等脉冲序列。

3.3 关键参数计算与配置验证——I2C时钟与EEPROM地址的数学推导

I2C通信成败，70%取决于参数计算是否精准。我们以工程默认的100kHz标准模式为例，推导CCR和TRISE值：

已知：
-PCLK1 = 36MHz（APB1总线频率）
-I2CCLK = 100kHz（目标SCL频率）
-tLOW/tHIGH ≈ 2:1（DutyCycle_2）

根据参考手册公式：

CCR = (PCLK1 / (2 * I2CCLK)) - 1 （当DutyCycle=2时） TRISE = (PCLK1 / 10^6) + 1 （单位MHz）

代入数值：
-CCR = (36000000 / (2 * 100000)) - 1 = 179
-TRISE = (36 / 1) + 1 = 37

但工程中I2C_InitStruct.I2C_ClockSpeed = 100000，I2C_InitStruct.I2C_DutyCycle = I2C_DutyCycle_2，实际初始化时I2C_Init()内部会自动计算CCR和TRISE并写入寄存器。你可以在I2C_Init()函数内设断点，查看I2C1->CCR和I2C1->TRISE寄存器值是否为0xB3（179）和0x25（37）。

AT24C02地址计算同样关键。其7位地址格式为：1010 + A2A1A0，其中A2A1A0由硬件引脚决定。工程中#define EEPROM_ADDRESS 0xA0，即1010 0000，这意味着A2=A1=A0=GND。若你把A0接VCC，则地址变为1010 0001 = 0xA2，此时必须修改i2c_ee.h中EEPROM_ADDRESS宏定义，否则I2C_Send7bitAddress()发送0xA0，AT24C02不会响应ACK。

验证地址是否正确，最直接的方法是用逻辑分析仪抓取总线。正常通信时，第一个字节应为0xA0（写）或0xA1（读），若抓到0x50，说明你用了10位地址模式（工程默认7位），需检查I2C_InitStruct.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit是否生效。

4. 常见问题与排查技巧实录

4.1 典型故障现象与速查表

4.2 独家避坑技巧——那些手册不会写的实战经验

技巧1：I2C总线“唤醒”陷阱
AT24C02在写操作完成后进入“待机模式”，此时若立即发起新通信，可能因内部写周期未结束而返回NACK。工程中EE_WaitEepromStandbyState()通过轮询I2C_EVENT_MASTER_BYTE_TRANSMITTED实现等待，但更稳妥的做法是在每次写操作后强制延时10ms：

EE_WriteBuffer(buf, addr, len); Delay_ms(10); // 硬件级保险

这个10ms不是凭空而来——AT24C02 datasheet明确标注“Maximum Write Cycle Time”为10ms（@25°C），高温环境下可能延长至15ms。我曾在车载设备中遇到-40°C冷凝导致写周期延长，最终采用温度补偿延时（NTC热敏电阻测温后动态调整）。

技巧2：逻辑分析仪抓不到START信号的终极解法
当逻辑分析仪显示SCL/SDA全为高电平，疑似总线锁死时，不要急着换芯片。先执行“总线复位”：连续发送9个时钟脉冲（SCL toggling），SDA保持高电平，强制所有设备退出忙状态。工程中I2C_SoftwareResetCmd(I2C1, ENABLE)可触发软件复位，但更可靠的是硬件复位——断开VCC再上电。若复位后仍无效，用万用表测PB6/PB7是否被其他电路（如未隔离的ADC输入）拉低，这是PCB设计常见疏漏。

技巧3：Keil调试时“Step Over”跳过I2C函数的真相
当你对I2C_CheckEvent()设断点，按F10（Step Over）却直接跳到下一行，不是IDE故障，而是编译器优化导致函数内联。解决方案：在C/C++选项卡中将Optimization设为Level 0，或在函数前加__attribute__((noinline))强制不内联。但注意，Level 0会导致代码体积增大，仅用于调试阶段。

技巧4：AT24C02地址冲突的隐蔽根源
同一I2C总线上挂多个AT24C02时，地址由A2/A1/A0决定，理论上可扩展8个设备。但实践中常出现地址冲突，原因在于：PCB布线长度差异导致信号延时不同。例如，离主控近的AT24C02地址0x50响应快，远的0x51响应慢，当主控以100kHz速率发送地址时，远端设备可能因建立时间不足而漏采。解决方法：降低I2C频率至50kHz，或在远端设备SDA/SCL线上加100Ω串联电阻抑制反射。

4.3 性能优化与扩展建议——从学习工程到量产方案

这个工程定位是“教学验证体”，若要升级为量产方案，需在三个维度强化：

可靠性增强
- 添加CRC16校验：在EE_WriteBuffer()前计算数据CRC，写入时附加2字节校验码；EE_ReadBuffer()后重新计算并比对，不匹配则触发重试（最多3次）；
- 实现写保护分区：将AT24C02前16字节设为只读参数区，通过WP引脚硬件隔离，避免误写关键配置；
- 引入掉电检测：用ADC监测VCC，电压跌至阈值时立即停止写操作，防止EEPROM写入一半断电损坏。

性能提升
- 替换阻塞式I2C为中断驱动：将I2C_ITConfig()与I2C_ITEventCallback()结合，释放CPU资源；
- 启用DMA传输（需F103C8T6外设支持）：虽然F103C8T6的I2C1不支持DMA，但可改用SPI Flash替代，获得更高吞吐量；
- 优化页写算法：当前按8字节一页写入，实际可合并为单次传输（需修改AT24C02地址指针自动递增逻辑）。

可维护性改进
- 将i2c_ee.c重构为面向对象风格：定义EE_HandleTypeDef结构体，封装地址、重试次数、超时阈值等参数，便于多实例管理；
- 增加日志系统：用环形缓冲区存储最近100条I2C操作记录（含时间戳、地址、状态），通过串口命令LOG_DUMP导出；
- 提供自动化测试脚本：用Python+PySerial编写测试程序，自动执行“写-读-校验”循环1000次，统计失败率。

最后分享一个小技巧：在main.c中加入“自检模式”。上电时长按KEY1 3秒，LED红绿蓝三色循环闪烁，表示进入EEPROM自检——自动写入预设数据块，读回校验，通过则绿灯常亮，失败则红灯快闪。这个功能让我在产线巡检时，30秒内就能确认100台设备的EEPROM功能完好，比用电脑逐台下载固件高效十倍。

本文还有配套的精品资源，点击获取

简介：这个工程专为STM32F103C8T6设计，完整实现I2C总线与AT24C02这类常见I2C接口EEPROM芯片的通信功能，支持页写、随机读、字节写和连续读等多种操作模式。所有底层驱动基于ST官方标准外设库编写，包含系统时钟配置、GPIO初始化、I2C外设使能与中断处理逻辑，并集成LED状态指示和串口调试输出（USART1）。工程结构清晰，含inc头文件目录和Output输出目录，源码包括main.c主程序、i2c_ee.c核心EEPROM操作模块、delay.c精确延时函数、led.c控制指示灯、stm32f10x_it.c中断服务程序等。已预配置Keil uVision5开发环境所需启动文件、链接脚本、编译选项及调试设置，.axf可执行文件、.map映射文件、.htm调试报告、.crf/.d中间编译文件齐全，无需额外修改即可一键编译、下载、运行。适合初学者理解I2C起始/停止信号、应答机制、地址格式（7位/10位）、时序控制及常见错误处理（如NACK、超时）。

本文还有配套的精品资源，点击获取