6 Replies Latest reply on Aug 6, 2020 5:31 AM by GaneshD_41

    I2C SCL, SDA startup power problem


      The I2C master mode is being used in a project to communicate with a FRAM chip and an IMU chip.  Communication has been going successfully but there seems to be a problem with the I2C and SDA pin pull-down power when a communication is first started.  Attached is a trace of the start of a 4 byte write to the FRAM.  The top trace is of the SCL pin and the bottom trace is of the SDA pin.  Note that on the first few pulses, neither the SCL or SDA pins are pulled close enough to ground for the FRAM to recognize them.


      The PSoC 6 I2C component is configured as a master at 400 kbps with TX and RX FIFO.  Both SCL and SDA pins are configured as bidirectional with Open drain, drives Low and the initial state is High.


      Note that on the first try neither the SCL or SDA lines are pulled down but not completely to ground.  Note also the exponential decay for both the pull-down and for the pull-up, particularly on the SCL trace.  The FRAM does not respond; so the transmission is aborted.  Then, about 30 microseconds later, the transmission is again started.  This time the pull-downs and pull-ups are normal and the transmission is completed successfully.  Afterwards a read of the FRAM locations was done to verify that the information was properly written.  This test was repeated every second and the same traces resulted.


      A second trace which zooms in on the first aborted transmission is also included. 


      What could be the problem and how could it be avoided? 

        • 1. Re: I2C SCL, SDA startup power problem

          Hi StNu_1610991,


          This could be due to improper selection of pull up resistors for the bus. What is the pull up resistor used? It has to be chosen based on the bus capacitance, VDD and data rate. Please check Pull-up resistor sizing section in the NXP I2C spec.






          • 2. Re: I2C SCL, SDA startup power problem

            The pull up resistors used are 3.3K ohm.  According to the spec you referenced they should be 1K to produce a minimum pull up current of 3 ma.  I will change them to see if the problem is resolved.


            By the way, the CY8CPROTO-063-BLE schematic shows that the I2C pull ups used there are 4.7 K.  Are they then also not out of spec?


            I found that if all the Cy_SCB_I2C_... functions are checked for errors and appropriate retries are put in, I2C communication works fine except for the added time when the first connection attempt is aborted.

            • 3. Re: I2C SCL, SDA startup power problem

              Hi StNu_1610991,


              There are restrictions on pull up resistors that can be used for I2C lines. Although it depends on the bus capacitance, there is a upper cap limit of Rmax. If you have high RC time constant, then it cannot meet the rise time – fall time requirements for I2C interface for the given speed.




              • 4. Re: I2C SCL, SDA startup power problem

                Hi Aashita:

                The rise and fall times of SCL and SDA is not the issue.  On the test board both signal traces are very short and therefore do not have much capacitance.  Also, the oscilloscope  traces show that the individual bit rise and fall times are very good.


                The problem is the first few bit transitions of the first byte being sent.  The rise and fall times are OK.  But, the amount that the signals are pulled down and up is the problem.  In the SCL, all clock cycles should be pulled down to 0 volts. But, the first is only pulled down to 2.5 volts, the next to about 1.3 and the next about 1.  This shows an exponential decay with a time constant of about 20 to 40 microseconds. Eventually the signals are pulled down properly to close to 0.  This looks like a gating issue in the PSoC 6 when the SCB first becomes active.  Whatever is causing the SCL to be pulled down is at first not strong enough to complete the pull down.


                It seems that this is something not under the user's control.  So, the workaround I mentioned in the previous response is what is needed.

                • 5. Re: I2C SCL, SDA startup power problem

                  Further trace details.

                  To further check the SCL and SDA signals at start-up, an I2C IMU (ICM-20948 from Sparkfun) was attached with short wires about 2 inches long.  The attached traces are the result of sending a single command to the IMU.  The first transmission again failed but the retry went through.  This trace shows more clearly the improper pull-down of the first few bits on both the SCL and SDA lines.  Because of the added  signal wires, the rise times  were not as good but still acceptable.


                  Is there maybe some configuration control that would prevent the pull-down problem?

                  • 6. Re: I2C SCL, SDA startup power problem



                    Ideally this is not expected. I do not have a scope with me to test this at mu side but anyways I can add my viewpoints to this.


                    1. You can download the code example from this link and test it on your side. The code example basically uses both I2C Master and Slave components inside PSoC 6 only. You just have to connect I2C Master and Slave pins externally. From this test you can get an idea whether the problem is towards I2C Master or I2C Slave. Please ensure I2C pins are properly connected with shortest possible wires.




                    2. If the test above is successfull and if you do not see any problems, there may be a problem with soldering of the devices on your board.

                    Please try de-sodering and soldering again the Master and Slave devices. Are you using your custom board or Cypress development kit? If you are using Cypress development kit you dont have to de-solder the PSoC.


                    3. Please check if the Master's ground and slave's ground are connected properly with a thick wire. Having more impedance on the ground path may also be an issue.


                    4. If the test in point 1 also shows similar kind of problem, please update us the same in this thread.