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.

DRV8343H-Q1EVM: driver damaged

Part Number: DRV8343H-Q1EVM
Other Parts Discussed in Thread: DRV8320

Hi, team,

we planned to use the DRV8343H-Q1 as a BLDC blower driver in our upcoming medical project. I got the DRV8343H-Q1EVM evaluation board to test a real performance. Although the blower provides the Hall sensors, I started testing with default sensorless firmware. Apart from blower phases, the only connected devices were laboratory power supply (set to 24V and 3A limit) and laptop with DRV8343Q1-1.0.0_EVM software.

The driver was successfully enabled in software tool and blower started to spin until timeout expired and fault was set (typically phase or stall fault as RPM was not detected because of improper parameters setting). The faults were normally cleared by pressing the corresponding button in the application GUI and start-up cycle was repeated.

Everything worked reasonably for dozens of cycles. Then the behavior had changed - I was not able to clear faults by repeated button activation, I realized the power supply entered the constant current mode and then I just saw smoke emitted by the driver chip (see attached picture).

Such a catastrophic failure of an automotive part on unmodified evaluation kit is rather surprising. I don't understand the reason - the voltage was well within recommended range and estimated dissipated power (related to gate switching) is not high enough to cause overheating.

Can you please help us to find a plausible explanation? It is critical for regaining confidence in this part. We really need a robust and reliable solution for our medical application.



  • Hello Vladamir,

    Thanks for posting to the MD forum! 

    What jumpers did you have set in hardware for VDS, MODE, and IDRIVE? Also, were the 30-A fuses installed when the device failed? 

  • Hello Aaron,

    thanks for prompt reply. 30A fuses were installed and the jumpers were set as follows:

    VSD: disabled (1st position)

    MODE: 6x PWM (6th position)

    IDRIVE: 60/120 mA (4th position)

    I know that configurations (both HW and SW) are not optimal so I would expect potential issues in MOSFET power stage (overcurrent, cross-conduction, for example) rather than damaging driver itself.



  • Hey Vladimir,

    Is is possible that any external forces can spin the motor in your test setup when the device is enabled? The main suspicion I have is that if a transient voltage of >40V is introduced on the SHx node (generator mode), there is a current path in the IC that can damage the internal ESD diode between the VM and VCP pins.

    I am working with a teammate to investigate any other potential root causes from the settings and setup you have. 


  • Hi Aaron,

    there was no permanent external force applied. Used blower (Micronel U71HX-024KX-6), however, had removed plastic casing so it is possible that I spun rotor momentarily by hand during testing. Nevertheless, the maximum BEMF peak-to-peak voltage in this case is as low as 3V. Moreover, it seems that VM is
    directly connected to both DRV and high-side MOSFET drain on evaluation module. In this case the high-side MOSFET body diode would prevent excessive voltage difference between SHx and VM (and also VCP - VM).

    Note that I didn't touch the hardware at the critical moment - I just used an application GUI.

    I attached more detailed pictures - perhaps it can help you to localize the cause (the hottest spot seems to be located near to the package edge).



  • Hey Vladimir,

    Just wanted to let you know that we're still looking into this and looking for root causes.

    Was the jumper set intentionally to disable VDS monitoring? If you had VDS monitoring set before to a VDS level, did you see any faults triggering before?

    If VDS was disabled, it's possible that there was a shoot-through condition from VM to GND through the power FETs. The large amount of current could have caused a large voltage spike to VM due to parasitic inductance from the board. 

  • Hi Aaron,

    thanks for info and hints.

    I intentionally disabled VDS monitoring at the beginning of evaluation as I supposed the current limit set for lab power supply (Agilent E3632A) is sufficient to protect power stage.

    Moreover, I suppose VDS monitoring serves only for FET overcurrent protection/indication, whereas the FET shoot-through protection is completely independent function (based on VGS monitoring).

    I agree that a shoot-through condition could cause significant voltage spikes. Are you sure, however, that disabling VDS monitoring can result in shoot-through?

    Best regards,


  • Hi Vladimir,

    Disabling VDS monitoring does not result in shoot-through; I was just mentioning that if a VDS shoot-through condition had occurred somehow, the lack of VDS monitoring would not pick up the overcurrent from VM to GND and damage the IC.

    May I ask what speed you were running the motor at, and whether you were disabling the motor at any point? When the motor is disabled, the motor begins to coast and I'm considering whether that could have resulted in a large amount of voltage being pulled from GND through the body diode of the FET. If SLx exceeded -3V peak or -1V continuous, it can damage the IC and cause an internal short from VM to GND.

    We would like to send you another sample of the board to evaluate with. Please accept my friendship request on E2E and I will be happy to get the information to send you another EVM. 

  • Hi Aaron,

    the target motor speed was set between 10000 - 30000 RPM. Note that the blower never started to operate normally - rotor was just shaking during start-up procedure which was automatically terminated with fault indicated. This behavior is likely caused by improper BEMF detection settings preventing sensorless operation. It means that the motor was driven only for a short period of time (well below 1 s) and I didn't disable it intentionally.

    Unfortunately, I don't know exact setting at the critical moment as my primary intention was to quickly familiarize myself with SW tool capabilities rather than systematic testing and tuning. So I agree it makes sense to try to reproduce a fault under well controlled conditions using another evaluation board.

    Best regards,


  • Hi Vladimir,

    So you are trying to spin the motor sensorlessly then? You are correct - it is difficult to spin the motor at high speeds using sensorless operation because the window to detect BEMF from the motor becomes too small. Can you use hall sensors to detect and spin the motor?

    We do have a reference design that allows for high-speed sensorless trapezoidal control of up to 33.6-V that that uses a DRV8320 here:

  • Hi Aaron,

    thanks for your hints. We will likely use Hall sensors in our application. As mentioned previously, I just tested a default sensorless firmware to quickly check the standard SW options and HW connections before starting firmware customization.

    I will resume testing soon and I will inform you about any relevant finding then.

    Best regards,


  • Hi Aaron,

    I have successfully tested both sensored and sensorless configurations using a new evaluation board. I also successfully repaired the original board (gate driver replaced). The system functionality and signal waveforms have been checked carefully under various operation conditions.

    I was not able to reproduce the fault - everything works flawlessly. However, I guess the failure was caused by incorrect driver configuration. I noticed that the jumper locations are a bit confusing:

    • Unintuitively, positions are counted from right to left.
    • A small PCB silkscreen dot indicating first position is shifted towards next  jumper block giving the impression of left-to-right ordering (see attached picture).
    • It seems that the boards are delivered in an inconsistent configuration (sensorless firmware programmed and independent FET mode selected).

    The correct position of first pin is clearly indicated by a rectangular copper pad (visible from the bottom side only) and it is also mentioned in the User's Guide.

    Although I am not able to guarantee an exact jumpers location when driver failed, I likely used an incorrect left-to-right rule resulting in improper and unintended configuration (MODE: independent FET, IDRIVE: 200 mA, VDS: 0.06V). I guess it is the best explanation - bypassed dead time in this mode would result in FET shoot-through with all detrimental effects. I tested this configuration (with limited supply voltage) and, as expected, excessive ringing at driver pins was observed. Its magnitude can easily exceed maximum driver's rating under worst conditions.

    I guess we can close this issue. Thanks a lot for your support.

    Best regards