TPS23861: Multiple Device failures

Part Number: TPS23861
Other Parts Discussed in Thread: TPS40210, LM5575

Tool/software:

We have used the TPS23861 PSE in a number of different product designs, selling a few thousand each year. We have had a number of failures where all 4 ports stop providing POE.

  • There is no detection or classification phase.
  • The I2C interface is still active although it only appears to be basic digital IO registers that can be read correctly. Vin (0x2E,0x2F) and temperature (0x2C) registers are examples of those that don't provide valid data.
  • Voltage is provided from a 12V input, boosted to 50V by a TPS40210, and with the 3.3V supply derived from the 50V with an LM5575. The 3.3V has a UVLO set at about 30V.
  • Each port has a protection TVS fitted between Vpwr and Drain similar to the EVM board.

We haven't had any failures where it's only a few ports faulty, always all 4 ports that fail.

The failing units have mainly been supplied from a solar/battery power source and our testing has revolved around repetitive charge/discharge cycles providing significant power cycles of the PSE but this hasn't shown any problems.

Any suggestions as to the failure mode.

  • Hi Mike, 

    Thank you for reaching out. I have a few follow-up questions: 

    1. What is the port voltage during failure? Want to know if the port is completely off or in an idle state. 

    2. Can you provide current waveforms of at least one port at the time of power on?

    3. Have you verified that the PD side of your system has no failure?

    Additionally, I can also review the schematic of your board as well.

    Thanks,

    Anagha

  • We have no idea as these are all failures on customer sites. All failures at different sites but with similar configurations. Our product is configured as an 8-port unit using 2 stacked boards of the same design each with a TPS23861 on it. For the customer who has had most issues, they are using 2 ports on each device and these will be in an always on situation. As mentioned we think most of these are solar/battery powered so there could be some power cycling when the battery is depleted, although our own tests haven't indicated this as a problem.

    As these are all separate failures, then the PDs are all ok, and this has been verified by replacing our product. We have also replaced the PSE device on multiple boards and this has also repaired the system.

    I don't have any faulty units here currently to get waveforms however as we are getting frequent returns due to those issue then I don't think it'll be long before I can provide those.

    I've attached PDFs of the main board as well as the ADB board (which provides the 50V from a 12V input)

    CS-PLUS2-MAIN-2-2 - Project.pdfCS-PLUS2-ADB-PCB-1-1 - Project.pdf

  • Hi Mike,

    Thank you for the background. As you said, power cycling upon battery depletion should not be an issue. 

    What operating mode do customers typically use the device in? 

    For the customer using only 2 ports, are they able to read all registers via I2C correctly since the ports are always on? If I2C reads work, would it be possible for them to provide a register dump? Specifically, registers 0x12, 0x14, 0x41, and 0x43. 

    I will review the schematics and get back to you as soon as possible. 

    Best,

    Anagha

  • Hi Mike,

    Just wanted to follow up with some notes on the schematic. The port FET being used in the design has a Vgs(th) minimum of 1.6V. TI typically recommends using a FET with a threshold voltage minimum of at least 2V. This can prevent leakage and reduce gate oscillation. Previous customers have experienced issues in their design while using a FET with a lower threshold voltage. Everything else on the schematic looks good. 

    Best,

    Anagha

  • For this particular product customers don't have any access to the I2C to be able to perform any diagnosis, it is effectively an unmanaged switch design. When we next receive a failed unit I will check those registers, based on previous experience we should be able to read those ok, the registers we've don't get valid data from are those associated with the analogue section of the device.

  • Hi Mike,

    Sounds good, I'll check back in once you have those register readings and/or waveforms for any failed units. Please let me know if there are any other concerns that come up in the meantime. 

    Thanks,

    Anagha

  • Hi,

    I've got a unit here that seems to have the same issue. In order to access the I2C I have to erase the microcontroller that normally configures the device so having to  then manually setup registers.

    Set 0x12 = 0xff

    Set 0x14 = 0xff - on a working board this is enough to enable the PoE output.

    Read 0x41 = 0x00 (Note that on other boards I'm sure this value was 0x02)

    Read 0x43 = 0xE2.

    Most other registers are only giving a value of 0x00 other than

    0x41  = 0x17

    0x00 = 0x80

    0x01 = 0x80

    0x0A = 0x30

    0x0B = 0x30

    0x11 = 0x20

    0x12 = 0xff

    0x14 = 0xff

    0x17 = 0x80

    This is with a 55V supply and a PD attached to one of the ports - all ports behave the same.

  • Hi Mike, 

    Thank you for getting back to me. 

    You are right about 0x41, expected values for this register are either 0x01 or 0x02. Just to clarify - are you also reading 0x17 for 0x41? What firmware is being loaded on to the PSE chip? Is this firmware owned by TI?

    Not sure if 0xE2 is what is expected for register 0x43 either. Let me see if I can recreate this issue on our end. I will get back to you about this Friday 10/17. 

    Best,

    Anagha

  • Hi,

    Repeated the register reads on those registers (same board)

    0x41 = 0x00

    0x42 = 0x17

    0x43 = 0xE2.

    Note that I've not got a history for this particular board it was just an RMA that we had that seemed to show the same issues but could already have been through some previous debug/repair stage, and I also don't know if this is from the customer/installation that we've had most issue with.

    With regard to firmware, we don't load any firmware (not even sure that's possible for this device), we use the devices as they are shipped.

  • Hi Mike, 

    At the moment, I am unable to recreate this issue on our end. Would you be able to provide the port voltage of this board at power on? Additionally, can you also provide waveforms of the VDD, VPWR, and /RESET pins of the chip at power on? I would like to check the timing sequence of these three pins. 

    What mode is the device operating in?

    Best,

    Anagha