STM32F4 I2C实战：硬件外设与软件模拟及故障排查全解析

简介：STM32F4 I2C通信例程是一套基于标准外设库的完整参考代码，适合嵌入式初学者与希望快速上手I2C总线的开发者，解决STM32F4系列通过I2C访问EEPROM（24LC02）并验证数据读写正确性的常见需求。例程中I2C_Test函数先向EEPROM写入256字节递增数据，再原样读出并通过RS232串口发送到PC，借助串口工具即可直观确认读写结果，同时涵盖I2C、GPIO、USART等模块的初始化与配置过程，注释清晰、便于移植。压缩包共1028个文件、约6.92MB，主要包含c源码、h头文件、汇编s启动文件及uvproj/MDK工程文件，另有hex和axf编译产物及PDF说明文档，而大量html、js、png文件多为工程帮助页面与图标，不影响主代码阅读，整体目录结构便于按需查找。该例程已有2461人学习下载，非常适合在STM32F4开发板上进行EEPROM读写实验或二次开发，可帮助理解I2C协议时序、外设驱动封装和串口调试方法，作为入门参考或项目模板均能提升开发效率。 手上有STM32F4板子、却被I2C折腾到怀疑人生的朋友，这篇文章就是写给你看的。OLED不亮、EEPROM回读全是0xFF、调试器一跑就卡死在HAL库的等待函数里——这些我在F407上都遇到过。I2C协议本身不复杂，但实际调起来，硬件外设和软件模拟两条路各有各的坑。这篇文章不打算泛泛而谈，直接把STM32F4上I2C通信的两种实现方式、完整例程、时序逻辑和排查经验一次讲透，适合正在做传感器采集、EEPROM存储、OLED显示这类项目的开发者参考。

1. 先把I2C这件事看透：协议本质和方案选型

1.1 两根线到底在跑什么

I2C总线物理上只有两根线：SCL时钟线和SDA数据线。两根线都是开漏输出，必须外接上拉电阻，默认状态下被上拉到高电平。通信时主机负责产生时钟，在SCL的每个高电平期间，SDA上的电平必须保持稳定；只有在SCL为低电平期间，SDA才允许变化。这就是I2C最核心的电平规则，所有时序都围绕这条规则展开。

协议层面的关键动作有四个：起始条件（SCL高电平时SDA由高变低）、停止条件（SCL高电平时SDA由低变高）、发送字节（高位在前，8个bit后跟一个ACK应答位）、接收应答（主机释放SDA，从机在第9个时钟拉低SDA表示应答）。实际设备通信时，主机先发7位从机地址加1位读写标志，再发寄存器地址，然后才是真正的数据。整个过程就像两个人对话：主机喊名字，从机应答，然后开始按节拍交换信息，每收到一个字节都要说一声“收到了”。

很多新手容易忽略一个细节：i2c通信的ACK是从机发的。比如写AT24C02，从机正常收到地址后会拉低SDA应答；如果从机没上电或地址不对，SDA在第9个时钟还是高电平，主机就知道没人应答。这个机制既是I2C的优点，也是排查问题的关键入口——总线上有没有设备，发个地址看应答就知道了。

1.2 硬件I2C外设 vs 软件模拟I2C

STM32F4自带多个硬件I2C外设，内核会自动处理起始、停止、应答、时钟等繁琐逻辑。但很多工程老手在实际项目里更爱用软件模拟I2C，不是硬件外设不行，而是它在一线调试中确实不省心。两者最核心的区别可以用一张表说清楚：

F407的硬件I2C有一个著名问题：如果总线上从机没准备好或者中途出错，硬件外设的状态机可能会卡在BUSY状态，HAL库的等待函数就一直死等，表现出来就是程序“没反应”。软件模拟I2C的优势在于所有时序都是自己写的，出问题时对引脚做一次翻转就能强制复位总线，排查起来特别快。

需要说明的是，软件模拟I2C并不是万能的。需要从机模式响应主设备请求、应对时钟拉伸、做多主机仲裁这些场景，还是必须使用硬件I2C外设。但如果你只是读写EEPROM、OLED、传感器芯片，软件模拟完全够用，而且更稳。

