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.

TPS92661-Q1: TPS92661-Q1 fault detection

Part Number: TPS92661-Q1

Dear Support team

Seeing datasheet,when TPS92661 is set the output duty to 100%,
It is need writting 0 to the ENOFF register.
But LED short circuit and overvoltage detection and  Fault bit is not asserted when duty 100%.
Is it correct operation?
If it is correct operation,Is there a way to inform the MCU of fault at 100% duty? 

Regards

Tomohiro Nagasawa

  • Hello Tomohiro,

    I'm looking into getting the right person to give you the best response. I will let you know (or they will respond) as soon as possible.

    Regards,

    Clint

  • Tomohiro-san,

    You are correct that clearing the ENOFF bit is the correct way to get to 100% LED duty cycle.

    While the LED fault reporting does not occur in this case, the switch and string are still protected (i.e., any LED open case will still trigger the FET to close and keep current flowing).

    What is the use case they are trying to detect? What is the maximum amount of time a pixel can be at 100% duty cycle vs. what is their desired fault reporting delay?

    Best Regards,
    Mike
  • Hello Mike-san

    Thank you for  kindly support.

    In customer application ,100% duty  cycle time is 3.3msec.

    Desired fault reporting delay is within 10msec.

    Is there any way to inform the MCU of fault at 100% duty?

    (For example, setting the 100% duty in LED_ON_OFF register)

    Your prompt reply would be  appreciated.

    Regards

    Tomohiro Nagasawa

  • Tomohiro-san,

    There is no way to force an evaluation of the fault at 100% duty cycle.  The LED has to be transitioning from on to off in order to evaluate a fault.  This has to do with how the part samples the fault latch from the switch.

    However, if the 100% duty cycle setting is only ever 3.3mS max and the fault reporting delay is 10mS (I assume this means the MCU reads the fault registers every 10mS?), then as long as their PWM frequency is >= 150Hz, they will catch the fault on every 10mS sample point.  Note that I am assuming their firmware does the array update and fault read synchronously in their scheduler.  The basic idea is that you want to ensure you can always get through one full PWM period when you are NOT at 100% duty cycle to ensure that the part will latch the fault into the FAULT register.

    Another option is to never go to the 100% duty cycle setting.  There is no perceivable difference in light output of the 1023/1024 PWM setting vs. the 100% duty cycle case.  This is a very simple solution and eliminates having to deal with the ENOFF bit altogether.

    One final note.  The firmware should never make a decision based on 1 single fault.  It is better to accumulate faults over some amount of time and run them through some type of FIR filter to differentiate between a transient event and a truly bad/failed LED pixel.  This will make the system's pixel fault handling more robust and the MCU doesn't have to deal with short-term problems in the pixels because the TPS92661 does that automatically (i.e., automatically protecting against open to maintain string current).

    I hope this helps.

    Best Regards,

    Mike

  • Hello Mike-san

    Sorry for late response and thank you for advice.

    Customer revised software to 1023/1024 setting and I have one question.

    (1)Why  this device can not detect fault at 100% ON state?

    (My understanding is that it is impossible to measure the voltage of the LED at 100% duty, Is it correct?)

    (2) Is this a specification as expected or errata of device?

    Regareds

    Tomohiro Nagasawa

  • Hello Tomohiro-san,

    I would like to get you in touch with the TI product line directly. Could you please let me know your contact information?

    If you would not like to post it here, and that is understandable, you can send me a friend request so that we can exchange info privately.

    Thanks,

    Clint

  • Hello Clint-san

    Thank you for response.
    Please send e-mail.

    tomohiro_nagasawa@nexty-ele.com

    Regards
    Tomohiro Nagasawa