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.

Using DRV8305, nFault pin pulls low without fault present on SPI

Other Parts Discussed in Thread: DRV8305

Hi there,

As mentioned in title, nFault pin of DRV83053 pulls low in random occasions, without any report of fault on SPI. The chip can still drive a load properly.

When nFault is released, it functions properly after a few power cycles, and reports faults correctly due to low voltage and such. So the pin seems functional. It appears like it latches down occasionally without an apparent issue.

  • This is the first time we see this happening.
  • I confirmed that it is in fact DRV8305 holding the pin low. There is a 100 ohm resistor between this pin and micro controller. In normal conditions, the voltage levels on the pin (high or low) are normal. But when it latches low, I have tried to short the micro side of the 100 Ohm resistor to 3.3V supply, and the DRV8305 side of 100 Ohm remains close to 1V, indicating the chip is pulling it down.
  • On the micro controller side, we have a 4.7k pull up resistor. We have the same circuit on the power good pin that works normally without any latching.

Thank you,

Mehdi

  • Hi Medhi,

    Do you have a second board to try?
    If this appears on multiple boards, would you please provide a scope capture of the nFAULT pin as the trigger? Please look at VM, VREG, VCP, and the other controlling signals. The typical delay from the error to nFAULT asserting is 7us, so the area of interest is 7 to 15us before nFAULT asserts.
  • Hi Rick,

    I only have one board with this happening on. According to datasheet, in any case nFault is asserted, the cause should be reported on SPI. Isn't that true?


    Do you know of a reason why nFault could be asserted with SPI reporting nothing?

    Thanks,

    Mehdi

  • Hi Medhi,

    Does this mean you have a board that nFAULT is not asserted? If you have one that works, you can perform an AB comparison of the key signal to determine why nFAULT is asserting.

    One possible reason for a lack of reporting in the SPI is a severe droop on VM or VREG, which could reset the device completely. This may be checked by reading a register that was set to a non-default value after nFAULT has asserted.

    By the way, which version of the DRV8305 are you using? (DRV8305N, DRV83053, or DRV83055)
  • Yes I can do a comparison between good and bad boards.

    When you say a drop in voltages can reset the device, shouldn't that also clear nFault too?

    We have a counter that would increment every time a register doesn't match the expected value. When nFault is asserted, the counter doesn't increment, showing that the register values are good. So I don't think it is resetting as registers remain unchanged.

    We are using DRV83053.

    Thanks,
    Mehdi
  • Hi Medhi,

    Thank you for doing an AB comparison. We will be interested to hear what you find.

    At this point, you are seeing unexplained behavior.

    Like you, I would think nFAULT should also be cleared when the voltage increases. But we don't want to rule anything out as it may provide a clue.
  • Hi Rick,

    I compared the voltage rise on different lines between two units and I don't see any differences. Basically PVDD and other voltages rise between 2mS to 5mS smoothly.

    In our circuit, we supply the power to the circuit from a switch. same line switching EN_GATE also enables the power switch. So when I disable EN_GATE, the chip supply also starts dropping. EN_GATE signal is faster than the supply rising.

    To test, I disable EN_GATE and the supply also drops. When supply reaches around or below 9V, I enable EN_GATE which also enables the power, and rises to 12V. In such case all VREG, AVDD and DVDD voltages are good without any droop. Still I see nFault latches low in random occasions. in the circuit EN_GATE is set high around 1mS before PVDD is enabled and rises to 12V. But as I measured, nFault is asserted 0.5mS after the EN_GATE is asserted, and 0.5mS before PVDD starts to rise.


    In general I can't find any correlation between nFault assertion and how other voltages change. Just that it seems to be happening if supply is around or below 9V.

    This doesn't happen on other boards I believe.

    Thanks,

    Mehdi

  • Rick,

    What is the next step to root cause the problem? Based on my measurements I can see a reason why nFault should latch down without any error present on the SPI. nFault is an open collector output and the reason it is latched seems to be internal to the chip. Can I get in contact with TI engineers to have them analyze the issue and get help finding the root cause?

    Thanks,
    Mehdi
  • Hi Mehdi,

    Sorry for the delay.

    Can you provide scope captures of the event (PVDD, EN_GATE, nFAULT, and any other signals that you think are important)?

    Can you provide a schematic of your board?
  • Hi Rick,

    I just found some new clues that might help. nFault is not actually latching down. We have a 100nF noise filtering capacitor on it that filters the signal. I removed the capacitor and observed that nFault is actually toggling at 56uS intervals, indicating it is reporting a warning.

    It is still an unknown behavior to me. According to datasheet if there is a condition for warning, nfault will report it by toggling the signal. Then as soon as the register is read through SPI, nFault stops toggling. It will restart toggling if the condition clears and returns again.

    We are reading all registers through SPI every 10mS. SPI is not reporting any faults or warnings. Reading the registers is not clearing the nFault toggling. From my nFault scoping, I can't see any interrupt in nFault toggling and it keeps continuously coming.

    In steady state, all voltages around the chip (PVDD, EN_Gate, etc...) are pretty DC. So I can't tell what the chip is complaining about, especially since SPI doesn't return anything either.

    Again the report is happening randomly at power up and keeps going. So now I'll do some more probing to see if how the start of nFault toggling matches other events on different lines. But in general when the warning doesn't persist, I see nfault toggle for around 100mS and then clears. In faulty cases, it keeps running forever.

    Please let me know if you can understand why nFault doesn't clear upon register reading, and why SPI doesn't report anything.

    If you like more detailed information we should do it over email.

    Thank you,
    Mehdi
  • Rick,

    Some more bit of information. To verify that the chip and software function correctly in a non-faulty state, I turn the board on and see that nfault is not toggling. Then I reduce the voltage below 8V. When that happens, I see nFault toggles for less than 10mS and stops, and our software reports the low voltage.

    So nFault toggles till the software reads SPI as noted in datasheet and clears, while SPI continues to report the warning. All functionality seems working in a non-faulty condition.

    In the faulty condition nFault keeps toggling without interrupt, SPI doesn't report any faults and voltages are at steady state.

    Thanks,
    Mehdi
  • Hi Mehdi,

    Thanks for the additional information. When nFAULT is toggling, this is an indication of a VDS event. Can you look at the VDRAIN/SH_x and SH_x/SL_x to determine if this is the cause of the toggling.

    We will still have to investigate the reason for the SPI registers not recording this.

    By the way, what are you register settings?
  • Hi Rick,

    I made sure the PWM lines are set to zero. I measured all VGS of 6 MOSFETs, as well as PWM input lines to the chip to make sure there are no glitches when the event happens and there are non.

    I can easily turn the issue on/off by just simply dropping PVDD voltage to around 8V and switching it on again. To drop PVDD, I turn off the power MOSFET on the positive line and PVDD drops slowly while bulk capacitors are discharging. Then I turn the power FET on. When I do this, PWM lines are all set to zero. nFault still toggles in random occasions, or clears.


    If VDS was the problem, then having 0 PWM should make sure the chip is not checking them. Is that right?

    And I made the unfortunate mistake of shorting something on the chip and it seems VDRAIN circuit was damaged as chip is cracked now. So I can't do anymore on this chip. But I can replace the chip and see if the problem persists. That way I can rule out the contribution of the surrounding circuit on the nFault issue.

    My register settings for VDS is 16, or 0.403V VDS and it is set to latch in case of VDS>threshold. Is there another setting you are interested in?

    Thanks,

    Mehdi

  • Rick, Below is scope probe of the signals:

    Yellow (CH1) = GATE_EN

    Light Blue (CH2) = nFault

    Pink (CH3) = VREG

    Dark Blue (CH4) = PVDD

    In the following image, you see a non-faulty case of the same chip. When PVDD is rising, nFault complains about low voltage until there is a SPI read and it clears.

    In the following picture, we see similar condition but nFault doesn't clear and keeps going:

    Also you mentioned nFault warning should be due to VDS, but I see nFault toggling when there is low voltage fault as well which agrees with Datasheet. In any case, when nFault persists in toggling, all conditions are resolved (low PVDD) and PWM inputs are set low.

    Thanks,

  • Hi Medhi,

    Thanks for the scope captures. EN_GATE active prior to PVDD is not a normal power up sequence. We will have to determine if this could be the reason for nFAULT toggling.

    There are a couple of questions from this:
    Is it possible to move the EN_GATE signal a few ms after VREG is up?
    Can you look at the VCP_LSD and VCPH for unusual behavior during this time?

    I will try to duplicate your procedure in our lab, but it may take a few days.
  • Hi Rick,


    That would be great if you can replicate that. Unfortunately as the design is right now I can't delay EN_GATE. But if that's necessary I will change the PCB in the next revision. This is eh only board I have noticed this happening on so far.


    Previously I though of the same thing and forced the power to be enable and toggle EN_GATE, but nFault didn't clear. So that might not be the cause of the issue.


    Let me know if you find out anything new on PVDD and EN_GATE timing.

    Thanks

    MEHDI

  • Hi Rick,

    Would you please give me a time line on when you can do the test in your lab?

    Thank you,

    Mehdi

  • Hi Mehdi,

    I should have the data by end of day Friday.
  • Hi Mehdi,

    I believe I am seeing similar behavior in our lab, but I have not been able to confirm the registers. The nFAULT pin is toggling once PVDD was lowered to approximately 8V and raising the voltage did not correct this. The nFAULT has a capacitor on it; you can see the RC time constant.

    I have contacted the design team for guidance. I did note that issuing a 600us EN_GATE pulse corrected this toggling. I will update you once I hear back from the design team.

    Please let me know if you think this is similar.

  • Hi Rick,

    It is good that you can repeat the problem. So that I'm clear, you have the supply and EN_GATE enabled, then you lower the PVDD below 8V so nFault toggles, then raising it above 8V sometimes doesn't correct this, is that right? Or do you do something to EN_GATE too?

    Thanks,

    Mehdi

  • Hi Mehdi,

    Correct. PVDD supply is 12V with EN_GATE enabled. PVDD is lowered in 1V increments to 8V, and nFAULT begins toggling. Raising PVDD slowly (it was raised to 20V) does not correct it, but issuing an EN_GATE pulse of ~600us does.
  • Hi Rick,

    I was able to recreate what you saw on another board. Because we read SPI every 10 mS nFault clears but returns even above 8V. This is when chip seems to be in an unknown state.

    But in other times, when I go under 8V nFault toggles only for less than 10mS before we read it and clears, until the next time I go below 8V. This is normal expected operation.

    In the specific worse chip, nFault never clears and continuously goes.

    Thanks,
    Mehdi
  • Hi Medhi,

    We are still investigating this. It will probably take a few more days. Sorry for the delay.