1.3 不同场景怎么选

日常最常见的I2C设备基本都可以用软件模拟搞定。AT24C02这类EEPROM、BH1750这类光照传感器、SSD1306驱动的OLED屏、SHT30温湿度传感器，它们的通信速率要求都在100kHz到400kHz之间，软件模拟设好延时后完全跑得动。我自己的项目里，只要用F407，默认就是软件模拟I2C，代码是同一套，换个板子改个引脚宏定义就能跑。

硬件I2C外设的适用场景是：总线上挂着多个不同速率的从机、需要外设中断自动处理收发、或者设备数量多到软件模拟的CPU开销不能接受。另外如果是从机设备往主机上报数据，必须用硬件I2C的从机模式，软件模拟做不了。

方案选型背后其实是“可控性”的取舍。软件模拟把I2C的所有细节摊在你面前，出了问题你能看见每一步；硬件外设一旦出错，寄存器状态、HAL库内部等待逻辑、引脚复用关系全都交织在一起，对经验不多的开发者来说排查成本很高。如果让我给建议，小项目、传感器项目、初期调试阶段，首选软件模拟；产品定型、总线复杂、有低功耗和中断要求，用硬件I2C并做好错误恢复机制。

2. 硬件I2C外设实操：F407 + AT24C02实现EEPROM读写

2.1 引脚分配与CubeMX配置

以STM32F407VET6为例，I2C1的默认复用引脚是PB6作为SCL、PB7作为SDA。这两个引脚同时支持I2C1和I2C2的复用功能，实际工程里最常用的组合就是PB6/PB7。使用STM32CubeMX配置时，在Pinout视图里把PB6和PB7分别设为I2C1_SCL和I2C1_SDA，然后在Connectivity -> I2C1中做参数设置。

关键参数是时钟速度和从机地址。I2C1外设挂在APB1总线上，F407的APB1时钟是42MHz，满足I2C外设最高42MHz的时钟要求。I2C速度一般选400kHz（快速模式），如果总线上有老旧设备或者线比较长，降到100kHz更稳妥。从机地址这里填的是主机自己的地址，我们做主机时从机地址是在代码里动态指定的，CubeMX里填0或任意值都行。

接线方面，AT24C02的A0、A1、A2地址引脚直接接地，器件地址就是0xA0（写）和0xA1（读）。WP写保护引脚必须接地，否则写入操作会被忽略，这是新手最容易踩的坑。

2.2 HAL库读写EEPROM完整代码

HAL库把I2C读写封装之后，操作EEPROM变得非常简洁。以AT24C02为例，核心是HAL_I2C_Mem_Write和HAL_I2C_Mem_Read，函数内部会自动处理起始条件、设备地址、寄存器地址、数据发送和停止条件。

#define AT24C02_WR_ADDR 0xA0 // 0x50 << 1 | 0 #define AT24C02_RD_ADDR 0xA1 // 0x50 << 1 | 1 // 写一个字节到EEPROM uint8_t EEPROM_WriteByte(uint16_t memAddr, uint8_t data) { return HAL_I2C_Mem_Write(&hi2c1, AT24C02_WR_ADDR, memAddr, I2C_MEMSIZE_8BIT, &data, 1, 100); } // 从EEPROM读一个字节 uint8_t EEPROM_ReadByte(uint16_t memAddr) { uint8_t data = 0; HAL_I2C_Mem_Read(&hi2c1, AT24C02_RD_ADDR, memAddr, I2C_MEMSIZE_8BIT, &data, 1, 100); return data; }

这里的memAddr是EEPROM内部的字节地址，AT24C02容量是2Kbit也就是256字节，所以地址范围是0到255，用8位地址就够了，对应I2C_MEMSIZE_8BIT。

写操作有一个必须注意的点：AT24C02每写完一个字节，内部都要进行一次擦写，这个时间典型值是5ms。在写周期结束前，芯片不会响应任何操作。所以写完数据后必须加延时，最简单的方式就是HAL_Delay(5)。我曾经因为没加这个延时，回读数据一直是0xFF，后来才意识到是写入根本没完成就被下一步操作打断了。

