• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 29 subscribers
  • Views 807 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DRV8301 Error Generation and Lockout in application

Dewayne Sowell
Prodigy 40 points
Other Parts Discussed in Thread: DRV8301

Our current setup utilizes the DRV8301 Driver IC, though we are not currently using the Buck converter feature (hardware disabled), all other IO are configured as suggest as per the datasheet. All register setting remain at default. Shunt resistor values are 1mOhm. R_ds, on of drive FETs are 6.8mOhm.

When applying a hall-effect driven step sequence for standard trapezoidail drive, both OCTW and FAULT pins are being driven low, indicating an error, and all FETs latched in a high Z state until the error pins reset. Under certain no-load conditions, the drive can be started by hand to run at a constant speed, but with the IN_X and G_X  broken out to an external header for monitoring, this no longer seems to be the case. 

The error indicated by the data sheet would be Over Temp, or External FET overload-latch mode, which from my reading of the datasheet is not the default error reporting state.  

What is causing the error generation? How can we get rid of it?

  • 0
    TI__Guru** 114905 points
    Hi Dewayne,

    Have you read the Status Register to determine the specific event?

    Does this OCTW and FAULT pins go low immediately upon trying to start the motor?
    Can you provide a schematic?

    If you have scope captures of the motor current at the point the OCTW and FAULT pins go low, would you please provide them also?
  • 0 in reply to Rick Duncan
    Prodigy 40 points

    We haven't established SPI communication yet to capture the specific event.

    As shown in the Captures, they do go low immediately when starting the motor, until they partially reset (shown in the last capture "Logic Step 5 to Step 6 analog fault") then promptly fire again.  I can provide a partial schematic without having a NDA in place.

    Thank you,

    Dewayne Sowell

    Electronic Hardware Engineer, Vector Horizon Technologies, LLC

     

  • 0 in reply to Dewayne Sowell
    TI__Guru** 114905 points
    Hi Dewayne,

    In addition to the 1200uF bulk cap, the datasheet shows a couple of local caps at PVDD1 (4.7uF and 0.1uF) to help with local bypassing. Can you place at least a 4.7uF ceramic cap as close as possible to PVDD1?

    Also, if you have caps C23, C24, C25 populated this could cause a delay in the halls that is affecting performance. The RC time constant is 100us when rising. Please remove them if possible and evaluate if they are required.
  • 0 in reply to Rick Duncan
    Prodigy 40 points

    Rick,

    After have  placed a 4.7uF ceramic cap directly from PVDD1 to GND, the captured signals (shown below) were cleaner, though the fault code still persist.

    After removing the caps C23, C24, C25 (Hall effect signal shown below), our signals are robust. Issue still persist.

    Please advise. Thank you.

  • 0 in reply to Dewayne Sowell
    TI__Guru** 114905 points
    Hi Dewayne,

    Glad to hear there is some improvement on signal quality.

    Have you been able to establish SPI communication and read the fault codes?
  • 0 in reply to Rick Duncan
    Prodigy 40 points

    Rick,

    My firmware guys still don't have the SPI working reliably on these PCBs. It is worth noting that these PCBs were a first gen, and as such, have multiple jumpers applied to the lines of the driver IC. We had basic drive running, then connected jumpers to the relevant drive pins for external monitoring. As a sanity-check, we've tried to reset any errors by keeping all PWMs low and toggling the enable pin low for .25 sec (as seen below). As you can see, the error lines remain low during and after the reset. Whatever the issue is seems to be resolved on our gen 2 boards, but we would still like understand the surrounding circumstance that seems to have "locked" the driver IC in an error condition.

    Please advise as to what may have caused this behavior.

    Thank you, 

    Dewayne Sowell, Hardware Engineer, Vector Horizon Technologies

  • 0 in reply to Dewayne Sowell
    TI__Guru** 114905 points
    Hi Dewayne,

    I am glad to hear the gen 2 boards work as expected. Now that you have working gen 2 boards, can you describe the differences with respect to the schematic and layout?

    Hopefully we can concentrate on the differences to determine why the gen 1 boards did not work.

    Also, can you confirm the layout guidelines of the DRV8301 datasheet have been met for both gen 1 and gen 2 boards? In particular, please look at the local capacitors on PVDD1 of the DRV8301, and PVDD of the power FETs.