• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 548 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Can we use DRV8305NQPHPQ1 instead of DRV8305NPHPR without any change ?

Tsuyoshi Iriyama
Prodigy 10 points
Part Number: DRV8305

Hi I am Iri. 

I had read below FAQ prior to post here. But we would like to know more detail. So let me allow to confirm again more detail.

DRV8305-Q1: the difference between DRV8305NQPHPRQ1 and DRV8305NPHPR - Motor drivers forum - Motor drivers - TI E2E support forums


Can we use DRV8305NQPHPQ1 instead of DRV8305NPHPR without any change ?
It looks like there are slightly differential between 2 chips. 

Due to supply shortage of DRV8305NPHPR now, we would like to evaluate DRV8305NQPHPQ1 very short period.

We tried to replace one DRV8305NPHPR to DRV8305NQPHPQ1. 
However, replaced DRV8305NQPHPQ1 and Lch FET (due to VDS error) were broken when the motor started to be driven.

Condition:
Rch→DRV8305NPHPR (Original circuit)
Lch→DRV8305NQPHPQ1 (evaluated)
VREF: Internal VREF is not used. (External Vref is provided.)

Could you please support us and let us know whether these 2 devices are replaceable as an alternative device or not...
We are not sure that the impact of the circuit difference of DC_CAL(SPI).

  • 0
    TI__Mastermind 18981 points

    Hi Iri, 

    Sure - thanks for reaching out about this topic through the e2e forum. 

    Will check with the team about this to investigate further about any functional/spec differences other than automotive rating, aiming to give you a response by end of this week. 

    Thanks and Best Regards, 
    Andrew

  • 0
    TI__Mastermind 18981 points

    Hi Iri, 

    Thanks for your patience on this - I did get some initial feedback from the team on this topic. 

    From the team's inputs, the devices you listed should be pin-to-pin compatible as long as they're both the 'N' versions of auto/industrial DRV8305. 

    The main difference between the variants of DRV8305 (N vs NE vs 5 vs 3) are the LDO (VREG/VREF) functionality. 

    • In your 'N' version, the LDO is treated as VREF external input - and that seems to be correct according to your earlier comments. 

    Device

    DRV83053Q

    DRV83055Q

    DRV8305NQ

    DRV8305NE

    Ambient Temperature range (oC)

    -40 to 125

    -40 to 125

    -40 to 125

    -40 to 150

    LDO

    3.3 V / 50 mA

    5 V / 50 mA

    NO

    NO

    Overtemperature shutdown

    Yes

    Yes

    Yes

    NO

    I am not too sure about whether the CSA has any major differences, but the DC_CAL CSA calibration procedure is best done while the system is not switching, so I am not expecting the differences in the side-by-side diagram you shared to cause any problems in the system 

    Can you tell us a bit more about the error found when trying to swap in a new part? 

    • any information in the SPI registers for fault reporting? 
    • waveforms of any strange motor driving behavior may also be helpful 

    Thanks and Best Regards, 
    Andrew 

  • 0 in reply to Andrew Liu
    Prodigy 10 points

    Thank you for your quick reply.

    <DC_CAL CSA>
    We understood the device differential regarding LDO.  

    -DRV8305NP(Current): External Voltage reference type (VREG/VREF: we connected external 3.3V)

    -DRV8305NQ(Swapped): External Voltage reference type (VREG/VREF: we connected external 3.3V)

    And regarding DC_CAL CSA calibration, from your comment, we understood the impact is negligible. 

    <IC Fault>
    >Can you tell us a bit more about the error found when trying to swap in a new part? 
    >any information in the SPI registers for fault reporting? 
    >waveforms of any strange motor driving behavior may also be helpful 

    Sorry, We don't have waveforms capture but we found that the error type was "IC Faults D0: VCPH_OVLO_ABS". 
    If you have any assumption for this fault, please let us know.

    <Charge Pump Setting>
    We also concern about the differential of charge pump setting.
    Current setting is default 0x0 (RSVD, none setting parameter for charge pump), but default 0x0 of Q1 type is charge pump frequency setting to "518kHz center".

    We also tried to swap both ICs to Q1 type without change FW, then, motor driving when low speed was not operated smoothly. (repeat stop and move) 
    So we would like to know whether this differential could be affected to motor driving characteristics especially low speed (high torque) condition.

  • +1 in reply to Tsuyoshi Iriyama
    TI__Mastermind 18981 points

    Hi Iri, 

    Thanks for the updated response -

    Looks like we're ok as far as LDO and CSA operation so far. 

    Moving onto the next topics to debug: 

    1. If you are seeing a 'VCPH_OVLO_ABS' type fault, then this means the charge pump is probably experiencing too much voltage above the rated spec and that's why it's reporting a fault in SPI and possibly nFAULT pin voltage 
      1. The datasheet recommendations for charge-pump related components (flying cap, storage cap) are the same -> so I don't think there would need to be any update to layout or component selection between the two devices
      2. It may be helpful to capture a waveform of the voltage waveforms for VCP, VM, CP1H/L, CP2H/L to observe what's going on 
      3. I don't think there is a difference in this parameter between DRV8305 and DRV8305-Q1, but the scope captures will tell us more info on whether this is the root cause of the problem
      4. charge pump freq SPI register bit could be something to look into -> let me ask the team about this. Although it does seem like the default setting is being used in both cases anyway 
    2. If the motor is not operating smoothly at low speed, 
      1. can you help share some waveforms of the gate drive signals? 
      2. we want to observe what INHx/INLx with GHx/GLx and SHx looks like 
      3. If the waveforms are very distorted, this could point to an underlying layout problem or schematic problem
         

    Here is the spec for the SPI fault flag you are seeing in VCPH_OVLO_ABS

    Best Regards,
    Andrew 

  • 0 in reply to Andrew Liu
    Prodigy 10 points

    Hi Andrew san

    Thank you for your information.

    Do you have any update for the below item ?

    d. charge pump freq SPI register bit could be something to look into -> let me ask the team about this. Although it does seem like the default setting is being used in both cases anyway 

    As our verification result until now, we are going to give up the replacement from DRV8305NP to DRV8305NQ without any design change. 

    Best regards,

    Iriyama

  • 0 in reply to Tsuyoshi Iriyama
    TI__Mastermind 18981 points

    Hi Iri,

    I do not yet have an updated response for that item - but will be meeting with the team for automotive support this week 

    Thanks for the update on your project status

    Best Regards, 
    Andrew 

  • 0 in reply to Tsuyoshi Iriyama
    TI__Mastermind 18981 points

    Hi Iri,

    I did get a chance to align w/ the team on this today - please see below information: 

    From charge pump switching frequency behavior, the only impact this should have on the system is EMI (electrical noise caused by high-speed switching). 

    Therefore, we do not believe that it will be the root cause of the VCPH_OVLO_ABS behavior. 

    Systems team alignment is that these two devices should be able to swap as pin-to-pin replacements, as long as they're the same variant (N version, for example) 

    Best Regards, 
    Andrew 

  • 0 in reply to Andrew Liu
    Prodigy 10 points

    Hi Andrew san

    Thank you for your sharing charge pump impact review result.

    We understand that theoretically said these two devices should be able to swap under the same variant (N version).

    On the other hand, as our verification result, we can not swap without any design change. So we may have another root cause. 

    Thank you.