2.3 读写验证与注意事项

在main函数里做一次“写入再读回”的测试是最直观的验证方式：

int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); uint8_t testData = 0x5A; EEPROM_WriteByte(0x00, testData); HAL_Delay(10); // 等内部写周期结束 uint8_t readBack = EEPROM_ReadByte(0x00); if (readBack == testData) { // 读写正常 } else { // 读写异常，进入排查流程 } while (1) {} }

实际用下来有几点体会。硬件I2C外设的HAL库封装里，HAL_I2C_Mem_Write/Read的超时参数要合理设置，100ms比较合适，调得太短（比如10ms）在寄存器擦写期间很容易超时。另外I2C通信时如果从机没有正确释放SDA，硬件外设可能卡在BUSY状态，这时可以把超时时间缩短，至少能让函数返回错误码，而不是无限死等。调试硬件I2C时，逻辑分析仪是必需品，抓一次波形就能看清起始条件、地址、ACK每一个细节上的问题。

3. 软件模拟I2C：摆脱外设束缚的通用写法

3.1 模拟I2C核心代码框架

软件模拟I2C的本质就是用GPIO按I2C时序要求翻转电平。这里有个关键技巧：把SDA和SCL所在的引脚初始化为开漏输出加上拉。开漏输出模式下，引脚输出0时强制拉低，输出1时释放总线由上拉电阻拉高。这样SDA既能输出又能输入，读取时直接读IDR寄存器就能得到当前电平，不需要反复切换输入输出模式，代码清爽很多。

#define I2C_SCL_PORT GPIOB #define I2C_SCL_PIN GPIO_PIN_6 #define I2C_SDA_PORT GPIOB #define I2C_SDA_PIN GPIO_PIN_7 #define SCL_H() HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_SET) #define SCL_L() HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_RESET) #define SDA_H() HAL_GPIO_WritePin(I2C_SDA_PORT, I2C_SDA_PIN, GPIO_PIN_SET) #define SDA_L() HAL_GPIO_WritePin(I2C_SDA_PORT, I2C_SDA_PIN, GPIO_PIN_RESET) #define SDA_READ() HAL_GPIO_ReadPin(I2C_SDA_PORT, I2C_SDA_PIN) void I2C_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStruct = {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); GPIO_InitStruct.Pin = I2C_SCL_PIN | I2C_SDA_PIN; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD; GPIO_InitStruct.Pull = GPIO_PULLUP; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); SCL_H(); SDA_H(); }

延时函数用简单的for循环就能实现。这里有一个工程经验：F407主频168MHz时，一个空for循环大约能跑到几十纳秒的粒度，自己实测标定一下就行。追求精确的话可以用DWT计数器做微秒延时，代码稍微复杂一点，但移植性更好。

核心时序函数是这四个：起始、停止、发送字节、接收字节。

