解决STM32 I2C接口死锁在BUSY状态的方法讨论

只看该作者 · 2019-10-18 11:34

关于STM32的I2C接口死锁在BUSY状态无法恢复的现象，网上已有很多讨论，看早几年比较老的贴子，有人提到复位MCU也无法恢复、只有断电才行的状况，那可是相当严重的问题。类似复位也无法恢复的情况是存在的，技术支持矢口否认问题存在，并不是正确面对问题的态度。比如我用这款F439芯片的SDRAM控制器，在错误操作后进入HardFault状态，复位无法恢复，JTAG也无法联机，只能断电重来，官方的Erratasheet里也提到了。

如果I2C接口无法可靠工作，那么所做的设计将存在严重隐患，不可能要求用户用断电的方法恢复系统。如果像某些网友提到弃用硬件I2C，转为GPIO模拟I2C时序，那么首先I2C时钟频率不易确定，因为STM32的时钟频率可以动态调节；此外不用硬件I2C，无法用中断、DMA等高级模式，会严重降低ARM内核效率。所以务须确认和解决这个问题。

只看该作者 · 2019-10-18 11:34

一．问题存在

我用STM32F439IGT，为了确定问题存在，让I2C控制器作Master，先人为产生I2C总线故障。产生I2C总线故障的方法简单而粗暴：在I2C总线工作过程中，用镊子把SCL和SDA两个信号短路一下，很容易进入BUSY死锁状态。长时间短路也可能产生超时。HAL_I2C_Init()、HAL_I2C_Master_Transmit()、HAL_I2C_Master_Receive()等函数返回值分别为HAL_BUSY（0x02）、HAL_TIMEOUT（0x03）。

试着用MCU复位，是可以恢复的，说明硬件没死穴。又测试不用MCU复位，而是在程序中依次调用STM32Cube_FW_F4_V1.5.0固件库提供的如下两个初始化函数：HAL_I2C_DeInit(&hi2c1)、HAL_I2C_Init(&hi2c1)，并不能保证一定恢复正常。

BUSY死锁时，用万用表测试I2C信号电压，SCL、SDA均为低电平。如果调用函数：HAL_I2C_DeInit(&hi2c1)，会函数释放IO口回到GPIO的默认状态（Input），此时再测SCL、SDA电压，均为高电平。这说明总线是被MCU这边的Master拉低的，而不是被Slave拉低的。当然也存在Slave刚好输出低电平拉低SDA的可能。

只看该作者 · 2019-10-18 11:35

二．出错代码位置跟踪

单步运行，可以看到进入stm32f4xx_hal_i2c.c程序中I2C读写函数不远处（如图阴影所在行），读BUSY位，总会得到SET的结果，无法继续执行后续程序而返回。

只看该作者 · 2019-10-18 11:36

三．参考文献

读了网上很多解决方案，其中比较有启发意义的有这几篇：

1. 百度文库，这个好像是ST官方客服提供的，关于死锁的可能机理和解决方案做了说明：
http://wenku.baidu.com/link?url=KB9p-TYrQcmVu1azHG66BXAcG6Pe6Bm2kWF_9ERSU35EOA8obiTVTDrZ6fZ3IOjfVAb71RCvJIiAODo4p4Sr0fUPDy0kQyyqWWJgxjfYHzO

2. STM社区，这个提到了初始化I2C引脚前应该先置为OUT及高电平。这在上电初始化时无虞，因为MCU复位后IO口为输入，并由外部上拉电阻拉为高电平。但在做故障恢复时很重要，因为此时IO口可能正被Master或Slave拉成低电平。http://www.stmcu.org/module/forum/thread-518463-1-1.html

3. 这个解决方案和上面思想两个相仿，但是写了太多代码，又有放置位置的要求，看起来头大。仅作参考：http://bbs.**/BLOG_ARTICLE_2154168.HTM

4. 最重要的说明，在ST官方提供的STM32F4xx用户指南：RM0090 Reference manualRev9，第845页，关于I2C_CR1，SWRST位的Note，提到解决BUSY死锁问题：

意思是说SWRST位可以在出错或死锁时，用于复位I2C控制器，例如众所周知的BUSY位问题。我没有看其它老STM型号的手册，至少STM32F4xx有SWRST位，STM32L0xx用户指南提到可以用PE位复位。

