• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 19 subscribers
  • Views 1855 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.

TXS0102 Critical Failure

Chad Graham38
Prodigy 20 points
Other Parts Discussed in Thread: TXS0102

Problem:

When we first hook-up a multi-board system using a TXS0102 to level shift an I2C bus between the boards, a critical failure will occur causing the TXS0102 to blow-up, but only on 1 system in 25.

Background:

We are utilizing a TXS0102 as a +3.3VDC to +5.0VDC translator for multi-board I2C communications bus.  There are 3 devices on the +3.3VDC side (VCCA) including the master micro-controller and 1 device on the +5.0VDC side (VCCB).  

The VCCA side is power from the same rail as the micro-controller and has a 4.75k pull-up on each data line; the +3.3VDC rail will always be powered up completely before the VCCB rail is enabled.  The regulator powering the TXS0102  VCCB rail is located on the same board as all of the VCCA components.  The OE pin is shorted to ground causing the device to be always on.

The VCCB device is a slave micro-controller that is located on the second board.  It is powered by it's own +5.0VDC power rail and each data line has a 4.75k pull-up.  The power going to this slave board is controlled by the master micro-controller and comes on at roughly the same time as the +5.0VDC regulator powering the VCCB rail.  The connection between the boards is a redundant connection scheme meaning that each signal has two parallel wires.

Failure Description:

The actual failure occurs on the initial power-up of a slave board in a dedicated test jig.  Excluding the I2C communications bus, each slave board is functionally tested at the assembly house and then verified by manufacturing prior to inserting it into the test jig.  (The test jig is a full-system platform with dedicated hardware used only for confirming the slave board's I2C bus.)  When power is first applied to the jig, the master micro-controller performs a self-check and then enables the peripheral rails; this is when the actual damage to the TXS0102 chip occurs.  Replacing the TXS0102 chip will repair the jig and allow it to test the next board, but I do not have data on f the same slave board will blow the TXS0102 a second time.  The boards are all quarantined and given to engineering for analysis.  Initial checks of the board showed nothing amiss with the I2C signals, but 1 did have to have the slave micro-controller replaced which fixed it.

Question:

What types of problems would blow up the chip on such an infrequent basis?

  • 0
    TI__Mastermind 23166 points

    Hello Chad,

    Can you please send a schematic for me to review?  I am a bit confused about some of the things you said on your post.  You said OE was grounded?  Is that correct?  I will look at you schematic first then maybe we can discuss what might be happening in your environment that might cause this failure. 

    -Francis Houde

  • 0 in reply to fhoude
    Prodigy 20 points

    Here are some snapshots of the schematic.  From the I2C master perspective, a command is generated by the Master PIC, passes through the TXS0102, moves from the Master board to the Slave board via the 2 redundant cables and then accepted by the Slave PIC.  There are 2 additional slave devices on the VCCA side of the TXS0102 and there are pull-ups on both sides of the TXS0102.

    Clear as mud right? 

    VCCA Master Micro-Controller

    VCCA External Pull-Ups

    VCCA Slave Devices

    TXS0102 Level Shifter

    VCCB Board-to-Cable Connectors (Mirrored on Both Boards)

    VCCB Slave Micro-Controller

    VCCB External Pull-Ups