I2C EEPROM

whhofmeyr · ‎2005-04-04

Posted on April 05, 2005 at 07:00

I2C EEPROM

whhofmeyr · ‎2005-04-04

Posted on April 05, 2005 at 06:02

This subject has come up before but the ''solutions'' did not work for

me - do people just give up or why are working solutions never

posted?

While trying to write to the 24C08 serial EEPROM on the STR7

Evaluation board V 2.04, I tried the following resources:

- AN 1782

- Code posted by RISC in a thread ''Header byte and address

transmission b/n M24C08 and STR710F''

My first impression was that neither of these pieces of code

succeded in writing to the EEPROM. I thought that I could set

STOP after sending all the bytes using I2C_BufferSend, and that

a STOP would be generated (as is done in AN1782).

The problem seems to be that the I2C ''STOP'' signal is not

correctly generated.

If I set the STOP bit before writing the last byte then a valid

STOP is generated and the data gets written to the EEPROM.

On page 222 of Rev 5 of the Reference Manual (Jan 2005) the

Master Receiver text says that to generate a STOP one must

set the STOP bit *before* reading the last byte, while the

Master Transmitter text says:

''To close the communication: after writing the last byte to the

I2Cn_DR register, set the STOP bit to generate the Stop condition.''

The description of the STOP bit (p227) says that a STOP is sent

''after the current byte transfer or after the current Start

condition is sent''.

Ideally then, the STOP bit should be set after writing the byte to

the I2Cn_DR register before waiting for the completion of

transmission.

The read code also seems wrong: Ref Man says -

Note: In order to generate the non-acknowledge pulse after the last

received data byte, the ACK bit must be cleared just before reading

the *second last* data byte.

Why did the previous solutions apparantly work for some others

but not for me?

Is my interpretation of the Ref Manual correct?

All comments will be greatly appreciated.

whh

PS

I now see that RISC's code uses I2C_ByteSend (which does not

wait for completion of data transmission before returning to the

user) instead of I2C_BufferSend which waits for BTF before

returning - meaning that STOP is set before the byte is transmitted

and so a STOP will be generated..

His code will write to the EEPROM (although it makes

no provision or protection agains wrapping of the address in

the page write routine).

[ This message was edited by: whh1 on 05-04-2005 10:21 ]

sjo · ‎2005-04-04

Posted on April 05, 2005 at 06:48

I had problems with the app note especially as it does not handle the busy bit correctly, Find attached the modified str7 lib code which should work ok.

do {

I2C_STARTGenerate( I2Cx, ENABLE );

while( I2C_FlagStatus( I2Cx, DIRECT, I2C_SB) == RESET );

I2C_AddressSend( I2Cx, 0xA0, I2C_Mode7, I2C_TX );

do {

I2CStatus = I2C_GetStatus( I2Cx );

} while(!( I2CStatus & I2C_EVF ));

while( I2C_FlagStatus( I2Cx, DIRECT, I2C_ENDAD ) == RESET );

I2C_FlagClear( I2Cx, I2C_ENDAD );

} while ( I2CStatus & I2C_AF );

The problem is down to the new ENDAD bit which was not present on the st7 i2c cell. The problem with clearing this flag to early causes us to miss the AF flag.

In the end though I wrote my own routines as the libs are a bit bulky.

Have st got any other thoughts ?

Regards

sjo

[ This message was edited by: sjo on 05-04-2005 10:19 ]

whhofmeyr · ‎2005-04-04

Posted on April 05, 2005 at 07:00

When revisiting the library code I saw that I2C_BufferSend

and I2C_ByteSend wait for completion differently.

This means that RISC's code will work - I had just looked

to see how he had done it and not actually used his code.

I did not look closely enough and have maligned him with my

first post. I have edited the original post which may confuse

those who have already read it.

Thanks for your version sjo.

whh