Associate III

Question

stm32cube I2c busy stm32F107

Forum|Forum|9 years ago
November 24, 2016
7 replies
2019 views

Posted on November 24, 2016 at 15:43

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 below

void 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-stm32f107

STM32Cube MCUs packages

This topic has been closed for replies.

I

Imen.D

ST Technical Moderator

Posted on December 02, 2016 at 11:06

Dear User,

Your request is reported internally for checking.

Thanks for highlighting this issue.

Best Regards

-Imen-

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Thanks

ali elhayek

Associate

Posted on January 10, 2017 at 09:19

I have the same problem, i did the same but it is not solved !!

I

Imen.D

ST Technical Moderator

Posted on January 10, 2017 at 11:46

Hello,

Please check the

http://www.st.com/content/ccc/resource/technical/document/errata_sheet/8d/85/aa/39/f4/58/40/e8/CD00238166.pdf/files/CD00238166.pdf/jcr:content/translations/en.CD00238166.pdf

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

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Thanks

ali elhayek

Associate

Posted on January 10, 2017 at 13:31

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

przemyslaw2

Associate

Posted on February 13, 2017 at 15:06

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 calling

HAL_I2C_Init()

therein, one needs to cycle 'set --> reset' on

SWRST

bit of

I2C1->CR1

register. It seems HAL-related, since manual tweaking of control register solves the issue.

Przemek

Bob jenkins

Associate II

Posted on August 16, 2017 at 13:06

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:

http://www.st.com/content/ccc/resource/technical/document/errata_sheet/7d/02/75/64/17/fc/4d/fd/CD00190234.pdf/files/CD00190234.pdf/jcr:content/translations/en.CD00190234.pdf#page26

And here:

https://electronics.stackexchange.com/questions/272427/stm32-busy-flag-is-set-after-i2c-initialization

https://electronics.stackexchange.com/questions/267972/i2c-busy-flag-strange-behaviour