Skip to main content
TSchm
TSchm
Associate
June 3, 2019
Solved

I2c device never sets SB bit after start is transmitted.

  • June 3, 2019
  • 1 reply
  • 1909 views

My MPU is STM32L152RET6

I am using i2c channel 1 to communicate with an i2c device.  I used the standard device set and verified the hardware appears to be set up correctly. When I set the "Start" bi in control register 1 (CR1), a start condition is generated on the i2c bus but the next thing the driver does is wait for the "SB" bit to got high in the status register 1 (SR1). This is the normal behavior. However, SB never goes high. I tried writing the address of the i2c device ins the data register (DR) (just to see if it would transmit the address) but it did not work. The problem is the SB bit never sets and the driver times out. Any ideas what might be wring?

This topic has been closed for replies.
Best answer by TSchm

I got this working. I had it all configured correctly. The first thing the HAL driver does is send a "Start" condition.

When that happened the BUSY bit sets but the SB bit never set so the system was hung and timed out.

I noticed this small print in the I2C section of the reference manual in section 26.6.21:

26.6.1 I2C Control register 1 (I2C_CR1)

Address offset: 0x00

Reset value: 0x0000

:

Bit 15 SWRST: Software reset

Bit 15 SWRST: Software reset

When set, the I2C is under reset state. Before resetting this bit, make sure the I2C lines are

released and the bus is free.

0: I2C Peripheral not under reset

1: I2C Peripheral under reset state

Note: This bit can be used to reinitialize the peripheral after an error or a locked state. As an

example, if the BUSY bit is set and remains locked due to a glitch on the bus, the

SWRST bit can be used to exit from this state.

This got me thinking. We had another product that used this CPU and the I2C bus but it

was set up exactly the same as my product. HOWEVER, it used 4.7k pull ups on the SDA

and the SCL lines. We had 10k pull ups. I had the hardware engineer change them to 4.7k pull ups

and then I was able to talk corretly down the i2c bus!

SO TERMINATION OF THE I2C SIGNALS IS VERY IMPORTAANT TO GET THIS I2C DEVICE RUNNING!

Thought this little bit of information may help someone some day.

1 reply

TSchm
TSchmAuthorBest answer
Associate
June 7, 2019

I got this working. I had it all configured correctly. The first thing the HAL driver does is send a "Start" condition.

When that happened the BUSY bit sets but the SB bit never set so the system was hung and timed out.

I noticed this small print in the I2C section of the reference manual in section 26.6.21:

26.6.1 I2C Control register 1 (I2C_CR1)

Address offset: 0x00

Reset value: 0x0000

:

Bit 15 SWRST: Software reset

Bit 15 SWRST: Software reset

When set, the I2C is under reset state. Before resetting this bit, make sure the I2C lines are

released and the bus is free.

0: I2C Peripheral not under reset

1: I2C Peripheral under reset state

Note: This bit can be used to reinitialize the peripheral after an error or a locked state. As an

example, if the BUSY bit is set and remains locked due to a glitch on the bus, the

SWRST bit can be used to exit from this state.

This got me thinking. We had another product that used this CPU and the I2C bus but it

was set up exactly the same as my product. HOWEVER, it used 4.7k pull ups on the SDA

and the SCL lines. We had 10k pull ups. I had the hardware engineer change them to 4.7k pull ups

and then I was able to talk corretly down the i2c bus!

SO TERMINATION OF THE I2C SIGNALS IS VERY IMPORTAANT TO GET THIS I2C DEVICE RUNNING!

Thought this little bit of information may help someone some day.

Terms & ConditionsAccessibility statement