图解说明STM32硬件I2C状态寄存器标志位含义

深入理解STM32硬件I2C：状态寄存器标志位全解析

在嵌入式开发中，I2C通信几乎无处不在——从温湿度传感器到音频编解码器，从EEPROM存储到触摸屏控制器。而当项目对性能和稳定性提出更高要求时，越来越多的开发者选择放弃“软件模拟I2C”，转而使用STM32内置的硬件I2C模块。

但问题也随之而来：为什么有时候程序会“卡死”在等待TXE或ADDR？为什么总线明明空闲，却无法启动通信？又为何清除AF标志后仍无法恢复？

答案往往藏在一个被忽视的地方——状态寄存器SR1与SR2中的各个标志位。

本文将带你穿透层层抽象，直面硬件本质，通过图解+实战逻辑的方式，彻底讲清楚这些标志位的真实含义、触发机制以及正确处理方法。掌握之后，你不仅能写出更可靠的驱动代码，还能在调试时一眼看穿问题根源。

一、硬件I2C不是“黑盒子”：它其实是个状态机

很多初学者把I2C当作一个简单的“发送/接收”接口，调用函数就完事了。但实际上，STM32的硬件I2C是一个基于有限状态机（FSM）的精密外设，每一步操作都必须严格按照状态流转进行。

这个状态机的核心反馈来源，就是两个寄存器：

• SR1（Status Register 1）：主状态标志集合
• SR2（Status Register 2）：辅助状态补充信息

它们就像交通信号灯，告诉你：“现在可以走”、“前方拥堵”、“请让行”……只有读懂这些信号，才能安全高效地通行。

⚠️ 错误解读标志位 = 在红灯时强行过马路 → 系统崩溃、数据错乱、死锁频发。

二、SR1详解：每一个标志都是关键节点

✅ SB —— 起始条件已发出（Start Bit）

• 何时置位：当你设置START=1后，物理层成功拉低SDA再释放SCL时，SB自动置1。
• 意义：表示起始条件已生成，你可以开始写入从机地址了。
• 如何清除：读取SR1 + 写入DR（地址）

📌 常见误区：只等SB置位却不写地址 → 状态机停滞！

I2C_GenerateSTART(I2C1, ENABLE); while (!I2C_GetFlagStatus(I2C1, I2C_FLAG_SB)); // 等待SB I2C_Send7bitAddress(I2C1, dev_addr << 1, I2C_Direction_Transmitter); // 清除SB

🔍 技巧：不要单独轮询SB！应配合I2C_CheckEvent()检查完整事件。

✅ ADDR —— 地址传输完成且收到ACK

• 何时置位：地址字节发送完毕，并且从机返回了ACK。
• 意义：地址阶段结束，进入数据阶段。
• 如何清除：先读SR1，再读SR2

⚠️ 这是最容易出错的一点！很多人以为读一次就够了，其实必须连续访问SR1和SR2才能清掉ADDR。

否则：
- 后续的TXE不会正常工作
- 中断可能重复触发
- BTF行为异常

// 正确做法 if (I2C_GetFlagStatus(I2C1, I2C_FLAG_ADDR)) { (void)I2C1->SR1; // 先读SR1 (void)I2C1->SR2; // 再读SR2 → ADDR被清除 }

💡 小贴士：如果你用的是ST标准库或HAL库，I2C_CheckEvent()内部已经做了这一步，但手动操作寄存器时务必小心！

✅ TXE —— 发送数据寄存器空（Transmit Data Register Empty）

• 何时置位：DR寄存器的内容被转移到移位寄存器后，TXE=1。
• 意义：你现在可以往DR里写下一个字节了。
• 注意：
• 初始状态下TXE也为1（复位后DR为空）
• 每次写入DR后，TXE立刻清零，直到下一次转移完成

📌 使用建议：
- 主发送模式下，每次写完一个字节后等待TXE再次置位
- 最后一个字节发送前不要等待TXE，因为之后不再需要写DR

