STM32F407 Disc pin pulled high after being used as SDA pin

[DaveBunyan]

Hi, I am trying to read data from a sensor over I2C, I am using pin B8 as the SCL line and B9 as the SDA line. The code worked once and after reading the data from the sensor, pin B9 got stuck pulled low. I terminated and reloaded the debug session and the IDR for pin B9 was pulled high straight after startup, before running any code at all, and after stepping through the code it gets pulled low as soon as I enable the RCC for GPIOB. I switched to pin B7 and that worked once and I noticed that both B7 and B9 are pulled high before I run any code. I can switch back and forth between the pins and it runs through once before the pin being used for SDA gets stuck low. Also the temperature value I got from my sensor after converting it was 338.1 degrees Celsius. I am not sure if I made a mistake converting it or this is something to do with the issue but I can't work out why the pins would be pulled high after turning the board on. I've tried attaching the pin to ground and it still exhibits the same behaviour.

Thanks,

Dave

[Foued_KH]

Hello @DaveBunyan , 

Could you please share GPIO settings?

• A start condition is defined as a transition from high to low on the SDA line while the SCL line is high.
• A stop condition is defined as a transition from low to high on the SDA line while the SCL line is high.

After the initialization the SDA and SCL should be at the high level : 

 

You can try checking the datasheet for your sensor to see what the valid temperature range is and make sure that your conversion code is correctly converting the raw sensor data to a temperature value.

Foued

[LCE]

The idle state of an I2C bus is that both SDA and SCL are high, so that's rather a good start.

I don't know the F407 discovery board, so is that an on-board sensor? Then hopefully the designers did the right thing and placed some pull-up resistors on the I2C signals.

Anyway, check all I2C communication with a scope, with only 2 wires and for a temp sensor probably only a few bytes it's not too hard to decode.

> ... and after reading the data from the sensor, pin B9 got stuck pulled low.

That sounds like a not issued stop state.

> ... it gets pulled low as soon as I enable the RCC for GPIOB

That shouldn't be a problem, when you init the GPIO it should be high again. Is it?

[DaveBunyan]

I am using an external sensor and have 10k ohm pull up resistors for the SDA and SCL lines. After I init the GPIO it stays low, which I am assuming is causing the BUSY bit to be set as soon as I init I2C. If I change from B9 to B7 then it works once through the code and then it gets stuck low and exhibits the same behaviour on start-up

[DaveBunyan]

This is the settings for the GPIO. I have written the drivers myself and to just learn how everything works. I am going to try it using the HAL drivers to see if that makes a difference and now.

void I2C1_GPIOInit(void)

{

GPIO_Handle_t I2CPins;

 

GPIO_PClockControl(GPIOB, ENABLE);

I2CPins.pGPIOx = GPIOB;

I2CPins.GPIO_PinConfig.GPIO_PinMode = GPIO_MODE_ALTFN;

I2CPins.GPIO_PinConfig.GPIO_PinOPType = GPIO_OP_TYPE_OD;

I2CPins.GPIO_PinConfig.GPIO_PinPuPdControl = GPIO_NO_PUPD;

I2CPins.GPIO_PinConfig.GPIO_PinAltFuncMode = 4;

I2CPins.GPIO_PinConfig.GPIO_PinSpeed = GPIO_SPEED_FAST;

 

// SCL Pin

I2CPins.GPIO_PinConfig.GPIO_PinNumber = GPIO_PIN_NO_8;

GPIO_Init(&I2CPins);

 

// SDA Pin

I2CPins.GPIO_PinConfig.GPIO_PinNumber = GPIO_PIN_NO_9;

GPIO_Init(&I2CPins);

}

[Foued_KH]

I suggest you to use STM32CubeMX , It helps you for the configuration of the STM32 peripherals and Clock configuration.

Foued

[TDK]

If SDA is stuck high low, it suggests the communication was halted and the slaves are still expecting more clocks from the master. There is nothing to solve here, it's just a shortcoming of the I2C protocol.

To reset, toggle SCL 9 times on startup (by initializing as an GPIO OD output and toggling) before initializing it in I2C mode.

Note that I2C lines should have external pullups to ensure they are idle high immediately after powerup.

Also note that IDR isn't accurate prior to enabling the GPIO clock.

[DaveBunyan]

I have tried it initializing the code with STM32CubeMX and I2C_Master_Transmit returns HAL_BUSY. The BUSY bit gets set as soon as MX_I2C1_Init() gets called

[LCE]

Maybe there's something else connected on the discovery board?