解决STM32I2C接口死锁在BUSY状态的问题.docxVIP

解决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官方客服提供的，关于死锁的可能机理和解决方案做了说明：/link?url=KB9p-TYrQcmVu1azHG66BXAcG6Pe6Bm2kWF_9ERSU35EOA8obiTVTDrZ6fZ3IOjfVAb71RCvJIiAODo4p4Sr0fUPDy0kQyyqWWJgxjfYHzO/link?url=KB9p-TYrQcmVu1azHG66BXAcG6Pe6Bm2kWF_9ERSU35EOA8obiTVTDrZ6fZ3IOjfVAb71RCvJIiAODo4p4Sr0fUPDy0kQyyqWWJgxjfYHzO2. STM社区，这个提到了初始化I2C引脚前应该先置为OUT及高电平。这在上电初始化时无虞，因为MCU复位后IO口为输入，并由外部上拉电阻拉为高电平。但在做故障恢复时很重要，因为此时IO口可能正被Master或Slave拉成低电平。 /module/forum/thread-518463-1-1.html/module/forum/thread-518463-1-1.html3. 这个解决方案和上面思想两个相仿，但是写了太多代码，又有放置位置的要求，看起来头大。仅作参考：/BLOG_ARTICLE_2154168.HTM/BLOG_ARTICLE_2154168.HTM4. 最重要的说明，在ST官方提供的STM32F4xx用户指南：RM0090 Reference manual Rev9，第845页，关于I2C_CR1，SWRST位的Note，提到解决BUSY死锁问题：意思是说SWRST位可以在出错或死锁时，用于复位I2C控制器，例如众所周知的BUSY位问题。我没有看其它老STM型号的手册，至少STM32F4xx有SWRST位，STM32L0xx用户指南提到可以用PE位复位。四．问题的解决方案按照ST手册的提示，经过各种尝试，本着尽量少改动代码、尽量不改动固件库里只读文件的原则，我的解决方案如下所述。假设主程序里有如下的代码，返回值ret不等于0表示出错，按stm32f4xx_hal_def.h头文件中的错误代码定义，返回值为0x02是HAL_BUSY，