I2C_SendData(I2C1, byte); while (!I2C_GetFlagStatus(I2C1, I2C_FLAG_TXE)); // 等待可写入下一字节

✅ RXNE —— 接收数据寄存器非空（Receive Data Register Not Empty）

• 何时置位：接收到的一个完整字节已载入DR。
• 意义：快去读DR！否则下一个字节会覆盖它。
• 注意：必须在BTF为0之前读取，否则可能丢失最后一个字节

典型错误场景：

while (!I2C_GetFlagStatus(I2C1, I2C_FLAG_RXNE)); data = I2C_ReceiveData(I2C1); // 如果此时BTF也置位了，却没有及时处理Stop，会导致额外时钟周期

✅ 正确做法是在多字节接收末尾结合BTF判断是否该发NACK。

✅ BTF —— 字节传输完成（Byte Transfer Finished）

• 何时置位：一个完整的字节（8位数据 + ACK/NACK）已完成传输。
• 精度高于TXE/RXNE：它是真正反映“传输完成”的标志。
• 用途举例：
• 发送模式：可用于触发Stop条件
• 接收模式：用于决定是否发送NACK以终止接收

// 发送最后一个字节后，利用BTF发Stop while (!I2C_GetFlagStatus(I2C1, I2C_FLAG_BTF)); I2C_GenerateSTOP(I2C1, ENABLE);

📌 关键区别：
-TXE表示 DR 可写入（准备阶段）
-BTF表示 整个字节已发完（完成阶段）

❌ AF —— 应答失败（Acknowledge Failure）

• 何时置位：从机未在第9个时钟周期拉低SDA（即未回ACK）
• 常见原因：
• 从机地址错误
• 从机未上电或损坏
• 总线被拉死（SDA一直高）
• 上拉电阻过大导致上升沿缓慢

📌 必须主动清除AF标志，否则后续操作会被阻塞！

if (I2C_GetFlagStatus(I2C1, I2C_FLAG_AF)) { I2C_ClearFlag(I2C1, I2C_FLAG_AF); // 清除AF I2C_GenerateSTOP(I2C1, ENABLE); // 主动释放总线 return I2C_ERROR_DEVICE_NOT_FOUND; }

⚠️ 千万别忘了发STOP！否则总线一直处于占用状态。

⚠️ ARLO —— 仲裁丢失（Arbitration Lost）

• 仅出现在多主系统中
• 当两个主机同时发起通信，本机因SDA比较失败而退出竞争时，ARLO=1
• 应对策略：
• 清除ARLO
• 延迟重试
• 避免频繁抢占

if (I2C_GetFlagStatus(I2C1, I2C_FLAG_ARLO)) { I2C_ClearFlag(I2C1, I2C_FLAG_ARLO); Delay(10); retry_count++; if (retry_count < 3) goto restart; else return I2C_ERROR_BUS_CONFLICT; }

🔒 BUSY —— 总线忙标志

• 何时置位：只要SCL或SDA上有活动（高→低或低→高），BUSY=1
• 最佳实践：初始化I2C前一定要检查BUSY是否为0！

while (I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY)) { // 可加入超时保护 if (++timeout > MAX_TIMEOUT) { I2C_BusRecovery(); // 强制恢复总线 break; } }

如果忽略BUSY直接启用I2C，可能导致通信混乱甚至硬件冲突。

↔️ TRA —— 当前传输方向（Transmitter/Receiver）

• 由硬件自动设置
• 主发送时：TRA=1
• 主接收时：TRA=0
• 用途：配合DMA判断数据流向，实现双向DMA切换

三、SR2：隐藏的“上下文增强包”

虽然SR1是主力，但SR2提供了不可或缺的补充信息。

📌 实际开发中，我们最常用的是通过读SR2来清除ADDR，而不是获取这些扩展状态。

四、真实案例：一次完整的I2C写操作流程分解

以向AT24C02 EEPROM写一个字节为例：

1. 等待总线空闲
   c while (I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY));

2. 发送Start
   c I2C_GenerateSTART(I2C1, ENABLE); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT));

