3 Replies Latest reply on Oct 23, 2019 11:39 PM by RashiV_61

    CX3 I2C master generates misleading pulse before stop condition

    MaOs_1615421

      Hi

       

      I'm currently encountering a problem with the CX3 I2C master before the stop condition. It seems that after the last ACK the master waits too long to pull down the SDA line, allowing a pulse on the SDA line right after the slave releases it. I believe that causes some troubles in my slave's state machine as it assumes that another byte is going to be transferred. Indeed, the I2C communication is always stuck after the first write transfer. Is there a way to change the master's behaviour?

       

      I'm using following code for testing:

       

      uint8_t buf[2] = {0x01, 0x70};

      preamble.buffer[0] = SENSOR_I2C_WRITE_ADDRESS; /* Slave address: write operation */

      preamble.length = 1;

      preamble.ctrlMask = 0x0000;

      status = CyU3PI2cTransmitBytes (&preamble, &buf, 2,0);

        • 1. Re: CX3 I2C master generates misleading pulse before stop condition
          RashiV_61

          Hello Marc,

           

          Can you program CX3 with any one of UsbI2CSpiMode/UsbI2CDMAMode examples of SDK to check the I2C connection.

          You need to send vendor commands from the control center to read/write data (Please refer to readme.txt file in the example folder)

          While doing that can you probe the I2C lines.

           

          Please share the waveform traces.

           

          Regards,

          Rashi

          • 2. Re: CX3 I2C master generates misleading pulse before stop condition
            MaOs_1615421

            Hi Rashi

             

            I looked a bit more into our slave and I realized that the problem is on our side. Our slave requires an additional SCL clock cycle after the stop condition to get into the idle state. However, the CX3 master immediately stops the SCL clock after the stop condition and restarts only after the start condition. This is why, our slave lacks behind one clock cycle and hence doesn't acknowledge the next write transfer. I understand that this is an issue on our side but since it is a little tricky to change the behaviour of our slave I was wondering whether we could configure the master somehow that it keeps the SCL clock running for at least another cycle after the stop condition?

             

            Thanks

            • 3. Re: CX3 I2C master generates misleading pulse before stop condition
              RashiV_61

              Hello Marc,

               

              Thank you for the update about the problem on slave side.

              Making the changes on the master side to get one more clock after the stop bit doesn't seem  feasible. I will still check it internally.

              Please let me know why the device is behaving in such manner? Or why do you need one clock cycle more? so that we can find some other solution to it.

               

              Regards,

              Rashi