HAL_I2C_IsDeviceReady Always Returns HAL_BUSY when Connecting STM32 Nucleo F446ZE Board and MPU-9250

[bvujic]

Hello, 

I am currently facing an issue while attempting to establish communication between an STM32 Nucleo F446ZE development board and an MPU-9250 sensor using I2C protocol. I am utilizing the HAL_I2C_IsDeviceReady function from the Hardware Abstraction Layer (HAL) library to check the readiness of the I2C device (MPU-9250) before initiating communication. Regardless of the absence of a physical connection between the STM32 Nucleo F446ZE board and the MPU-9250 sensor, the HAL_I2C_IsDeviceReady function consistently returns HAL_BUSY as the status.

I have also tried to delete everything from the stm32 microcontroller memory using STM32 ST-LINK Utility, but it didn't help.

I think MPU9250 sensor is not a problem because when I connect it with Raspberry Pi 3 Model B via I2C communication protocol it works fine, I can read all sensor data and command for Raspberry terminal to detect i2c devices ' i2cdetect -y 1' returns the address of i2c on this sensor. But when I connect STM32 Nucleo F446ZE to Raspberry via I2C protocol, there is no any sigh of communication, command 'i2cdetect -y 1' doesn't return the memory address of I2C on STM32 board, it is just empty.

Function HAL_I2C_Mem_Read(&hi2c1, MPU9250_ADDRESS, MPU9250_WHO_AM_I, I2C_MEMADD_SIZE_8BIT, &who_am_i, 1, HAL_MAX_DELAY) returns 0x00.

I've generated the firmware code using STM32CubeMX.

Can you, please, help me with this problem? Do you have any idea what might cause this state and how to fix this?

Thank you!

[TDK]

HAL_BUSY is returned if the BUSY bit is set. The BUSY bit is set if SCL or SDA is low instead of what it should be at idle, high.

This is a hardware issue, not a software issue. Some possibilities:

• Check that your chip is connected correctly and has power.
• Ensure external pullups of appropriate strength (about 1-5 kOhm) are on the SDA and SCL lines.
• Ensure the pins used for I2C are not being used by another peripheral. You can check the nucleo schematic for this.

[Foued_KH]

Hello @bvujic ,

Connect an oscilloscope to check SDA & SCL behavior.
You may need to add external pullups on the I2C bus.

Foued!

[bvujic]

I've tried adding external pullups on the I2C bus but there is no any change. It is still the same error.

Is it possible that is a problem in pins and their settings?

For I2C1 I've used STM32 pins D15(SCL) and D16(SDA) on Right Connector - CN7, but next time also tried A4(SDA) and A5(SCL) on Left Connector - CN9 and set like this in CubeMX:

 

 

Did I make a mistake somewhere? Do I need to use other pins? Is this all correct?

Thank you!

[Foued_KH]

Hi @bvujic , 

Set GPIO Pull-Up/Pull-down at : pull-up and set the frequency at 400KHz : " The internal registers and memory of the MPU-9250 can be accessed using either I2C at 400 kHz " MPU datasheet

Foued

[TDK]

Pin settings look fine. Seems like a hardware issue. How is the MPU9250 board connected? What board is it? Does it have power? Is I2C mode selected? Are SCL/SDA high when power is connected before any code runs? If not, that's a hardware issue.