Bruno,

Thanks for your quick response.

I am using the Raisonance REva board with the STM8S105 daughterboard.

I have the zipped the two projects I2CEEprom.zip, the project with the polled method and I2CExample.zip, the project with the interrupt method and emailed them to you.

Do you suspect this is an issue with the MCU ?

Are there jumper on the Reva board that have to be set?

Hi Rgodbole,

I received you example and reproduced the problem. The data written to the I2C chip is not correct, as an extra 0x00 byte is inserted in first position.

Explanation: The problem comes from the fact that the I2C EEPROM which is on the REva is a 24C02 (which holds 256 bytes), although the code you are using is written for the STM8-EVAL which has a 24C64 (64K).

The I2C protocol is very low-level, and is used only for sending and receiving bytes. The "upperlevel protocol" used by the 24C02 and 24C64 are different: The first one uses a 1-byte address (which is enough to index its 256 bytes) although the second one requires 2 address bytes.
Your code sends 2 address bytes to the I2C EEPROM, so the protocol is not respected.

Hence this is not a bug, you just have to respect the proper protocol.

Resolution: You can use the "testall" example from the Ride7\Examples\STM8\REva\STM8S105\Testall directory, which contains the code that will correctly read/write to the 24C02.

Also ensure that the SCL and SDA jumpers are set on your REva.

Best Regards,

Bruno,

Should this effect the Start condition? I would think the Start condition would be sent regardless of whether the upperlevel protocol is correct? I was not receiving the Start condition sent event.

Since you have verified that the testall example I will switch to that example.

Thanks in advance.

Bruno,

I have moved the eeprom files, eeprom.c and eeprom.h, from the testall example to the EEprom sample with the same results. I am unable to build the testall sample because it exceeds the size limitation.

The Start condition is still not generated. Reading the documentation the MCU should enter Master mode when a request to generate a Start condition is requested. If I examine I2C_CR2 the START bit is Enabled. However, if I examine I2C_SR3 the MSL bit is set to Slave Mode and I2C_SR1 the SB bit is disabled. Shouldn't both these bits be set when there is a request to sent the Start condition? If before calling I2C_GenerateStart(ENABLE) I set the START, SB and MSL bits the code seems to send the Start condition and receives the I2C_EVENT_MASTER_START_SENT event.

I am initializing the EEProm as given in eeprom.c, EEPROM_Init in the testall sample. The SCL and SDA jumpers are set.

Were you able to step through the testall application eeprom read and write routines?

There is an I2C header on the Reva board with SCL, SDA and GND pins. I'm assuming these can be used to monitor the I2C bus. I have connected an EasyI2C analyzer and am not seeing any activity even when the Start condition is successfully generated by setting the appropriate bits.

Thanks in advance.

Hi,

Several things here:
- You should be able to build the testall example. If you do not succeed, you may have to (freely) register your RKit-STM8 in order to have a 32K code maximum limit, which should be enough. You can register from http://www.mcu-raisonance.com/stm8_registration.html
- The testall example work fine in our Labs. Can you confirm that if you execute the example using "RE" and "WE" (read/write EEPROM) commands the results are OK?
- The debugger is intrusive i.e., it "reads" the memory locations that are displayed in your debug/memory/watch/peripherals windows. This has the nasty side-effect of clearing some status registers (which are sometimes clear on read). So what you must do in order to correctly analyze the problem is to disable debug and check whether this fixes your issue.

Let us know if this fixes your problems,

Bruno,

Sorry for the long, long, long delay in posting. We finally got the I2C working. We have a dsp on the same I2C bus as the MCU and the problem was that we did not have strong enough pullups on the I2C to counteract the dsp. Once we increased the pullups we were able to communicate to the dsp as well an eeprom.

One other question not related to the I2C, I was not able to register from the link you provided in your last post. When I attempt to transfer my registration information the browser spins indefinitely and never connects or transfers the information. This has happened every time I have attempted to register.

Thanks again for your help.