Interface and Connectivity ICs
MEMS and Sensors
Analog and Audio
EMI Filtering and Signal Conditioning
Power Management and Motor Control
SPC5 Automotive MCUs
ST25 NFC/RFID Tags and Readers
Switches and Multiplexers
STM32 MCUs Community
MEMS and Sensors Community
Automotive MCUs Community
STM8 MCUs Community
Help the community
Share your activities
Contribute your knowledge
About this community
to create and rate content, and to follow, bookmark, and share content with other members.
Question asked by
on Apr 5, 2005
on Apr 5, 2005 by 15542
Show 0 Likes
No one else has this question
Mark as assumed answered
This content has been marked as final.
Show 3 comments
(Required, will not be published)
Apr 5, 2005 6:02 AM
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
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
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
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.
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 ]
Show 0 Likes
Apr 5, 2005 6:48 AM
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.
I2C_STARTGenerate( I2Cx, ENABLE );
while( I2C_FlagStatus( I2Cx, DIRECT, I2C_SB) == RESET );
I2C_AddressSend( I2Cx, 0xA0, I2C_Mode7, I2C_TX );
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 ?
[ This message was edited by: sjo on 05-04-2005 10:19 ]
Show 0 Likes
Apr 5, 2005 7:00 AM
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.
Show 0 Likes
Retrieving data ...
2018 STM32 Wish List
STM32-C2C (Cellular to Cloud) Web Concierge Portal
STM32F769I-DISCO: No audio output from wm8994
STM32CubeMX V4.24.0 code generation failure (bug report)
CubeMX SDIO DMA FatFS configuration