void I2C_Start(void) { SDA_H(); SCL_H(); delay_us(5); SDA_L(); // SCL高电平时SDA由高变低，产生起始条件 delay_us(5); SCL_L(); } void I2C_Stop(void) { SDA_L(); SCL_H(); delay_us(5); SDA_H(); // SCL高电平时SDA由低变高，产生停止条件 delay_us(5); } // 发送一个字节，返回从机应答位：0表示收到ACK，1表示NACK uint8_t I2C_SendByte(uint8_t data) { for (int i = 7; i >= 0; i--) { if (data & (1 << i)) SDA_H(); else SDA_L(); SCL_H(); // SCL高电平期间数据稳定 delay_us(2); SCL_L(); delay_us(2); } // 第9个时钟，读取从机应答 SDA_H(); // 主机释放SDA SCL_H(); delay_us(2); uint8_t ack = SDA_READ(); SCL_L(); delay_us(2); return ack; } // 接收一个字节，ackFlag=0表示读完后主机回NACK，=1表示主机回ACK uint8_t I2C_RecvByte(uint8_t ackFlag) { uint8_t data = 0; SDA_H(); // 主机释放SDA，让从机控制数据线 for (int i = 7; i >= 0; i--) { SCL_H(); delay_us(2); data |= (SDA_READ() << i); // 高电平期间读取一位 SCL_L(); delay_us(2); } // 主机在第9个时钟发送应答 if (ackFlag) SDA_L(); // 主机回ACK，告诉从机继续发 else SDA_H(); // 主机回NACK，告诉从机结束发送 SCL_H(); delay_us(2); SCL_L(); SDA_H(); // 释放SDA return data; }

这段代码的时序严格按照I2C规范，SDA只能在SCL为低电平时变化，SCL为高电平时数据必须稳定。每两位数据之间SCL有一个完整的低高位周期，保证了从机的采样窗口足够宽。延时取2微秒，对应的通信速率在100kHz左右，兼容性很好。

3.2 I2C地址扫描：让“没反应”变成“有反应”

总线上设备不响应，排查起来最麻烦的是不知道设备地址到底是多少。我写过一个地址扫描函数，循环向1到127所有7位地址发送一个读请求，看哪些地址能收到ACK。这个函数在调试时价值极高，插上设备，打印出扫描结果，立刻就知道哪个地址有设备在总线上。

void I2C_ScanBus(void) { printf("Scanning I2C bus...\r\n"); for (uint16_t addr = 1; addr < 128; addr++) { I2C_Start(); uint8_t ack = I2C_SendByte((addr << 1) | 0); // 地址 + 写标志 if (ack == 0) { printf("Found device at 0x%02X\r\n", addr); } I2C_Stop(); } printf("Scan done\r\n"); }

这个函数看起来简单，但设计上有讲究。每次只发送地址字节，不发送数据，发送完无论有没有ACK都立即产生停止条件。这样即使总线上有设备对写请求不感兴趣，整个探测过程中也不会干扰设备和总线状态。之前的经验是，某些设备在收到不属于自己的地址时会忽略，但收到停止条件后一定释放总线，所以这个方式是安全的。

在调用扫描函数之前，务必保证SDA和SCL都是高电平。如果扫描结果一个设备都没有，先检查上拉电阻、接线和供电，再用示波器看SDA上有没有正常的地址脉冲。

3.3 用BH1750光照传感器验证模拟I2C例程

BH1750是I2C接口的数字光照传感器，7位地址是0x23，写地址0x46，读地址0x47。它和EEPROM最大的不同是不用寄存器地址，直接发指令码。以连续高分辨率测量为例，整体流程是：上电 → 发Power On指令0x01 → 发连续测量指令0x10 → 等待180ms → 读2字节数据。

float BH1750_ReadLux(void) { uint8_t buf[2]; I2C_Start(); I2C_SendByte(0x46); // 地址 + 写 I2C_SendByte(0x01); // Power On I2C_Stop(); I2C_Start(); I2C_SendByte(0x46); I2C_SendByte(0x10); // 连续高分辨率模式 I2C_Stop(); HAL_Delay(180); // 测量时间要求180ms I2C_Start(); I2C_SendByte(0x47); // 地址 + 读 buf[0] = I2C_RecvByte(1); // 读高字节，回ACK buf[1] = I2C_RecvByte(0); // 读低字节，回NACK I2C_Stop(); uint16_t raw = (buf[0] << 8) | buf[1]; return (float)raw / 1.2f; // 分辨率1lux，除1.2得到实际值 }

这个例子完整展示了模拟I2C的典型用法。发送阶段所有字节都用I2C_SendByte，从机每收到一个字节都会回ACK，我们不对返回值做处理，因为BH1750正常情况下必然应答。读取数据时最后一个字节主机回NACK，这是I2C协议的规定——从机收到NACK就知道这是最后一个字节，会释放SDA等待停止条件。如果读两个字节都回ACK，从机会一直发送下去，主机就会卡在读数据的循环里。

BH1750的180ms测量延时不能省。我之前为了调快采集速度，把这个延时缩短到50ms，结果读回来的数据一直是上一次的结果或者全0。温度、光照这类传感器都有一个内部转换时间，数据手册上写得很清楚，照着做才是最省事的。

4. 实战问题排查：没反应、卡死、回读0xFF的完整方案

4.1 总线卡死怎么恢复

I2C调试中最常见的现象就是程序跑在HAL库的等待函数里出不来，或者软件模拟时SDA一直被拉低。总线卡死的根源通常是某个从机在发送过程中被异常终止，导致它在接收完8位数据后一直等待主机时钟，把SDA拉低不放。这时候主机再发起通信，SDA永远是低电平，起始条件都发不出来。

针对这个问题，我写了一个总线恢复函数。原理是强行产生9个SCL时钟脉冲并伴随一个停止条件，让卡死在半途的从机完成当前字节的剩余位，从而释放SDA。

void I2C_BusRecover(void) { // 先将SCL、SDA全部配置为开漏输出（如果此前已经改了模式） // 连续产生9个SCL脉冲 for (int i = 0; i < 9; i++) { SCL_L(); delay_us(5); SCL_H(); delay_us(5); } // 产生停止条件 SDA_L(); delay_us(5); SCL_H(); delay_us(5); SDA_H(); delay_us(5); // 重新验证总线是否恢复 if (SDA_READ() == 1) { // 总线已释放 } }

这个恢复函数我在好几个项目里救过急。使用时机是：每次I2C操作失败后、重试之前，都先调用一次。软件模拟I2C的好处在这里体现得很明显——GPIO始终在我们的掌控下，怎么折腾都不会锁死外设。如果是硬件I2C外设遇到BUSY位置位，需要调用__HAL_I22C_DISABLE或者干脆重新执行MX_I2C1_Init，操作步骤会麻烦不少。

4.2 SDA电平异常检查清单

如果总线恢复执行完，发起始条件时SDA仍然无法拉高，问题大概率出在硬件层面。检查顺序可以按这个清单来：

一、上拉电阻有没有焊。I2C是开漏总线，没有上拉电阻SCL和SDA就永远无法回到高电平。正常接法是3.3V电源各接一个4.7kΩ电阻到SCL和SDA，通信速率400kHz时可以换成2.2kΩ。

二、引脚是不是真的配成了开漏输出。如果把SDA配成了推挽输出，输出高电平时会强拉SDA到3.3V，这会和从机的开漏输出打架，严重时可能损坏引脚或从机。

三、从机有没有上电。从机不上电时，其内部保护二极管可能会把SDA钳位到地，主机看到的SDA一直是低电平。尤其是带掉电检测的传感器芯片，先确认供电再查信号。

四、SCL和SDA有没有接反。这种错误特别隐蔽，因为接反后设备偶尔能正常响应一次，放大看波形时钟比较乱。用逻辑分析仪抓SCL，如果SCL上出现数据跳变而不是规律的时钟脉冲，八成就是接反了。

五、3.3V从机接了5V上拉。如果从机是3.3V供电，而上拉电阻接到了5V，SDA高电平会超过从机的耐压范围。这会让设备偶尔出错甚至发热。总线电平不匹配时必须加电平转换电路。

4.3 常见问题速查表

把平时调试中遇到的问题整理成了一张速查表，按现象定位原因和解决方案，效率最高：

排查I2C问题时要记住一个顺序：先确认硬件连接和供电，再扫描总线地址，然后抓波形，最后才怀疑代码逻辑。很多“代码完全没问题”的项目，最后查出来都是上拉电阻虚焊或者地址弄错。反过来，地址扫描都扫不到设备，说明问题在底层，在上面反复调试HAL参数都是浪费时间。

另外分享一个实际经验。软件模拟I2C调试时，建议把通信速率调到比较慢（比如延时5微秒），配合万用表或者LED指示逐步确认每一段逻辑是否正确。对于模拟I2C来说，慢是优点不是缺点——时序越宽松，越容易观察和排查问题。硬件外设的速率可以直接用400kHz，但前提是总线上没有老旧设备。调试阶段用100kHz，稳定后再提高，这个习惯能省下很多抓波形的功夫。

我在实际项目里还有一个习惯：每个用到I2C的工程，都会先实现地址扫描函数并放在调试入口，确认从机应答后再进入具体业务逻辑。这个方法建议你直接抄进自己的工程模板里，以后换任何I2C设备，第一步都是扫描地址。总线这东西，只要地址能通，剩下的事情就好办多了。

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