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

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

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

 

一．问题存在

我用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的可能。

 

二．出错代码位置跟踪

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

 

 

三．参考文献

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

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.ednchina.com/BLOG_ARTICLE_2154168.HTM

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

 

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

 

四．问题的解决方案

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

 

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无错误时的正常程序

    }

 

 

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

上面HAL_I2C_Init(&hi2c1)函数会调用HAL_I2C_MspInit(hi2c)函数，这个函数在stm32f4xx_hal_msp.c文件中实现，主要是初始化IO口以及外设，由STM32CubeMX工具生成或用户自行编写，非只读文件。如下节选该函数第一段，其中I2C端口用哪一个pin，是由用户本身设定的，我这里用的PB六、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);

  }

//。。。

}

 

上面程序中，把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控制器。因此解除复位是用户来作的，硬件不会自动清除该位。

 

五．结论

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

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

 

                                        Circuitlife

                                      2015年6月3日