3 Replies Latest reply on Aug 21, 2019 3:27 AM by SananyaM_56

    CYUSB3304 - I2C Communication failure


      We're having problems with a device which uses CYUSB3304 configured in I2C slave mode as a USB hub. When we send a call to the 7-bit address 0x60, the I2C rail will enter a blocked state, never producing the stop condition or releasing SDA or SCL until power is cycled.


      I2C Failure when reading from the 7-bit address 0x60:

      I2C Read.png

      During normal operation we will see the following behavior form the device when it finds a valid address (0x40 and 0x41)
      I2C Read from 0x40 Success.png

      Schematic section with the CYUSB3304: Note R14 and R22 have been verified as non-stuffed:


      Reference Datasheet:


        • 1. Re: CYUSB3304 - I2C Communication failure



          -For the I2C slave boot mode, the hub expects a write command with valid firmware or configuration and it will wait for enumeration until that is received. Please check the KBA for the complete method and let us know if you are able to perform it successfully- EZ-USB® HX3 I2C Slave Mode Operation – KBA90943

          -Could you please explain the normal operation behavior? Which is the device you are referring to and is it a read or write to the hub?


          Best Regards,


          • 2. Re: CYUSB3304 - I2C Communication failure

            Thanks Sananya for the response, that seems to have gotten me a bit farther and have tried out several different variations on the configuration files generated by the tool but it doesn't seem like this is successful.


            "-Could you please explain the normal operation behavior? Which is the device you are referring to and is it a read or write to the hub?"

            I'm sorry, I might be misunderstanding this question. The CYUSB3304 is part of a development tool where it serves as a USB hub which can be controlled by another MCU that communicates with the host. We intend to enable and disable the hub using 100KHz I2C during test conditions to disconnect the peripherals. We've been using it in 'Internal ROM configuration' via the mode select before where the USB pass though has been successful.


            I2C writes seem to work, a logic analyzer doesn't show problems with the communication on that direction and I've verified the message format matches the KBA90943 article l but it's still non-functional when operating in I2C slave mode with the following symptoms:


            * The USB on host has only shown up when the mode select is in the 'Internal ROM configuration'.


            * I can send the "bD4Length = 6" style message to the device and it will prevent the I2C from being bricked when I send a I2C read, but I won't get any data from it. Since the USB doesn't show up and I can't do a read, I have not been able to verify if any of these commands are actually working.


            * I've tried other messages, including those which leave the parameters as their default according to the datasheet and I have not been able to get I2C to work nicely, reads for all others than "bD4Length = 6" style cause the rail to be held low.


            * I've tried the various different permutations of the I2C configurations on the HX3 Blaster Plus tool and master MCU's I2C configuration while validating it.

            • 3. Re: CYUSB3304 - I2C Communication failure



              From your explanation, I think you are trying to change the hub configuration on the fly after it boots up. The I2C interface on the hub is used only to update firmware to an I2C EEPROM and boot from an I2C master or slave. Thus, in I2C slave mode, it will expect the write command to send firmware in either D4 or B0 format and enumerate as soon as it receives the complete data. After that, the I2C interface is not designed to receive any read or write commands.


              For the hub not showing up on the host in I2C slave boot mode, kindly attach a screenshot of the communication captured using the logic analyzer. You could also generate the firmware file to be sent using Blaster Plus tool itself and try sending that after the internal address as mentioned in the KBA. I have attached the Blaster Plus tool guide for you reference, please check section 3.3.4.


              Best Regards,