Spin Semiconductor

I've been using a microcontroller uC) to emulate an eeprom to feed program codes to FV1 via I2C. The FV1 runs on a clock signal (32Khz) generated by the uC. What baffled me is that, the only way I can get a successful I2C data transfer is if I bring the clock frequency down to around 10 KHz, if the clock is kept at 32KHz during the data transfer the I2C communication becomes 'stuck'.

I've measured that with FV1 a 32KHz clock will translate to I2C clock frequency to around 250KHz, and with 10 KHz clock the I2C clock is around 70 KHz.

I doubt that FV1 is incapable of high speed I2C data transfer cause I'm sure it's communicating with a real eeprom at 250 KHz, so it's likely something is wrong with my uC I2C implementation, however I've been looking at the implementation very closely and couldn't find what could be the problem. Maybe someone with similar experience or a deep knowledge of I2C system could give me some advice on this problem?

By the way, I've already verified that the uC is capable of I2C communication with 250KHz with other devices, so the I2C implementation is basically working, what I want to know is whether FV1 expects a certain condition or timing constraint to work at 250 KHz I2C clock.

I'd check your setup and hold times for the data lines compared to the clock signal. They should not be transitioning at the same time as the clock signal, or anywhere close. Also, take a look at the waveforms on the 24LC32 data sheet as the FV-1 data sheet doesn't have any details.

http://html.alldatasheet.com/html-pdf/1 ... 4LC32.html

Thanks for the suggestion Larry. Anyway after pouring over the uC datasheet again I found that the i2c module was actually stretching the clock when transfer speed is higher than 80 Kbps, and I remember reading on another thread that FV-1 does not support clock stretching, that explains why I need to slow down the FV-1 clock to make the communication work.

There's no way to disable that feature from happening? I have no idea what it is but it sounds like some sort of protocol compatibility issue that should be optional, unless it's due to a limitation in the micro itself and you can't get around it any other way.

The datasheet says nothing at all about the possibility to disable clock stretching, so I guess it's not a possibility (I'm using Atmel Atmega chips by the way). uC is running at 8 Mhz system clock and only a few lines of codes are executed whenever i2c interrupt occur, so I'm at lost as to why it need to stretch the clock, it has ample time to keep up with the i2c data transfer.