只看该作者 · 2019-10-18 11:36

四．问题的解决方案

按照ST手册的提示，经过各种尝试，本着尽量少改动代码、尽量不改动固件库里只读文件的原则，我的解决方案如下所述。假设主程序里有如下的代码，返回值ret不等于0表示出错，按stm32f4xx_hal_def.h头文件中的错误代码定义，返回值为0x02是HAL_BUSY，0x03是HAL_TIMEOUT，这两个返回值都可能得到。下面程序里红色的两行是错误处理必须的：

只看该作者 · 2019-10-18 11:37

4.1 主程序改动，加错误处理代码2行：

unsigned char ret = Sensor_ReadData(uint8* buf); // I2C读写函数

if (ret != 0)  {                //I2C故障处理

   HAL_I2C_DeInit(&hi2c1);    //释放IO口为GPIO，复位句柄状态标志

   HAL_I2C_Init(&hi2c1);       //这句重新初始化I2C控制器

}

else  {

   // 。。。。I2C无错误时的正常程序

}

只看该作者 · 2019-10-18 11:38

4.2 子程序的改动，加7行代码：

上面HAL_I2C_Init(&hi2c1)函数会调用HAL_I2C_MspInit(hi2c)函数，这个函数在stm32f4xx_hal_msp.c文件中实现，主要是初始化IO口以及外设，由STM32CubeMX工具生成或用户自行编写，非只读文件。以下节选该函数第一段，其中I2C端口用哪个pin，是由用户自己设定的，我这里用的PB6、PB7。红、绿底色的几行是为了处理BUSY死锁问题专门插入的。
void HAL_I2C_MspInit(I2C_HandleTypeDef *hi2c)

{

  GPIO_InitTypeDef GPIO_InitStruct;

  if(hi2c->Instance==I2C1)

  {

__I2C1_CLK_ENABLE();

// PB6 ---->  I2C1_SCL

// PB7 ---->  I2C1_SDA

// strong pull-uphigh to recover from locking in BUSY state

GPIO_InitStruct.Pin = GPIO_PIN_6|GPIO_PIN_7;    //此行原有

GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; //GPIO配置为输出

GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;       //强上拉

HAL_GPIO_Init(GPIOB,&GPIO_InitStruct);

HAL_GPIO_WritePin(GPIOB, 6, GPIO_PIN_SET);    //拉高SCL

HAL_GPIO_WritePin(GPIOB, 7, GPIO_PIN_SET);    //拉高SDA

   hi2c->Instance->CR1= I2C_CR1_SWRST;       //复位I2C控制器

hi2c->Instance->CR1= 0;             //解除复位（不会自动清除）

// 以下是原有代码

GPIO_InitStruct.Pin = GPIO_PIN_6|GPIO_PIN_7;

GPIO_InitStruct.Mode = GPIO_MODE_AF_OD;

GPIO_InitStruct.Pull = GPIO_PULLUP;

GPIO_InitStruct.Speed = GPIO_SPEED_FAST;

GPIO_InitStruct.Alternate = GPIO_AF4_I2C1;

HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

  }

//。。。

}

只看该作者 · 2019-10-18 11:39

上面程序中，把I2C端口配置成GPIO-OUTPUT，并强制拉高，是必需的。注意到手册里关于SWRST位说明的第一句：“When set, the I2C isunder reset state. Before resetting this bit,make sure the I2C lines are released and the bus is free.” 意思就是置位SWRST，会使I2C控制器保持在复位状态。解除复位前，确保I2C总线已经释放到空闲状态，即SCL、SDA均为高电平，再恢复I2C控制器。所以解除复位是用户来做的，硬件不会自动清除该位。

只看该作者 · 2019-10-18 11:39

五．结论

我用这款STM32F439IGT单片机，I2C部分没有出现断电才能解除BUSY死锁的严重问题，看来STM已经意识到这个硬BUG，并在后期产品里逐步进行了改进。

在没有硬件死穴的情况下，我这里仅增加10行程序，就可以用软件恢复故障。多次尝试，触发I2C故障时，一次就可以恢复，无需加延时等语句，也未改动现有固件库代码。