Topic : I2C interfacing in STM32F107_MemsToLCD example

Forum : ARM

Original Post
Post Information Post
January 15, 2011 - 12:22pm
Guest

Hello
I was reading the STM32F107_MemsToLCD example given in C:\Program Files\Raisonance\Ride\Examples\ARM\REva.
In function MEMS_WriteOneByte() the following code is there
Line 75:
while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT))
{
if(I2C1->SR1 & I2C_FLAG_RXNE)
dr_temp = I2C1->DR;
}

I am not able figure out why this code is required Is it something related to
using I2C with 10bit,7bit device address?

Toolchain : Ride7
Target : STM32F107
Board : Reva3.3

Thx In advance
Lokesh
Replies
Post Information Post
+1
0
-1
January 17, 2011 - 9:35am
Raisonance Support Team

Hi Lokesh,

This is some remniscent of some older code that was trying to bullet-proof the I2C code.

There is a classic limitation (bug?) of the I2C bus: There is no standard way for a master to reset the devices. If I2C communication is broken in the middle of an I2C communication, and the master resets, then the subsequent I2C "START" events will be handled as SDA transitions.
As the REva is equipped with a 24C01 I2C EEPROM which has NO reset facility, the "classic" startup reset sequence is to send 9 START events then a STOP, in order to let any I2C device reset back to a default state.
The"classic" startup reset sequence can trigger the reception of a byte in the I2C receive buffer.

The code you are seeing is just flushing the I2C receive buffer before any read or write transfer.

This is a very typical example which shows why hardening I2C code is such a complex exercise. If you need strong, safe code you will have to think again about using our example :(

I hope this helps,
+1
0
-1
January 17, 2011 - 7:07pm
Guest

Hello
Thank you for the quick reply Bruno.
I am still not able to figure out I2C_EVENT_MASTER_MODE_SELECT flag . Is this flag cleared
after 9 clock cycles by hardware ?

I have tried to understand the sequence of events
1. I am reading the eeprom
2. Suddenly the processor is reset by the user
and the processor doesnot save the current status anywhere.
Also at the same time I have not finished reading the bus.
3. Processor starts the boot up activity
4. Processor again tries to read the eeprom again by giving start......
Now if the processor sees SDA bus driven at '0' initially the processor will see a hung bus.
This happened becoz eeprom was not reset and its excepecting that the processor
will read the unfinished bits and if '0' was the next bit then the eeprom has placed data correctly.
5. So as to avoid the hung bus the processor will read the eeprom and recover the bus.
So When the master detects the SDA line stuck in the low state, it merely needs to send some
additional clocks and generate a STOP condition.At max 9 clocks needed to be sent 8 for data and 1 for ACK.

A good reference for I2C RESET I found is : Implementing an I2C® Reset - AN-686 APPLICATION NOTE.

Thx in Advance
Lokesh
+1
0
-1
January 18, 2011 - 9:49am
Raisonance Support Team

Hi Lokesh,

Does the "Testall" example work on your REva? If it does, you may have trouble waiting for I2C_EVENT_MASTER_MODE_SELECT for various reasons, but using interrupts to read it out may be a good (better) architecture.

Let us know how you get through,