3. 发送设备写地址（0xA0）
   c I2C_Send7bitAddress(I2C1, 0xA0, I2C_Direction_Transmitter);

4. 等待ADDR并清除
   c while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) { if (I2C_GetFlagStatus(I2C1, I2C_FLAG_AF)) { /* handle NACK */ } }

5. 发送内存地址
   c I2C_SendData(I2C1, reg_addr); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED));

6. 发送数据
   c I2C_SendData(I2C1, data); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED));

7. 发送Stop
   c I2C_GenerateSTOP(I2C1, ENABLE);

整个过程依赖SR1中一系列标志的有序跳变。任何一个环节判断错误，都会导致失败。

五、那些年我们踩过的坑：常见问题与解决方案

❓ 问题1：程序卡死在等待TXE？

✅ 检查以下几点：
- 是否忘记发Start？
- 从机是否响应（AF是否置位）？
- 总线是否真的空闲（BUSY=1？）
- 是否有超时机制？

🔧 解决方案：加入超时检测

uint32_t timeout = 10000; while (!I2C_GetFlagStatus(I2C1, I2C_FLAG_TXE)) { if (--timeout == 0) { I2C_BusRecovery(); return ERROR_TIMEOUT; } }

❓ 问题2：ADDR清除不了？

✅ 原因几乎总是：只读了SR1，没读SR2

🔧 正确姿势：

if (I2C1->SR1 & I2C_SR1_ADDR) { volatile uint32_t tmp; tmp = I2C1->SR1; tmp = I2C1->SR2; (void)tmp; // 防止编译器优化 }

❓ 问题3：总线被“锁住”，始终BUSY=1？

✅ 可能原因：
- 外部设备故障，SDA/SCL被拉低
- 上电顺序不当导致I2C状态异常

🔧 恢复方法：GPIO强制模拟时序打脉冲

void I2C_BusRecovery(void) { GPIO_InitTypeDef gpio; // 将SCL/SDA配置为推挽输出 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); GPIO_StructInit(&gpio); gpio.GPIO_Mode = GPIO_Mode_Out_PP; gpio.GPIO_Speed = GPIO_Speed_50MHz; gpio.GPIO_Pin = GPIO_Pin_6; // SCL GPIO_Init(GPIOB, &gpio); gpio.GPIO_Pin = GPIO_Pin_7; // SDA GPIO_Init(GPIOB, &gpio); // 拉高SCL和SDA GPIO_SetBits(GPIOB, GPIO_Pin_6 | GPIO_Pin_7); // 打9个脉冲，尝试唤醒卡住的从机 for (int i = 0; i < 9; i++) { GPIO_ResetBits(GPIOB, GPIO_Pin_6); // SCL低 Delay_us(5); GPIO_SetBits(GPIOB, GPIO_Pin_6); // SCL高 Delay_us(5); } // 再次尝试释放总线 GPIO_ResetBits(GPIOB, GPIO_Pin_7); // SDA低（准备Stop） Delay_us(5); GPIO_SetBits(GPIOB, GPIO_Pin_6 | GPIO_Pin_7); // SCL和SDA同时高 → Stop }

📝 提示：此法可在初始化失败或通信异常后调用，极大提升系统鲁棒性。

六、设计建议：打造健壮的I2C通信层

七、结语：掌握状态机，才算真正驾驭硬件

STM32的硬件I2C并不复杂，但它要求你尊重协议、遵循流程、精准控制。

那些看似神秘的“卡死”、“无响应”、“间歇性失败”，背后往往是某个标志位没有正确处理所致。

当你学会看懂SB → ADDR → TXE → BTF这条主线，能够从容应对AF和ARLO带来的挑战，甚至能在总线“瘫痪”时用几根IO救回来——你就不再是“调API的程序员”，而是真正的嵌入式系统掌控者。

如果你在项目中遇到I2C难题，欢迎在评论区留言，我们可以一起分析波形、解读标志、找出病灶。

记住：每一个标志位，都是硬件在对你说话。听懂它，系统才会听话。