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.

TPS23861: Interrupt functionality stopped working after a while

Part Number: TPS23861

Hi Team,

I have a question about the TPS23861 PoE controller used in our ethernet switch.

When TPS being used in semi-auto mode while PoE port functionality being deactivated via switch firmware (means PWON1-4 bits in register 19h won’t get set)  -  we plug in a class 4 PoE device.
Then the TPS Interrupt pin is pulled low through Classification Event. Our system reads out a few registers to find out which class the PoE device has and clears the Interrupt via CoR on Detect/Class Enable register 14h. Then again the TPS is pulling the Interrupt low after new classification and system clears it again. This process repeats to a certain point where the TPS is not sending an Interrupt anymore (Interrupt pin stays high). Replugging the device does not change that. Sometimes it only takes one minute to reach this effect and sometimes it takes up to 20 minutes.

 I wanted to ask if there’s any kind of counter/timer realized in the TPS functionality that keeps it from continuing the mentioned process forever?

Best regards

Simon

  • Hi Simon,

    Can you explain a little bit more about the test situation by answering the following questions?

    1. Can you dump all register settings when you didn't see the interrupt?
    2. When you can't have interrupt pin asserted low, what's all ports' status? Can you measure all ports' voltage?

    Best regards,

    Penny

    1. You can always read out / write the registers
    2. Ports stay deactivated because of switch firmware, no port voltage measurable, as intended

    My question is why the TPS does not repeat the classification -> send interrupt process forever. Is there any timeout-like function realized in the TPS that stops him from sending interrupts at some point?

    Procedure:

    1. Our TPS is in semi-auto mode, classifies and therefore sends interrupt
    2. We read out Interrupt Register (00h) => Response: Detection and Classification at least at one port (18h)
    3. Clear on Read Detection Event Register (05h) =>  Response: Classification and Detection at port X
      (with this command the interrupt pin is going back to high state)
    4. Read Port X Status register (0Ch <-> 0Fh, depending on port) => Response: Class 4 and Resistance valid (44h)
    5. System checks if PoE functionality is enabled:
    1. Enabled: Set corresponding Port Power Enable bit in register 19h
    2. Disabled: Do not set bit in Power Enable register

     

    This procedure repeats a few minutes as mentioned in the first mail. Important is here that we DO NOT power on the corresponding port (5b.). Therefore the TPS restarts his classification process because his Interrupt register was cleared by 3) but this process does not go on forever. It stops and interrupt stays high forever. Sometimes after just a few minutes and sometimes after more than 20 minutes. Do you have an idea why?

    Best regards

    Simon

  • Hi Simon,

    I have not seen this before. The reason why I ask you to dump all register data is that I want to check the each port's status(operating mode, detection/classification enabled, any faults). Technically, if the ports are in semi auto mode, detection classification is enabled and detection and classification event are unmasked, you should continuously see the interrupt coming out. With that said, can you read all register's status (when you see this problem) and send the data to me for further analysis?

    Best regards,
    Penny
  • Simon, It has been over a week since we last heard from you. Are you able to get the information requested from the customer?

    Thanks for your local support,