2016-11-24 06:43 AM
Hi,
I found an issue in the smt32cubeMX (ver 4.17.0 stm32F1 lib ver 1.4.0) when generating the I2C init code.I have an EEPROM connected to a smt32F107VC micro through I2C.Stm32cube does generate the following code to initialize the I2C.void HAL_I2C_MspInit(I2C_HandleTypeDef* i2cHandle){ GPIO_InitTypeDef GPIO_InitStruct; if(i2cHandle->Instance==I2C1) { /* USER CODE BEGIN I2C1_MspInit 0 */ /* USER CODE END I2C1_MspInit 0 */ /**I2C1 GPIO Configuration PB6 ------> I2C1_SCL PB7 ------> I2C1_SDA */ GPIO_InitStruct.Pin = I2C_SCL_EEPROM_Pin|I2C_SDA_EEPROM_Pin; GPIO_InitStruct.Mode = GPIO_MODE_AF_OD; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); /* Peripheral clock enable */ __HAL_RCC_I2C1_CLK_ENABLE(); /* USER CODE BEGIN I2C1_MspInit 1 */ /* USER CODE END I2C1_MspInit 1 */ }}When I start this code my I2C interface is always busy, I found out that starting the I2C clock before to initialize the GPIO does fix it. See code belowvoid HAL_I2C_MspInit(I2C_HandleTypeDef* i2cHandle){ GPIO_InitTypeDef GPIO_InitStruct; if(i2cHandle->Instance==I2C1) { /* USER CODE BEGIN I2C1_MspInit 0 */ // must be done otherwise I2c is busy //????? __HAL_RCC_I2C1_CLK_ENABLE(); /* USER CODE END I2C1_MspInit 0 */ /**I2C1 GPIO Configuration PB6 ------> I2C1_SCL PB7 ------> I2C1_SDA */ GPIO_InitStruct.Pin = I2C_SCL_EEPROM_Pin|I2C_SDA_EEPROM_Pin; GPIO_InitStruct.Mode = GPIO_MODE_AF_OD; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); /* Peripheral clock enable */ __HAL_RCC_I2C1_CLK_ENABLE(); /* USER CODE BEGIN I2C1_MspInit 1 */ /* USER CODE END I2C1_MspInit 1 */ }}i checked in other driver and it looks like for SPI or UART drivers the clock is always started before the GPIO is configured. #stm32cube-i2c-busy-stm32f1072016-12-02 02:06 AM
Dear User,
Your request is reported internally for checking. Thanks for highlighting this issue. Best Regards -Imen-2017-01-10 12:19 AM
I have the same problem, i did the same but it is not solved !!
2017-01-10 03:46 AM
Hello,
Please check the
and review if you have same conditions as described in 'I2C analog filter may provide wrong value, locking BUSY flag and preventing master mode entry'.You can try to use another combination of SCL & SDA pins (if available).
Please keep us informed about your progress on this issue.
Best Regards
Imen
2017-01-10 05:31 AM
Hello
thank you. i can not change the pins of the SCL and SDA because I am using STM3210C_EVAL and EEPROM is connected to B.6 and B.7.
I did the next steps
hi2c1.Instance->CR1 &= ~I2C_CR1_PE; GPIO_InitTypeDef GPIO_InitStruct; GPIO_InitStruct.Pin = GPIO_PIN_6|GPIO_PIN_7; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD; GPIO_InitStruct.Speed = GPIO_SPEED_HIGH; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); HAL_GPIO_WritePin(GPIOB,GPIO_PIN_7|GPIO_PIN_6,GPIO_PIN_SET); HAL_GPIO_WritePin(GPIOB,GPIO_PIN_7,GPIO_PIN_RESET); HAL_GPIO_WritePin(GPIOB,GPIO_PIN_6,GPIO_PIN_RESET); HAL_GPIO_WritePin(GPIOB,GPIO_PIN_6,GPIO_PIN_SET); HAL_GPIO_WritePin(GPIOB,GPIO_PIN_7,GPIO_PIN_SET);GPIO_InitStruct.Pin = GPIO_PIN_6|GPIO_PIN_7; GPIO_InitStruct.Mode = GPIO_MODE_AF_OD; GPIO_InitStruct.Speed = GPIO_SPEED_HIGH; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);hi2c1.Instance->CR1|=I2C_CR1_SWRST; hi2c1.Instance->CR1&=~I2C_CR1_SWRST; hi2c1.Instance->CR1 |= I2C_CR1_PE; I2C is not busy anymore but the other registers are wrong now so i write there values manually like following hi2c1.Instance->CR2 =0x824; hi2c1.Instance->OAR1=0x40A0; hi2c1.Instance->CCR=0x8028; hi2c1.Instance->TRISE=0xB;Best Regards;
Ali ElHayek
2017-02-13 06:06 AM
Hello,
There is a similar problem when trying to use the LM303DLHC gyro-sensor on board of F411E-Discovery board. The I2C lines are reported HAL_BUSY. To solve this issue, prior to configuring the interface in
MX_I2C1_Init()
and callingHAL_I2C_Init()
therein, one needs to cycle 'set --> reset' onSWRST
bit ofI2C1->CR1
register. It seems HAL-related, since manual tweaking of control register solves the issue.Przemek
2017-08-16 04:06 AM
Thanks for this post.
I have a simple STM32F103C8T6 based 'blue pill' board, and ran into a similar problem.
Enabling clocking alone or setting-resetting the RST bit didn't help, but together (when put before initializing any peripherals) they did the trick: I am no longer getting the HAL_BUSY error upon mcu startup:
/* USER CODE BEGIN SysInit */
__HAL_RCC_I2C1_CLK_ENABLE(); HAL_Delay(100; __HAL_RCC_I2C1_FORCE_RESET(); HAL_Delay(100); __HAL_RCC_I2C1_RELEASE_RESET(); HAL_Delay(100);/* USER CODE END SysInit */The problem I had was I2C read/write functions returning HAL_BUSY, if the stm32 board was rebooted by pressing the Reset button for longer than a second, or it happened even occasionally from time to time after a 'regular' reboot.
EDIT: the problem wasn't resolved completely :(.
Occasionally I still get HAL_BUSY upon startup. But at least this happens much less often than before, usually when the reset button was pressed for too long (several seconds). I think I can live with that.
EDIT2: See here for possible complete solution of the problem:
And here:
https://electronics.stackexchange.com/questions/267972/i2c-busy-flag-strange-behaviour
2018-03-05 02:45 AM
Thanks for the post. It helped me to solve my problem.
Ioan