Skip to main content
Visitor II
April 5, 2005
Question

I2C EEPROM

  • April 5, 2005
  • 3 replies
  • 902 views
Posted on April 05, 2005 at 07:00

I2C EEPROM

    This topic has been closed for replies.

    3 replies

    whhofmeyrAuthor
    Visitor II
    April 5, 2005
    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 ]

    Visitor II
    April 5, 2005
    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 ]

    whhofmeyrAuthor
    Visitor II
    April 5, 2005
    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