3 Replies Latest reply on Jul 8, 2012 4:40 AM by JoMe_264151

    Clock stretching on a CY8C9540A

       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?

        • 1. Re: Clock stretching on a CY8C9540A

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

          • 2. Re: Clock stretching on a CY8C9540A

            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.

            • 3. Re: Clock stretching on a CY8C9540A

              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...