I have a string of 10 CY8C9540A on a single I2C bus, driven by a single AVR processor. For reasons that are not clear to me, the CY8C9540A is stretching the clock from 0.4 ms to 3 ms on each and every byte, including the address. I've tried all the drive modes, unloading the outputs, etc, and I can't seem to make the clock stretch go away. I can't find any mention of this in the datasheet or the app notes I have found. 

The timing is critical for this project, so this is clearly unacceptable. Can anyone give me any pointers on getting this clock stretch to go away?

 All the pins I am using are configured as plain digital outputs, if that matters.

Is this applicable to your situation, from datasheet, master stretching

clock for block writes ?

To write data to the EEPROM, the master device performs one
write cycle, with the first two bytes being AHI followed by ALO.
This is followed by one or more data bytes. In the case of block
writing it is advisable to set the starting address on the beginning
of the 64-byte boundary, for example 01C0h or 0080h, but this is
not mandatory. When a 64-byte boundary is crossed in the
EEPROM, the I2 C clock is stretched while the device performs
an EEPROM write sequence. If the end of available EEPROM space

is reached, then further writes are responded to with a NAK.

Regards, Dana.

I am a bit curious about your mesured clock of 0.3ms. So what transfer rate is set for your master? And are you able to verify that clock? Streching the clock for a write-access of an EEPRom is quite understandable, but not if this occurs during the first bits of an address. It looks for me a bit like a clocking-mismatch where one of the devices waits for the oher...

Bob