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.

DRV8303 - seemingly random activation of Fault Pin

Other Parts Discussed in Thread: TLV2774, CSD18532Q5B, INA213, TLV2771, DRV8303, DRV8301

Hello,

for my thesis i'm working on a BLDC driver for sine-commutation that can drive up to 1kW in a tight package using the DRV8303 in a 12-15V net (Automotive). The whole board is about the size of a Creditcard (Mikrocontroller is extra). The first iterarion (not packed very tight) worked quite good, but now i downsized the whole thing. It  is now a high-build board, i added 3 highside-shunts R001 with INA213 amps at 2.5V reference(TLV2771) with 4th deg. FIlters (TLV2774)  and changed the FETs to CSD18532Q5B. 

Now, the issue is: when i start the commutation, the fault pin is triggerd in a seemingly random pattern. It is not latched, 'OCTW is not triggered and in the SPI-registers I can't find any faultreports. Unfortunately this happens also, if the DutyCycle is down to 0 and no matter if any Motor is connected or not.

edit: Almost forgot to mention: DVDD looks just fine.

First thing I checked was the connections and solderjoints, but they were fine. I tried different PWM-Frequenzes but it only got worse at multiples of 4880Hz.  C_CP is about 15mm away from the DRV and on the opposite layer, Could it be that there is an inductance caused by the vias that causes the troubles? I'm running out of Ideas.

Please let me know, if you have any Idea how to fix this. I'd be happy send you my layoutfiles if thats of any help.

Best Regards,

Tobias Müllensiefen

  • Hi Tobias,

    Sounds like you have a working system to compare against; is that correct? If that is true, you might start by looking at the components that have changed, such as the FETs. This is one suspect area since you mentioned that the problem happens with or without the motor. A duty cycle of 0 should not create the problem though.

    Can you run without the motor looking for differences? Is the rise fall time of the FETs the same? Does adjusting the gate driver peak current  remove the problem?

    Any screenshots that you can share may help point to the problem also.

  • Hi Duncan,

    thank you for your support. Yes, i do have an older version using the 8301 with a deavtivated OC-detection

    I tried to raise the peakcurrent and to disable OC-detection on this newer board (see picture below) but unfortunately i don't know if the DRV accepted the SPI commands, since it is not responding to any read command. Is it possible that i destroyed the chip when i solderd it to the board? I did it manually and maybe too much heat got into it. On the other hand: The second board (same) shows the exact same behaviour.

    The first picture i added, is from my documentation. The board had to be really flat, so i decided to use those Keramiks. In _F_ the Microcontroller-board is connected (similar to arduino).

    The following two picures are triggerd on CH2 wich is the FAULT pin-signal. Both with F_PWM=20kHz with DutyCycle=0. CH1 in the first of those pictures is the sourcevoltage of a LowsideFET. CH1 in the last picture is the open Motorconnector. The Pattern you can see there on CH2 is repeating itself (5V Peak followed by 4 smaller ones)

    Best Regards

    Tobias

  • Hi Tobias,

    Yes, it is possible that the device has been damaged. But since the other device shows the same behavior, let's assume it is still good.

    The second scope shot is puzzling. Are all inputs INx_y static when this is occuring? If so, there is something causing the output of the phase to turn on. Can you determine what is causing it? When this happens please look at the gate of the lowside FET for coupling. If the gate of the low side increases when the output is rising, this could cause shoot through in the FETs.

     

     

  • Hi Rick, 

    i managed to limit the peakcurrent to 0.25A and since then the fault is only pulled for low dutycycles (SPI works now, i forgot to toggle SCS after a command)

    This is the the sine, with a dutycycle of "0" (actual it is a 50%DC symetrical on all 3 phases. For bigger dutycycles it alternates to this 50%value shifted by 120deg_el on each phase) .(CH1 LS, CH2 HS). 

    When i enable the gates it shows the following (CH1 Fault-Pin, CH2 HSgate)

    same, but zoomed in

    ...and the same, with LSgate on CH2.

    Do you think it is a problem, that all HS resp. LS inputs are simultaneous? Is the 8303 capable to drive more than one highsideFET at a time?

    I tried bigger bootsraps (220n) but with no change. CP is 220n as well.

    Best regards,

    Tobias

  • Hi Tobias,

    Now that the SPI works, does the status register identify which fault occurred? From the zoomed in scope shot of the HS gate, it appears like the voltage may reach 30V then returns to about 12V before drooping back to zero. Is that correct?

    Is the GH_x output  approximately 10.5V above the SH_x pin when enabled? If not, please look at the BST_x pin to determine why.

    Additional information about the current limit mode that may be of use can be found at: http://www.ti.com/lit/pdf/slva552

    This app note is in the DRV8301 product folder, but applies to the DRv8303 also.

  • Hi Rick,

    the voltage on the gates reaches about 28V for a short time, then 12V and then 0V. On the Motorconnectors it is the same butthe peaks reach are about 20V.

    Here you can see the gatevoltages (CH1 and 2 on same baselevel). If LOW the difference is about 11V, but if its HIGH its only 10.1V 

    I tried reading the faults but did not get constant results. In without changing anythig i sometimes got no faults at all (all low), somtimes an OC evvent on one or two FETs, and sometimes the MISO was high for the whole time. 

    If I turn off OC-Detection it works for a short as long no load is connected. When i try to drive a motor, the enable pin seems to be pulled low internal. All spicommands are lost and it starts to trigger "random" faults.

    Best regards

    Tobias