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.
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.
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.
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.
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?
IMU_cmd_SCL_SDA.jpg 3.8 MB
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.