DRV8703-Q1: intermittent VDS monitor fault

Hi Matt,

Can you provide scope captures of nFAULT, nSLEEP, IN1, and IN2 and two others of nFAULT, nSLEEP, Vg, and Vd of the each low side FET?

It seems you are putting both IN1 and IN2 high to turn on the low side FETs, question is when are they turning on exactly to see if it is occuring too close to the 1ms turn on time. Also, the next question is why you get the VDS fault and from which FET it is coming from.

Hi Hector,

Thanks for the reply. I'll work on getting those scope captures, but I can say the MCU application has no artificial delay between setting nSLEEP, turning on the outputs for IN1/IN2, and sending the SPI configuration (in that order). Could the behavior I'm seeing here happen sporadically on a subset of parts if those three events are too close together?

Regarding your second question, register address 0x00 was set to 0x90 and address 0x01 was set to 0x04 after the fault was first detected by the MCU code. This would indicate the fault is from the FET connected to GL2 on the driver correct? If so, the FET captured in the second screenshot above at least shows the condition of those three pins during the fault.

Thanks,

Matt M.

Hi Matt,

Regarding your first point: As a best practice, I recommend you first setup your MCU clocks and peripherals, including your SPI, then set nSLEEP when you need to turn on the device, make sure at least 1ms has passed (it can be assured with a software artificial delay or other method you deem possible), then setup your DRV through the SPI transactions, and finally manipulate on your outputs. If you turn on the outputs before setting up the DRV registers via SPI, you could be manipulating the driver with default register values, and it could be incorrect if you need your registers setup in a non-default state.

As for your second point: I want to get a zoomed in view to what happens magnitude wise on Vg, Vd and Vs of GL2 FET to justify the Vds_ocp fault.

As for the scope captures, please capture these signals instead:

1. nFAULT, nSLEEP, nSCS, and IN2

2. nFAULT, Vg_L2, Vd_L2, and Vs_L2 with a trigger point when nFAULT asserts low and make sure you capture what happens before the fault

Information requested:

1. VDS_LEVEL, and the FET Rds(on)

Hi Hector,

I was able to cause a regression of the fault by heating one of the boards, supporting the idea of a potentially marginal VDS threshold or startup timing if our clock is drifting.

Here is the startup (with the software as-is) producing the fault:

As you can see, the SPI configuration and IN2 come up at almost exactly the same time, so the DRV still likely has the defaults loaded when IN2 is first enabled. We plan to make that timing change to make sure the values we want are loaded well before the inputs are first turned on.

Here is a capture of the low side FET pins with the half bridge open (no load connected, however the behavior looks similar with a load connected):

For the information you requested:

The current configuration is writing registers 2-5 in order, so the VDS configuration is not sent until the third transaction in the first capture above, but the code is changing from the default VDS of 0b111 (0.96V) to 0b100 (0.12V).

The FETs have an Rds(on) of 6.9mR nominal, Infineon part number IPD90N06S4-07.

Thanks,

Matt M.

Hi Matt,

Thank you very much. One more clarification/request: Can you zoom in or scope capture in the 1us/div scale the yellow highlighted area? Similar to what you initially provided, but with the nFAULT being the trigger. Make sure that the fault is L2_VDS when you capture it. At this zoom scale I cannot read the magnitudes around the fault trigger point clearly.

Hi Hector,

Here is a zoomed in capture of just the falling edge of the nFAULT line:

I did confirm that the fault registers still have the FAULT, OCP, and L2_VDS bits set when the driver is faulting on startup.

Thanks,

Matt M.

Hi Matt,

My theory is that, if your voltage scale is 2 V for Vd and for Vs, that your Vd - Vs is going over 120mV, which is your Vds_level setting. To further verify that this is true, you will need to zoom in even further to further if that voltage difference is occuring right before the fault starts to drop.

Additionally, it seems your Vs has some coupling or ground bounce on it, which you can see on nFAULT as well. Vs gets to 1 V at certain moments. We can potentially clean up this bouncing by lowering your IDRIVE setting (not sure what setting you are on). If the bouncing is acceptable and you have leeway to increase your Vds_level higher, you might be able to avoit the fault. All of these settings, of course, depend on what is functionally required in your application.

Hi Matt,

Pinging this conversation for an update. Thank you.