不过自动生成的代码,调用HAL_I2C_XXX的API工作不正常,返回错误代码为I2C_BUSY 使用STM32的I2C接口使用时需要注意很多细节,不过HAL库中官方已经为用户根据这些细节做了处理,可以直接使用。不过这个I2C代码并不稳定,有些板子可以用,另一些则出错. 出错现象为调用HAL_I2C的API时,返回I2C_BUSY 查看寄存器 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)、H...
STM32HAL库I2C⼯作出错返回I2C_BUSY 使⽤stm32cubemx⽣成硬件I2C的代码 不过⾃动⽣成的代码，调⽤HAL_I2C_XXX的API⼯作不正常,返回错误代码为I2C_BUSY 使⽤STM32的I2C接⼝使⽤时需要注意很多细节，不过HAL库中官⽅已经为⽤户根据这些细节做了处理，可以直接使⽤。不过这个I2C代码并不稳定，...
具体依据没有找到,不过在HAL的说明文档中有要求这样的初始化顺序,同时其他的模块如SPI或UART,也都是先初始化模块(SPI,UART),再初始化GPIO void HAL_I2C_MspInit(I2C_HandleTypeDef* i2cHandle) { GPIO_InitTypeDef GPIO_InitStruct = {0};if(i2cHandle->Instance==I2C1) {/* USER CODE BEGIN I2C1_MspInit 0...
试着用MCU复位,是可以恢复的,说明硬件没死穴。又测试不用MCU复位,而是在程序中依次调用STM32Cube_FW_F4_V1.5.0固件库提供的如下两个初始化函数:HAL_I2C_DeInit(&hi2c1)、HAL_I2C_Init(&hi2c1),并不能保证一定恢复正常。 BUSY死锁时,用万用表测试I2C信号电压,SCL、SDA均为低电平。如果调用函数:HAL_I2C_...
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)、...
之后 SDA 卡在低电平并且 HAL_BUSY 在连续的 I2C 读取时返回。我可以重现此问题，同时强调 I2C 读取...
一.问题存在我用STM32F439IGT,为了确定问题存在,让I2C控制器作Master,先人为产生I2C总线故障。产生I2C总线故障的方法简单而粗暴:在I2C总线工作过程中,用镊子把SCL和SDA两个信号短路一下,很容易进入BUSY死锁状态。长时间短路也可能产生超时。HAL_I2C_Init()、HAL_I2C_Master_Transmit()、HAL_I2C_Master_Receive()...
中的I2C_WaitOnFlagUntilTimeout()函数，等待busy位变低。但是外部引脚通过示波器测试都处于拉高状态，...
__I2C1_RELEASE_RESET(); 再比如,有时可能碰到芯片外部LSE工作不稳定,除了排查其它因素外,我们还可以尝试在配置系统时钟前对RTC域先做强制复位操作。 __HAL_RCC_BACKUPRESET_FORCE(); __HAL_RCC_BACKUPRESET_RELEASE(); 总之,某外设工作途中出现异常,对其进行强制复位,这样我们可以不受那些不清晰或不确定的状态...