• State Answer Suggested
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 386 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCA9517: VCCA not connected to the A-side supply

Yandrie Oyarzabal
Prodigy 10 points
Part Number: TCA9517
Other Parts Discussed in Thread: MSP430F5510

Hello TI:

My company acquired a product that uses I2C communication protocol through cable. The connection between the main board and multiple tier boards is a typical star application. There is an I2C repeater (TCA9517DGKRQ1) between the main board and the tier boards. The I2C Master MCU is in the main board and the I2C Slave MCU plus the I2C repeater (TCA9517DGKRQ1) are in the tier boards.

I noticed 2 design flaws in the diagram above:

  1. The VCCA is not connected to the A-side supply voltage, VCCA and VCCB are connected to the B-side supply voltage instead. The TCA9517DGKRQ1 chip should work as a voltage-level translator, but the VCCA supply is not connected to the chip.
  2. There is only one decoupling capacitor placed close to the VCCA side.

Can you help to understand how this incorrect configuration in the I2C bus repeater will affect the I2C communication?

The system has multiple I2C errors. To take care of some of the I2C errors, the firmware implements retries to resend the I2C packets after I2C errors. There are also I2C bus lockups when the SDA line is being held low by the I2C Slave. These type of I2C errors are catastrophic and the system cannot recover without a power cycle.

I noticed that unusual fast transitions in the I2C signal become the trigger for the I2C errors because impacts on the ability of the I2C decoders to understand the data on the line. I noticed that unusual fast transitions in the I2C signal become the trigger for 2C errors because affect the I2C decoder’s ability to decode the data on the line correctly. I’m using an I2C Bus analyzer and an oscilloscope with I2C protocol built-in plugged to the A-side to analyze and log the I2C frames.

Instead of getting a solid HIGH in SDA, there are fast transitions from HIGH to LOW and go back to HIGH. The I2C decoder in the oscilloscope stop decoding after 3 data bytes in this particular case. Check a zoom view in the picture below to get more details into the unusual fast transitions of the SDA line.

The only issues that I could find in the schematic is the ones that I pointed out (VCCA not connected to the A-side supply and not decoupling capacitor at B-side); can you please provide an insight of how could possibly affect the I2C signal this incorrect connection to the I2C bus repeater?

I also calculated the pullups min and max values, and they are in range, but I just wondering if the pullups are not strong enough. Any recommendation?

Is there any other issue in the diagram that standout?

Thank for your help,

EE Yandrie Oyarzabal

  • 0
    Guru 316760 points

    1. The difference of 0.3 V is not large enough to matter. As shown in the oscilloscope traces, all devices properly detect the high signal level.

    2, The B sides are not as critical (short traces, weaker pull-up resistors). The nearest decoupling capacitor being some distance away from the VCCB pin is harmless. I see no problem that could be caused by that.

    3. There is some crosstalk between SCL and SDA on the cable. But it is not large enough to matter.

    4. The spikes on SDA are harmless because they happen only while SCL is low. They cannot be caused by the circuit or the I²C buffer; they happen because the I²C slave actively drives the line low for a short time. (While harmless, this is a stupid thing to do.)

    5. The only actual problem visible in these traces is at the place where the analyzer stops decoding. The I²C slave should let SDA go high when the clock is low, but it delays so long that the rising edge comes after SCL goes high again. This is an I²C stop condition, which makes the analyzer stop. (A stop condition is not valid at this place, so the I²C master ignores it.)

    The only problem is the I²C slave. And that random delay makes me guess that the slave implements I²C entirely in software, and that that software was not properly designed to meet the required real-time constraints. (The lockups further confirm that the slave is buggy.)

  • 0 in reply to Clemens Ladisch
    Prodigy 10 points

    Hello Clemens:

    I really appreciate you taking the time to look into my issue.

    It’s good to have confirmation regarding of the I2C repeater VCCA not connected to the A-side and the decoupling capacitor not near to the B-side are not problems.

    Regarding of the crosstalk, I agree with you. The undershoot cause by the falling edge transition in the SCL line is not large enough to cause any problem.

    You are right when pointed out that the fast transitions in SDA line do not occur during the SCL rising edge, because of that reason it should be harmless. To give you a better context what it’s odd is that the I2C fast transitions only occur when the I2C data send by the slave is incorrect. The data sent out in the I2C frame I shared was 0x9E, 0x7A, 0x7F, but the correct data expected is 0x82, 0x0A, 0x03… a respond to a ping command. This I2C slave behavior leads to your conclusion that I’m working with a buggy I2C slave.

    For your reference, the I2C slave is the MSP430F5510 from TI. The I2C is implemented using the I2C module, the developers did not bit bang the I2C protocol. Do you have experience using the I2C module in the MSP430F5510? Can you share insights that might confirm the conclusion that the I2C slave device is buggy?

    It’s important to me to get more confirmation of this issue (I2C slave buggy), so I can convince my managers that we should be focusing on recovering from the I2C bus lockup instead of spending more time trying to fix the potential issues that cause the lockup.  

  • 0 in reply to Yandrie Oyarzabal
    Guru 316760 points

    I have never used the F5510, but as far as I am aware, the MSP does not generates such spikes. (The spikes could be explained by very strong crosstalk, but they happen only when the slave is transmitting.) And the MSP certainly does not output entirely wrong values, so there definitely is a software issue.

    There are several USCI errata, but none of them have symptoms that look like this. And that delayed rising edge makes me doubt that the slave is actually using hardware I²C. (Well, it could be explained by some other part of the software/hardware pulling the line low.)

  • 0 in reply to Clemens Ladisch
    Prodigy 10 points

    The I2C slave is implemented using the USCI module in the MSP430F5510. We reviewed functional problems and implemented workarounds in the USCI errata. For example, we dropped the clock frequency from 100kHz to 40kHz to ensure SCL clock frequency is < 50kHz in I2C standard mode if using repeated start to comply with the errata. I also cannot see anything in the errata that could possibly cause the fast transitions in the SDA line.  

    In order to be on the same page, I’d like to ask you what you mean when you say hardware I2C? For me, because the I2C was implemented using the USCI module is completely done in software.

    Even if it points to a firmware error in our code based on the fact that the I2C slave respond with incorrect data before I started recording I2C errors and eventually going into a bus lockup, the problem only happens in one I2C slave in the lab unit we use for testing.

    To give you a better context, the system has a main board with an I2C master that communicates using a typical star configuration with 10 I2C slaves. I can only record I2C errors in one specific I2C slave. It cannot be a coincidence, that’s why I’m leaning towards a hardware issue that we are overlooking.  

    Thanks again and I’ll keep you posted with my findings.

  • 0 in reply to Yandrie Oyarzabal
    Guru 316760 points

    Yes, USCI is hardware.

    I have no explanation for why the USCI module would delay a rising edge, or why it would lock up.

    If different units behave differently, then I would assume that the flash contents are corrupted, or that the chip is damaged.