TCA9406: Not switching on the A-side
Part Number: TCA9406
We are using TCA9406 to convert our I2C lines from 3.3v to 1.8v. Below is the schematic:
We have additional 10k pull ups on VCCB side on SCL and SDA. Here is the problem we are facing:
1) When we connect R217 with 10k and remove R529, R527, this is equivalent to connecting OE to VCCA. In this case the signals are always high, the master is unable to pull down the lines.
2) When we connect R529, R527 and disconnect R217 we are controlling OE pin with CATALYST_I2C_LS_EN signal which is driven from a 3.3v IO. In this configuration we are enabling OE 31ms after enabling VCCA and VCCB. In this case the same scenario as in case 1 is occuring. If we increase the delay before enabling the OE to 180 ms the circuit is working as expected. From the data sheet waiting for 200ns after enabling OE is enough for O.S to become stable.
This issue is only happening when we connect the slave on VCCA side. When slave is not connected there is no issue.
We have also observed that on a different board where SCL_A and SDA_A are externally pulled up by 4.7k resistor and OE tied to VCCA it is working without any issue. But the problematic board is not working with external pull ups also.
Why is giving this additional delay on enabling OE required?
We have some boards where OE is directly tied to VCCA where we don't have an option of controlling the OE. The same problem is present on these boards also.
I'm not sure yet how to explain what you are seeing, since to my knowledge there should be no requirement for a delay prior to OE signal assertion with this part. Can you please start by confirming that it is the TCA9406 device that is holding the I2C lines high? You might be able to do this by replacing those 0-Ohm series resistors with a non-zero value (few tens of Ohms). That way you could at least see the other master/slave devices trying to sink current through their pull-down drivers by looking at the voltage drops across these resistances. Any oscilloscope captured you could provide showing the issue versus normal expected operation would be helpful on our end as well.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Max Robertson:
I just wanted to check back in on this. Were you able to learn any more about the issue that you were seeing? Or, have you had a chance to review my previous comments?
Unfortunately, we did not get a chance to work on this last week, I will get back to you once I try the experiment which you have suggested.
In reply to Teja Allani:
After some more experiments we have found out, by isolating the slave from the level shifter, that this issue is not with the level shifter. This was due to the slave device connected to level shifter.
Thank you very much for the follow-up. I'm glad to hear you found the root cause! If you have any questions on this device in the future please don't hesitate to post a new thread.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.