• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 293 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.

BQ79616-Q1: VPATH test fails

Gianni Perugini
Prodigy 130 points
Part Number: BQ79616-Q1
Other Parts Discussed in Thread: BQ79616

Dear all,

We have a problem with BQ79616 diagnostic features. When we run OVUV Bist, we get a VPATH_FAIL set in FAULT_PROT2 registers.

To run the test, we follow the indications of the datasheets. We are using the first 13 cells of 16 managed.

Could you explain what does VPATH_FAIL means?

Could you help us to understand which is the root cause?

 

Waiting for your kind reply

Thanks

BR

Gianni

  • 0
    TI__Expert 3760 points

    Hi,

    Generally, the VPATH_FAIL means something triggered OVUV during the BIST (built-in self test). I have a couple of questions to figure out what could be causing this:

    1. Are any other faults set? Check the other bits in the FAULT_PROT2 register and the fault summary register

    2. What are the steps you are performing when running the BIST? Are you setting the PROT_BIST_NO_RST bit?

    3. Are you able to clear the faults? That is, if you re-run the BIST what happens? Are you consistently having this bit set?

    Thanks,

    Nancy

  • 0 in reply to Nancy Hidalgo
    Prodigy 130 points

    Hi Nancy,

    many thanks for you reply.

    1. No the only fault we have is related to VPATH_FAIL in FAULT_PROT2. To prevent other faults from invalidating the BIST, we are also masking every non OVUV related faults.

    2 We follow these steps:

    • mask every non OVUV related faults
    • reset every fault 
    • starting the BIST

    We also tried to run the test with the PROT_BIST_NO_RST set to 1 but the only thing we saw is that other than VPATH_FAIL we have OVUV fails bits set as expected.

    3 Yes, even if we clear the faults and re-run the BIST, we get again the same results.

    We attach a debug print screenshoot of the test run with PROT_BIST_NO_RST = 1. The chain we have is composed by one bridge device BQ79600 (address 0) a BQ79631 (address 1) and 8 BQ79616 (13 celles configuration, with address from 2 to 9)

    [2024-02-22 10:35:07.883] dev_address: 0x1 FAULT_PROT2 value: 0x13
    [2024-02-22 10:35:07.883] dev_address: 0x1 FAULT_OV value: 0xFFFF
    [2024-02-22 10:35:07.883] dev_address: 0x1 FAULT_UV value: 0xFFFF
    [2024-02-22 10:35:07.883] dev_address: 0x2 FAULT_PROT2 value: 0x13
    [2024-02-22 10:35:07.883] dev_address: 0x2 FAULT_OV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x2 FAULT_UV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x3 FAULT_PROT2 value: 0x13
    [2024-02-22 10:35:07.883] dev_address: 0x3 FAULT_OV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x3 FAULT_UV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x4 FAULT_PROT2 value: 0x13
    [2024-02-22 10:35:07.883] dev_address: 0x4 FAULT_OV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x4 FAULT_UV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x5 FAULT_PROT2 value: 0x13
    [2024-02-22 10:35:07.883] dev_address: 0x5 FAULT_OV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x5 FAULT_UV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x6 FAULT_PROT2 value: 0x13
    [2024-02-22 10:35:07.883] dev_address: 0x6 FAULT_OV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x6 FAULT_UV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x7 FAULT_PROT2 value: 0x13
    [2024-02-22 10:35:07.883] dev_address: 0x7 FAULT_OV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x7 FAULT_UV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x8 FAULT_PROT2 value: 0x13
    [2024-02-22 10:35:07.883] dev_address: 0x8 FAULT_OV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x8 FAULT_UV value: 0x1FFF
    [2024-02-22 10:35:07.883] dev_address: 0x9 FAULT_PROT2 value: 0x13
    [2024-02-22 10:35:07.884] dev_address: 0x9 FAULT_OV value: 0x1FFF
    [2024-02-22 10:35:07.884] dev_address: 0x9 FAULT_UV value: 0x1FFF
    [2024-02-22 10:35:07.884] BQ OVUV BIST KO

    Waiting for your kind reply

    Thanks

    BR

    Gianni

  • 0
    TI__Expert 3760 points

    Hi,

    Thanks for the additional information. Can you check two other things:

    1. Can you rerun without the PROT_BIST_NO_RST bit set and without masking the faults?

    2. Are you able to probe the nFault pin? If so, can you clear all the faults then run the BIST and observe the behavior of the pin?

    3. How are the unused cells connected?

    Best,

    Nancy

  • 0 in reply to Nancy Hidalgo
    Prodigy 130 points

    Hi Nancy,

    many thanks for your reply.

    1. Rerunning without the PROT_BIST_NO_RST bit set and without masking the faults (0x0000 on FAULT_MSK1 and FAULT_MSK2 and 0x0000 on FAULT_RST1 and FAULT_RST2) the result is as follow:

    dev_address: 0x1 FAULT_PROT2 value: 0x40
    dev_address: 0x2 FAULT_PROT2 value: 0x40
    dev_address: 0x3 FAULT_PROT2 value: 0x40
    dev_address: 0x4 FAULT_PROT2 value: 0x40
    dev_address: 0x5 FAULT_PROT2 value: 0x40
    dev_address: 0x6 FAULT_PROT2 value: 0x40
    dev_address: 0x7 FAULT_PROT2 value: 0x40
    dev_address: 0x8 FAULT_PROT2 value: 0x40
    dev_address: 0x9 FAULT_PROT2 value: 0x40

    that is BIST ABORT.

    2. Yes, I'm able to probe the BQ79631 NFAULT pin. Before to write 0x0000 (no mask) on FAULT_MSK1 and FAULT_MSK2, the NFAULT pin is high. After writing, the NFAULT pin goes LOW and remain in that state until I write the 0x8777 on FAULT_MSK1 and FAULT_MSK2.

    Restoring the default mask used for OVUV BIST test 0xE7FF on FAULT_MSK1 and FAULT_MSK2 and 0xFFFF on FAULT_RST1 and FAULT_RST2, the NFAULT moved as the picture below:

    Is it normal?

    Unfortunately we don't use NFAULT pin on BQ79616 so it's not connected on that boards. Anyway we are monitoring the NFAULT of BQ79600 bridge of the whole chain. 

    3. The unused cells V14, V15 and V16 are connected to VBAT as V13.

    Waiting for your kind reply

    Thanks

    BR

    Gianni

  • 0
    TI__Expert 3760 points

    Hi,

    Thanks for trying that. The NFAULT bit pulls low when there is a fault detected, so that is expected. The unused cells are connected correctly, thanks for checking. 

    Can you try the BIST with the  PROT_BIST_NO_RST bit set, without the masking, and power cycle before running the BIST? 

    Best,

    Nancy

  • 0 in reply to Nancy Hidalgo
    Prodigy 130 points

    Hi Nancy,

    Nancy Hidalgo said:
    Can you try the BIST with the  PROT_BIST_NO_RST bit set, without the masking, and power cycle before running the BIST

    what do you mean with power cycle before running the BIST?

    Waiting for your kind reply

    Thanks

    BR

    Gianni

  • 0
    TI__Expert 3760 points

    Hi,

    By this I mean can you disconnect the power supply to the device or otherwise power down the device before trying again. Please let me know if there are additional questions. 

    Best,

    Nancy

  • 0 in reply to Nancy Hidalgo
    Prodigy 130 points

    Hi,

    in our configuration / management we are not able to power down the device and then repeat the test. 

    Could you explain us what does the Vpath fail means?

    We have this fault set on every device, so it seems that it could be caused by a wrong management or a wrong electric circuit used with the device. What can we look for on the setup or on the electric scheme? 

    Could it be due to the fact that we use an external cell balancing circuit instead of the internal?

    Waiting for your kind reply

    Thanks

    BR

    Gianni

  • 0
    TI__Expert 3760 points

    Hi,

    I got some feedback from the team. The VPATH_FAIL  indicates that there is some issue with the BIST. The BIST will try to force OVUV bits and toggle the nFault pin. If the nFault is disabled or the OVUV bits get stuck during testing then the VPATH_FAIL bits will get set. The most likely way to reset the stuck bits would be to power cycle. Because the nFault pin is not connected here, this may be what is causing the issue. Is it possible to externally pull-up the nFault pin to the same voltage as CVDD (5V) and retry? 

    Best,

    Nancy

  • 0 in reply to Nancy Hidalgo
    Prodigy 130 points

    Hi, 

    as you suggested we connect the Nfault pin to pull-up but we obtain the same result.

    Anyway as described in the data sheet that pin has been leaved unconnected because it is not used:

    After reworking the board with the pull-up resistor, we tried again to run the BIST monitoring the nFault pin. The result is the following:

    Why the first transition takes soo long with respect to the others?

    As you can see, the signal performes 13 transitions, we assume that there is one for every cell configured, after that the signal remains high as expected but the FAUL_PROT2 register show VPATH_FAIL error bit set. 

    The board is the last in the chain and it has every fault masked, with exception to OVUV and PROT.

    Waiting for your kind reply

    Thanks

    BR

    Gianni 

  • 0
    TI__Expert 3760 points

    Hi,

    Yes, you are right that is the recommendation. Can you send a HWRST tone in an attempt to reset these faults?

    Best,

    Nancy

  • 0 in reply to Nancy Hidalgo
    Prodigy 130 points

    Hi,

    the problem is not how to reset the fault but to understand the root cause.

    Could someone help us to understand how to avoid this issue, please? What do we need to investigate on our board to avoid the VPATH_FAIL during the BIST?

    Waiting for your kind reply

    Thanks

    BR

    Gianni 

  • 0 in reply to Gianni Perugini
    Prodigy 130 points

    Hi,

    finally we were able to fix the issue, programming the OV_THRESH and UV_THRESH registers before to execute the BIST check.

    Could you explain why, please?

    Waiting for your kind reply.

    Thanks

    BR

    Gianni 

  • 0
    TI__Expert 3760 points

    Hi,

    The BIST will compare the OVUV thresholds to the ADC input values. The point is to run the cell measurements through the OVUV comparators. So if the ADC inputs are within 100mV of the thresholds, then  it's possible that an OVUV fault will trigger which will also trigger VPATH_FAIL. 

    Best,

    Nancy

  • 0 in reply to Nancy Hidalgo
    Prodigy 130 points

    Hi,

    but if we don't program the threshold before to start the BIST, the OV_THRESH and UV_THRESH registers have already a default values 0x3F and 0x00. If I'm not mistaken, at the reset time the UV_THRESH should be 1200mV (0x00) and OV_THRESH should be 2700mV (0x3F), so I'm wondering why the VPATH_FAIL it's triggered.

    Waiting for your kind reply.

    Thanks

    BR

    Gianni 

  • 0
    TI__Expert 3760 points

    Hi,

    That's correct. To clarify, are you manually setting the thresholds to be the same as the default? Or what are you setting the thresholds to in the case where there is no issue? My theory is that the default thresholds are not reasonable thresholds so the OVUV faults are triggering, leading to a VPATH_FAIL. 

    Best,

    Nancy

  • 0 in reply to Nancy Hidalgo
    Prodigy 130 points

    Hi,

    Nancy Hidalgo said:
    To clarify, are you manually setting the thresholds to be the same as the default?

    No I'm not.

    Nancy Hidalgo said:
    Or what are you setting the thresholds to in the case where there is no issue?

    OV_THRESH set to 4200mV

    UV_THRESH set to 2000mV

    Waiting for your kind reply.

    Thanks

    BR

    Gianni

  • +1
    TI__Expert 3760 points

    Hi,

    The BIST is not intended to be used when there is an actual fault, like in the case you've described. The BIST checks that the fault detection path is functioning. It assumes that there is no fault, which is why it is recommended in the datasheet that the cell voltages are not close to the thresholds, otherwise the result is invalid. In this case, the faults are legitimate, so the BIST result is invalid. When you set the thresholds appropriately, there were no legitimate faults so the BIST result was valid and had no issues. Because the faults were not pre-existing, the BIST_ABORT bit was not set. So the device was functioning as expected. Please let me know if there are additional questions. I've included the datasheet snippet below. 

    Thank you for your patience,

    Nancy