• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 195 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

LP8764-Q1: Reporting UV and OCP fault

LP8764-Q1: Reporting UV and OCP fault_2

Alex Lee
Prodigy 60 points
Part Number: LP8764-Q1

Hi TI team,

I am facing UV problem for LP8764-Q1 on system reliability qualification. The fault report as following:

 

mfg-s32g> i2ctransfer -f -y 1 w1@0x20 0x5a r1

0x91

 

mfg-s32g> i2ctransfer -f -y 1 w1@0x20 0x5b r1

0x02

 

mfg-s32g> i2ctransfer -f -y 1 w1@0x20 0x5d r1

0x02

 

mfg-s32g> i2ctransfer -f -y 1 w1@0x20 0x66 r1

0x01

 

mfg-s32g> i2ctransfer -f -y 1 w1@0x20 0x69 r1

0x02

 ------------------------------------------------------------------------------------------

The log indicates the fault is caused by Buck3 interrupt with UV event.

mfg-s32g> i2ctransfer -f -y 1 w1@0x20 0x5d r1

0x02

 

Currently, I suspect this should be an OCP event causing Vout drop. Some of question should be clarified below.

1. How is the reading for the Vsense internally, is it from FB pin?

2. How is the definition of UV trigger level? Is this Vout*90%?

3. OCP fault will be reported if the load current above the limit level for 30us, right? If we do not see this fault, the Vdrop might result from high transient load or other scenario?

  • 0
    TI__Expert 6410 points

    Hi Alex,

    1. Yes, this is read from FB pin.
    2. UV level is configurable. Below 1.0V it is voltage value and above 1.0V percentage from set voltage level.
    3. Yes, Actually getting OCP fault is tough per my experience. You will always first hit OV or UV limits since voltage deglitch time is shorter and reaction done based on this first before hitting current limit. 
  • 0 in reply to Jari Niemela13
    Prodigy 60 points

    Hi Jari,

    Thanks for your reply.

    Currently, we change current limit level of buck 3 from 4A to 5.5A  to meet system loading shown as figure. Besides, the setting of VCCA/Vmon timing  is 4us.

    Since we are facing UV issue we try to check the boundary of current limit and UV protection.  

    The fast transient kit are applied in my experiment, CH1 is the voltage of 1V05, CH4 is the current with 20mV/A conversion.

    I have some questions below,

    1.  By generating the current pulses with 10us width, we can see the current limit event but why the system did not do shutdown?

    2.  Regarding the timing requirement of the current limit, the deglitch_oc should last from 19-23us to trigger the fault. Why we can see the current limit has been triggered? And what is the meaning of OC detection delay for 7us from datasheet?

    3. We are setting UV with 10%(Typ) level. Ideally, the UV level for 1V05 is around 0.94V.(1.05V*(1-0.105)=0.93975V). Please correct me if I am wrong.

    4. According UV 0.94V level, we had the cursor with 4us width under 0.94V. We generated 150mV (7.5A) with 14us width current, and the fault event only showed UV_INT. Is it the priory high for the UV detection, so the register did not record UV and current limit fault both?

  • 0 in reply to Alex Lee
    TI__Expert 6410 points

    Hi Alex,

    1. This reaction is now dependent on how NVM is defined, what actions it ill take because of this. Usually we don't want action only when current limit is hit. Reaction is wanted when voltage falls under UV limit. Please refer figure 
    2. Delay of 7µs is from first switching peak hitting current limit. When peak current is hit all the time 7µs it is reported out and next digital delay of maximum 23µs is taking place so that OC signal is reported maximum of 30µs to PFSM and interrupts. 
    3. UV limit is 0.9x1.05V = 945mV.
    4. This question i'm going to verify from designer.

    Br, Jari

  • 0 in reply to Jari Niemela13
    TI__Expert 6410 points

    Hi Alex,

    For the question 4. Are you sure BUCK3_ILIM_INT is not masked with bit BUCK3_ILIM_MASK setting "1"? Both UV and ILIM should appear in your measurement. 

    Br, Jari

  • 0 in reply to Jari Niemela13
    Prodigy 60 points

    Yes, the BUCK3_ILIM_INT is not masked.

    I share the folder as link below, which includes schematic and FW file.

    drive.google.com/.../1b0dgB_NQs-LMDf8nJ3uQn1VEONvHdISY

  • 0 in reply to Alex Lee
    TI__Expert 6410 points

    Hi Alex,

    Our organization blocks google folders access. Could you email me directly j-niemela@ti.com. 

    Br, Jari

  • 0 in reply to Jari Niemela13
    Prodigy 60 points

    Hi Jari,

    Just checking, I have sent an e-mail to you.

    Do you recieve the config file?

    Alex

  • 0 in reply to Alex Lee
    TI__Expert 6410 points

    Hi Alex,

    Thanks for waiting.

    What comes to this question 4. I would like to know did you changed something for testing since the shared NVM should cause SAFE_RECOVERY transition because UV is hit and SOC group is triggering ORDERLY_SHUTDOWN?

    But still UV and ILIM can appear at the same time. These interrupts have same priority. 

    4. According UV 0.94V level, we had the cursor with 4us width under 0.94V. We generated 150mV (7.5A) with 14us width current, and the fault event only showed UV_INT. Is it the priory high for the UV detection, so the register did not record UV and current limit fault both?

    Also I wasn't sure what project this is but opening schematics understood this already somewhat familiar case overall. 

    From schematics only concern is that BUCK1,2,3 inductors is not in line with selected BUCK use case. 

    Br, Jari