STM32F405, ChibiOS-RT 18.2: I2C always busy Topic is solved

[mroth]

Hi,

In our project, we recently upgraded from ChibiOS-RT 17.6 to 18.2. We use an STM32F405 microcontroller. Using 18.2 the I2C status register 2 always has a value of 2 (the busy flag is set). As a result, the I2C driver gets stuck in a while loop when trying to transmit a message via I2C (LLD/I2Cv1/hal_i2c_lld.c: the while loop in i2c_lld_master_transmit_timeout).
I tried restarting the board and executing a software reset of the I2C bus (using the CR1 SWRST flag), but that didn't solve the problem.

On a different board we are using an STM32F103 microcontroller and the I2C bus works fine with both ChibiOS 17.6 and 18.2. The I2C also worked fine on the STM32F405 microcontroller when we used ChibiOS 17.6.

Do you have any idea why we see this behavior on the STM32F405 microcontroller?

Thank you in advance!

[Giovanni]

Hi,

Are the GPIO pins programmed to the appropriate alternate mode and have the external pull-up resistors? the driver is seeing a stuck bus.

Giovanni

[mroth]

Yes, the I2C SCL and SDA pins are all set to alternate mode and they all have external pull up resistors. If I flash ChibiOS-RT 17.6 onto the microcontroller, the I2C bus is working, so I am fairly certain it's not a hardware problem. I also just checked whether it is just one I2C bus being stuck, but it seems the problem includes both of them.

[Giovanni]

The driver is the same on 17 and 18, no significant changes. The fact that it works on the F1 makes me think this could be board-related (or setup related).

Check your board files, also check if multiple pins are mapped on the same fiunction.

Giovanni

[mroth]

Yes, you are correct. The problem is solved now and it was related to the PAL setup in the board.c file.
I looked at one of the board.c files in the hal/boards directory and realized I hadn't changed from the old PAL initialization to the new way of doing it correctly. Now that I correctly initialized the GPIOs that way, everything works fine, thank you!

[faisal]

One thing to keep in mind which isn't apparent at first is the pin driver configuration. Just because a pin is set to I2C doesn't mean that the pin driver configuration is set to Hi-Z. You have to set it. I've slipped up on more than one occasion where there driver configuration was set to push-pull and resulted in I2C not working.

[Jacon]

... the pin driver configuration is set to Hi-Z ...

I would rather use Floating as input & Open Drain with PullUp/Down switched off (replaced with externals) as output