• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 298 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: Fault with driver giving unexpected status register value for nFAULT and nOCTW states

Richard_McAleer
Intellectual 460 points
Part Number: DRV8301
Other Parts Discussed in Thread: CSD88537ND, TMS320F28035,


Hi

We are using a TMS320F28035 to drive a DRV8301DCA chip into some CSD88537ND FETs for a motoro control project

On some units we see faults and I am trying to determine where the root issue might lie.

When the faults occur rotation ceases immediately, both the nOCTW and nFAULT lines from the DRV8301DCA throw and on inspection the Status 1 Regsiter reads 0x400
This would indicate that the FAULT bit (Bit10) has latched; and only this bit.

The values read for all registers are.
Status1 0x400
Status2 0x801
Config1 0x13d2
Config2 0x1801

From the "fault warning reporting and handling" table in the DRV8301 datasheet (table 5) I would have expected either more bits to have been set in the status register.
Having both the nFAULT and nOCTW pin throw would suggests OTSD_GATE or EXTERNAL_FET_OVERLOAD conditions which I would have thought would show on the OTSD or OC bits.

I would be grateful for any suggestions as to how to further diagnose what could be the issue.

Best regards,
Richard

  • 0
    TI__Mastermind 26046 points

    Hi Richard,

    Thanks for sharing this issue. 

    Do you know what kind of motor control performance is causing the FAULT bit to be set? Is it when PWMs are set, motor current is running, or another type of condition? 
    What overcurrent mode are you in, latched shutdown or CBC? Does increasing OC_ADJ_SET help the issue?

    Does this issue appear on all devices or just a select few? 

    Thanks,
    Aaron


  • 0 in reply to Aaron Barrera
    Intellectual 460 points

    Hi Aaron

    It happens when the motor is spinning - most commonly at a large change in load (e.g. a big step change in speed) but I have seen it on motors that were at steady state 

    - so there does appear to be variation across devices and I am looking to try and ascertain from the data we have where the root cause might lie

    What was confusing is that I would have expected more bits to have been set in the register given the table in the data sheet.

    The Driver chip is configured with: 

    Config1 0x13d2 : ie. 0001 0011 1101 0010

    Which unpacks to:

    GateCurrent   10 - Peak current 0.25mA
    Gate Reset    0 - Normal mode
    PWM_Mode   0 - 6 PWM inputs
    OCP Mode   01 - OC Latch Shutdown
    OC_ADJ_SET   01111 - 0.454 Vds


    Config2 0x1801 i.e: 0001 1000 0000 0001

    Which unpacks to:

    OCTW_MODE 01 - report OT only
    GAIN 00 - 10V/V
    DC_CAL_CH1 0 Amp 1 to load
    DC_CAL_CH2 0 Amp 2 to load
    OC_TOFF 0 - Cycle by cycle

    The csd88537nd FETs we are using should have an RdsON ~12mOhm at the 24V we are using

    With the OC_ADJ_SET as above this should require ~30Amps to trip?

    Which is above what our power supply can really deliver

    I suppose this (and the OCTW mode) points to it being an OverTemp fault; however should this not be represented in the bits of the status register?

    All the best

    - Richard

  • 0 in reply to Richard_McAleer
    TI__Mastermind 18926 points

    Hi Richard,

    Thanks for sharing such detailed information in your e2e post - I have a few questions and suggestions to help debug the behavior:

    • Debug Experiment: 
      • for OCP mode, can you help set the register setting to instead be 00, for 'current limit' as cycle-by-cycle current instead? 
        • we are curious if this changes the behavior of the device
      • for OCTW_MODE, can you let us know if the problem persists even if you use different settings in these two bits? (d1, d0)

    • Possibility that the SPI registers might be getting reset accidentally? (clearing the fault-specific bits?) 
      • is there any activity on the EN_GATE pin or on the RESET_GATE that could possibly be clearing the SPI registers? 
      • does the nFAULT pin hold low for the entire duration of the behavior? or does it show any recovery at all, even if just briefly?
      • was there any action that could've occurred, resulted in writing a bit to 'RESET_GATE' SPI register to clear the faults? 
    • quick clarification: the OC_ADJ_SET of ~01111 = 15 corresponds to 0.358V and not 0.454V for Vds, but your estimate of ~30Amps still sounds correct to me based on the updated calculation values. So I don't think this is the root cause of the problem regardless, but just wanted to let you know in case it impacts future CSA settings once we resolve this nFAULT problem. 

    Lastly, can you help share some details about the samples that you are using? 

    • would you be able to share the lot trace code / assembly lot# (or the device topsymbol marking)?

    Best Regards,
    Andrew

  • 0 in reply to Andrew Liu
    Intellectual 460 points

    Thanks Andrew

    I should be in a possition to try and test your suggestions in the next few days (workinf remote from the hardware at the moment)

    Thanks for pointing out the mistake in my reading of the OC_ADJ_SET table.

    Having checked our code again it is possible that only one of the OCTW or FAULT line might be throwing (I'll recode shortly to tease these apart - but I was mistaken in my understanding of our error reports)

    The status registers should be being read prior to any activity on the GATE_EN line
    - it is used to disable the driver chip immediately after the SPI reads,
    - the SPI reads themselves are done as soon as either of the OCTW or FAULT are detected (they are monitored in a 1ms poll) 

    Thanks for the suggestions I should hopefully have some more info in the next couple of days

    Best regards,

    - Richard

  • 0 in reply to Richard_McAleer
    TI__Mastermind 18926 points

    Hi Richard, 

    Thanks for the update - we'll be here for the next step of the debug once needed 

    Best Regards,
    Andrew

  • 0 in reply to Andrew Liu
    Intellectual 460 points

    Switching to use a current limit prevents the tripping; indicating that it was an OC condition.

    I have reduced the allowed Vds to a level where we seem to retain the necessary performance.

    I think I can make use of this if I am careful to ensure that we have a method to detect stalls so as to prevent burning out the motors,

    Thanks for the help.

    Best regards,

    - Richard

    (Apologies for the delay in response: I tried to post this a couple of weeks back and I find it today in draft form when I revisited this page)

  • 0 in reply to Richard_McAleer
    TI__Mastermind 18926 points

    Hi Richard,

    thanks for the update - and we are glad to see that switching the overcurrent mode is a viable workaround for your system 

    Best Regards,
    Andrew