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.

DRV8320: No communication issue.

Guru 11255 points
Part Number: DRV8320

Hi team,

During the evaluation for DRV8320S, the motor stopped working and my customer could not control DRV8320 on I2C.
What is the state when I2C can not communicate?
Is there an error that cannot be canceled even when the power is turned on / off?

Sincerely.
Kengo.

  • Hello Yoshikawa-san,


    When you say I2C, do you mean SPI? The DRV8320S is a SPI device. For further clarification of the problem, can you tell me the following information:

    • Was the motor spinning before this problem occurred?
    • (if yes,) Was there a fault before the motor stopped working?
    • Is there a continuous fault that is indicated when you try to control the device with SPI?
    • Were you able to read the registers before and after the occurrence?
    • Were you able to write to the registers before the occurrence?

    The answer to these questions will help to better understand what is going on and hopefully point us to a solution. There are a few possibilities that would result in being unable to communicate over SPI: if the voltage to the DRV is too low then the driver would be unable to sufficiently power up to communicate. Another possibility could be incorrect timing for the SPI communication sequence (section 7.6 goes into more detail on SPI timing).


    Best,
    Johnny

  • Hi Johnny-san,

    Thank you for your support.
    I'm sorry, it was a typo...SPI is correct!

    I'll answer your questions.

    • Was the motor spinning before this problem occurred?
       -> Yes, it noticed that the motor stopped.

    • (if yes,) Was there a fault before the motor stopped working?
       -> No, they could not find a fault signal.Because the Fault pin does not connect.

    • Is there a continuous fault that is indicated when you try to control the device with SPI?
       -> No, they couldn't communicate with SPI already when this problem occurred.

    • Were you able to read the registers before and after the occurrence?
       ->They couldn't read the registers after the occurrence.

    • Were you able to write to the registers before the occurrence?
       -> Yes.


    Sincerely.
    Kengo.



  • Kengo-san

    The default settings for the IDRIVE of this device is the highest IDRIVE setting, which is 1000/2000 mA. For most MOSFET's (depending on the QGD of the MOSFET), that IDRIVE is too high, and this setting can cause permanent damage to the driver due to ringing on the gate. Since the device was operated before changing the gate drive settings via SPI, What has likely happened is that using the default IDRIVE settings to drive the motor has caused damage to the device in a short time of operation.

    For more information on how to choose the correct IDRIVE setting, you can visit the following FAQ: https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/796378/faq-selecting-the-best-idrive-setting-and-why-this-is-essential

    Here's an article on the proper SPI protocol: https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/937258/faq-spi-configuration-and-use?tisearch=e2e-sitesearch&keymatch=FAQ%252520SPI

    I would recommend probing your SPI pins (SDI, SDO, SCLK, nSCS) and comparing the waveforms to the waveforms shown in the FAQ to ensure that the code is sending the signals in the right order. You can also refer to section 7.6 of the datasheet on the proper the timing requirements for SPI communication. If you still have issues, please reach out, and we can continue to debug.

    best,

    Johnny