I2C Start Problem on STM32F205

[nate1]

Posted on August 30, 2014 at 00:53

I am attempting to communicate via I2C to another ST device (LPS331AP) and read its sensor values. However, I am not able to initiate the I2C session properly. On the wire, I can see that the start signal is actually manipulating the clock line as well (you can see a simultaneous dip on both lines in my attachment). The result appears to show the master (STM32) zeroing the MSB of the intended slave address. The master appears to be addressing 0x38, while the slave address should be 0xB8. 

Any idea why this may be? Thanks #i2c-stm32f2

[nate1]

Posted on September 02, 2014 at 07:22

Any idea if this is an STM32 issue? Look at all familiar to anyone?

[nate1]

Posted on September 02, 2014 at 18:36

Just to be clear, these are the regions of the waveform I am concerned with: The start sequence and the MSB of the slave address. I am still confused as to why the slave MSB is being sent as a zero.

[stm322399]

Posted on September 02, 2014 at 19:04

I2C run very well on many devices including F429 i am working with. Maybe the F205 has some issue ... possible ... but this would not be my first bet.

Concerning your problem: * the double dip does not look good at all (GPIO switch glitches, I2C start glitches, I don't know) but I guess it would be better when they were not here. * one can see a nice start (sda going low during SCL high) * one can see that the byte being transferred is 0x70 corresponding to a write to slave 0x38. The I2C slave address is not 0xb8, this is the value to be sent a the first byte, the address is 0xb8>>1=0x5c. But if you called a function that requires the I2C address (0x5c) and gave 0xB8 as argument, the generated byte can will be 0x70, wiping the MSB, instead of the expected 0xB8. Check the code.

[nate1]

Posted on September 02, 2014 at 21:27

Thanks, Laurent. Indeed, the right shift was a factor and has resolved the waveform issue I was seeing. Additionally, it appears the slave device is now acknowledging the transfer, as I can see the data line remaining low after the final bit of the slave address is sent. 

However, the STM32F2 is now not recognizing the receiver's acknowledgement and the I2C routine times out after sending the address, before attempting to send data. Basically, the change now is that the last clocked bit on the line is zero, which I believe is progress, but not the end of the story.

[Tesla DeLorean]

Posted on September 02, 2014 at 21:53

And you're driving the pins in OD mode, with external pull-ups? Perhaps if you share some code and schematics for the issue you'll get more feedback.

[nate1]

Posted on September 02, 2014 at 23:14

Thanks, Clive. Yes, the pins are configured for Alt Function and Open Drain:

    GPIO_InitStructure.GPIO_Mode  = GPIO_Mode_AF;

    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;    GPIO_InitStructure.GPIO_OType = GPIO_OType_OD;    GPIO_InitStructure.GPIO_PuPd  = GPIO_PuPd_NOPULL;They are both pulled high with a 4k to 3v3. I am actually using a framework called WICED from Broadcom, so the API functions will probably not be very useful, but I can summarize. The gist is, the device sends a start signal, send the 7-bit address, the slave appears to hold the line low as an ACK, but then the processor code is timing out. The sending is done by assigning the data to the I2C2->DR register (I believe that is CMSIS?). The timeout is from the following code, which I believe is calling a standard peripheral function from ST:

    while ( I2C_CheckEvent( I2C2, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED ) != SUCCESS )

    {        number_of_waits--;        if ( number_of_waits == 0 )        {            return WICED_TIMEOUT;        }    }I'm not sure if the 

I2C_CheckEvent 

function is something standard? But that is the lowest level function I have traced so far.

[nate1]

Posted on September 03, 2014 at 00:00

In further research, it looks like 

I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED

should indicate an issue with a slave acknowledgement. However, my scope is showing the final clocked bit to be held low (hopefully by the properly addressed slave device, tested by changing the slave address and noticing the last bit is no longer low). 

[nate1]

Posted on September 03, 2014 at 01:29

Looks like the fix was to set speed mode to standard, I had it on low speed. Not sure why that fixes the problem, but it works now. Thanks for all the help.