DRV8243-Q1: Inquiries about thermal estimation and DIAG-pin configuration

Part Number: DRV8243-Q1

Tool/software:

Dear team,

Let me ask the questions about the datasheet.

#1: Table7-1 shows the transient thermal impedance and current capability. Does it use Rds_on MAX value or TYP value? D/S shows typical value in room temp and max value in 150C. I like to know which is referred for this estimation. Meanwhile I will recommend customer to use the thermal estimation tool(SLVRBI3) for their load profile.

#2: For the thermal estimation tool(SLVRBI3) includes switching loss even "user input#5 = Typical"? If yes, which spec(SR and deadtime) are referred?

#3: Table7-1 mentions "- full bridge", so can we understand it is the data when both HB is used? My customer will be use it for independent mode.

#4:  In HW variant with independent mode, the DIAG-pin can be configure as shown in Table8-12. When R_LVL3OF6 or 4OF6, IPROPI will be disabled.
In this case how will IPROPI be? is it Hi-Z?

#5: Also in this same situation, even OCP is latched, IPROPI does not flag anything? In other words, it will not be "VIPROPI_LIM" - is it correct?

Best regards,
Yuto

  • Hi Yuto,

    Does it use Rds_on MAX value or TYP value? D/S shows typical value in room temp and max value in 150C. I like to know which is referred for this estimation.

    To start, the RDSon typical value at 25C is used. Since these values are at 85C ambient temp, the RDSon is multiplied by a scaling factor based on char data so that the RDSon is correctly adjusted for 85C. For the DRV8243 the RDSon scaling factor that is used was roughly ~1.9. 

    For the thermal estimation tool(SLVRBI3) includes switching loss even "user input#5 = Typical"? If yes, which spec(SR and deadtime) are referred?

    When cell C5 is set to "Typical", deadtime = 750ns and SR= slewRate selected * 0.7. When cell C5 is set to "WorstCase", deadtime is 975ns and SR=slewRate selected. These values were determined with the help of design.

    Table7-1 mentions "- full bridge", so can we understand it is the data when both HB is used? My customer will be use it for independent mode

    The RthetaJA values were simulated with the devices power distribution being from an H-Bridge configuration. The device may be able to handle more current for longer before hitting TSD if only one FET is conducting instead of two but the actual capability would need to be tested with the EVM.

    In HW variant with independent mode, the DIAG-pin can be configure as shown in Table8-12. When R_LVL3OF6 or 4OF6, IPROPI will be disabled.
    In this case how will IPROPI be? is it Hi-Z?

    I admit that this is a bit confusing and should be updated. IPROIPI is not disabled, the reason this is mentioned is that the load is noted as being a high side load in the Diag table. In the case of a high side load, the high-side FET of the half bridge will not drive current which is required for IPROPI to sense and output the load current.

    Also in this same situation, even OCP is latched, IPROPI does not flag anything? In other words, it will not be "VIPROPI_LIM" - is it correct?

    In the case that OCP it hit, IPROPI will be clamped to VIPROPI_LIM. Let me know if you need some captures to show that this is the case, I will have to go to lab to get them for you.

    Regards,

    Joshua

  • Hi Joshua, 

    thank you for your comments and most of them makes sense.

    in terms of IPROPI, the customer will use high-side load. In this case IPROPI AND OCP cannot be used - is that correct?

    If yes, should we tied IPROPI to GND via some resistance(maybe 10k ohm)?

    best regards,
    Yuto

  • Hi Yuto,

    OCP will function when driving a high side load, the OCP detection is independent from the IPROPI and ITRIP circuits.

    it is correct the IPROPI cannot be used if a high side load is used, in this case tying IPROPI directly to GND is ok if the clamping to indicate a short to GND fault is not needed. If this is needed, then a 10kOhm resistance between IPROPI and GND is good but even something as low as 1kohm is still ok.

    Regards,

    Joshua