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.

DRV8305: Problems with two identical boards .

Part Number: DRV8305

Hi, 

I am working on a prototype of a driver for BLDC motors that employs a controller for BLDC motors using a DRV8305NPHPR gate driver. I have soldered a couple of complete boards. On one of them, everything works perfectly, while on the other, running exactly the same software, the gate driver is not functioning correctly.

Making readings from the DRV8305NPHPR registers through the SPI interface, I observe that in the case of the non-functioning board, the values are as follows:

---Warning and Watchdog Reset---
    Reading Register : 0x01
    Byte 0 : 00000100
    Byte 1 : 00100000
    Register 0x01: 0010000000000100
    [ FAULT | TEMP_FLAG2]
---OV/VDS Faults---
    Reading Register : 2
    Byte 0 : 00000010
    Byte 1 : 00000000
    Register 0x02: 0000000000000010
    [ SNS_C_OCP]
--- IC Faults ---
    Reading Register : 3
    Byte 0 : 00000000
    Byte 1 : 00000000
    Register 0x04: 0000000000000000
    [None]
--- VGS Faults ---
    Reading Register : 4
    Byte 0 : 00000000
    Byte 1 : 00000000
     Register 0x04: 0000000000000000
    [None]

The schematic of the connections of the DRV8305NPHPR is shown below.

Some questuions:

  • Could someone indicate the origin of what might be happening for the design to work perfectly on one board and not on the other?
  • Could someone suggest recommended actions to take to try to solve the problem?
  • How is it possible to get a temperature-related error when the device is at room temperature?

Thank you very much in advance for the time spent trying to resolve the issue. If additional information is needed, please feel free to request it.

  • Hi Jorge,

    Thank you for posting to our support forum! 

    I can say it is very unusual to have a device behave this differently in the same conditions. Can you please ensure that the layout/solder connections on the second PCB have no mismatch or errors compared to the first working board? 

    In this situation, I would recommend conducting an A-B-A swap, where the second unit with the issue is replaced on the first known, working PCB, and then observe if the device is still behaving oddly.  If the unit works on the first board then we can conclude that there is a further issue on the second PCB, or if not, we know the unit itself is experiencing odd behavior. 

    Please let me know if you're able to conduct this test.

    Best Regards,

    -Joshua

  • Thank you for your prompt response. I appreciate your guidance, and I will make an effort to implement your suggestions as soon as possible.

    In the interim, I'm curious about the possibility of an overtemperature error occurring even when the device is at ambient temperature. Would you consider adjusting the registers that allow errors to be ignored as a potential solution? I'm wondering if this approach could resolve the issue or if it might lead to further complications.

    I want to express my gratitude once again for your assistance. I'll be sure to share the results after conducting the test you recommended.!!

  • Of course, Jorge! 

    In the interim, I'm curious about the possibility of an overtemperature error occurring even when the device is at ambient temperature. Would you consider adjusting the registers that allow errors to be ignored as a potential solution? I'm wondering if this approach could resolve the issue or if it might lead to further complications.

    There is a possibility for this circumstance (device operation is normal at ambient temp) if the device had an OverCurrent event (OCP) and quickly heated up the internals of the device, or if the internal temp sensor was damaged. But first can you clarify how often/when the OTP flag trips during operation? If the device is working with only a temperature warning (as pictured below) and no other issues, then disabling the OTP protection is an option, but you will of course lose that layer of protection for your application.

    Can you try clearing the fault as well as observe if it stays cleared?

    Thank you for your patience and Best Regards,

    -Joshua

  • Thank you very much for the suggestion, I will try to carry out what you suggest and as soon as I have it I will post the result here.

  • Thanks Jorge,  wish you well in your testing. 

    Best Regards, 

    -Joshua