FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

I2c device never sets SB bit after start is transmitted.

Go to solution
TSchm
Associate

‎2019-06-03 02:07 PM

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?

Labels:
0 Kudos
1 ACCEPTED SOLUTION

Accepted Solutions
Go to solution
TSchm
Associate

‎2019-06-07 10:30 AM

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.

View solution in original post

0 Kudos
1 REPLY 1
Go to solution
TSchm
Associate

‎2019-06-07 10:30 AM

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.

0 Kudos
Top