DRV8245-Q1: nFault goes low ~200us after clearing

Hi Sebastian,

Thank you for posting in this forum. 

Sebastian Hoyer said:

We have multiple DRV8245 connected to the same nFault pin with a 10k ohm 3v3 pullup.

This is fine. The nFAULT pin is an open drain pin so connecting multiple together will form an OR connection with a pull-up resistor. I assume you have only one 10 kΩ pulled up for all the nFAULT tied together. How many devices are connected together?

Sebastian Hoyer said:

We have multiple DRV8245 connected to the same nSleep pin with a 10k pulldown.

For the device(s) to be awake nSLEEP must be logic HIGH. Having a pull-down for LOW with many pins connected together should be fine. When the nSLEEP pin(s) are made HIGH and LOW they must comply with the VIH and VIL specifications in the datasheet. Please measure and verify HIGH and LOW voltages.

Sebastian Hoyer said:

We are seeing an issue in our design where we are unable to drive any outputs of the DRV8245 (hardware variant). 
The startup sequence is:
1. Put device into sleep mode by pulling nSleep low for >tSleep max
2. Wake up device by setting nSleep high for >tReady
3. Clear fault by pulling nSleep low for >tReset max (and less than tSleep min)
4. nSleep high

During the startup sequence we can see that nFault goes high when issuing the clear fault pulse, but about ~200us after the nFault goes low again.

This follows the recommended sequence in the datasheet. The nFAULT should go HIGH after tRESET. If a fault was reported by nFAULT LOW that may indicate an actual fault condition. Does it get cleared if you issue another tRESET pulse on nSLEEP? How much tRESET time was used? Could you also please try to extend the tRESET pulse even longer?  

Because multiple devices drive nFAULT in parallel it may be challenging to find if only one device was the offending device or multiple devices reported issues. Can we get oscilloscope captures of the nSLEEP and nFAULT during these initialization process? Thank you.

Regards, Murugavel

Hi, thanks for the quick response.

Murugavel4637 said:

Sebastian Hoyer said:

We have multiple DRV8245 connected to the same nFault pin with a 10k ohm 3v3 pullup.

This is fine. The nFAULT pin is an open drain pin so connecting multiple together will form an OR connection with a pull-up resistor. I assume you have only one 10 kΩ pulled up for all the nFAULT tied together. How many devices are connected together?

Yes, we have single 10k ohm pullup for all the nFault tied together. We have a total of 10 devices tied together. 
Will a single device pulling the nFault low affect the ability to drive the out1/out2 on the other devices? (i.e. assume that only single device fails)



I believe the rest of your questions are best answered with oscilloscope captures:

Channel 1: nSleep pin 
Channel 3: nFault pin

Capture 1: Initialization sequence with an extra RESET pulse added. nSleep has been low for a couple of seconds prior to this, VM has been stable 24V for a couple of seconds prior to this as well.

The wakeup pulse is low for 2ms
The reset pulse is low for 36µs (see capture 2)

I tried setting the reset pulse time to 20, 30, 40, 50, 60....100µs but it did not resolve the issue.





Capture 2: Zoom in on RESET pulse 1.

We are not able to drive the OUT1/OUT2 of any of the 10 devices. We have measured the IN1/IN2 to confirm that we do drive the input pins as expected, but nothing happens on the OUT1/OUT2. However after waking up the DRV8245 the voltage level on OUT1/OUT2 goes from 0V to ~0.4V.

Best regards, Seb.

Hi Sebastian,

Thank you for sharing additional information about your system.

Sebastian Hoyer said:

Will a single device pulling the nFault low affect the ability to drive the out1/out2 on the other devices? (i.e. assume that only single device fails)

nFAULT is only a fault reporting output pin. It does not affect device operation. 

Sebastian Hoyer said:

We are not able to drive the OUT1/OUT2 of any of the 10 devices. We have measured the IN1/IN2 to confirm that we do drive the input pins as expected, but nothing happens on the OUT1/OUT2. However after waking up the DRV8245 the voltage level on OUT1/OUT2 goes from 0V to ~0.4V.

Can you please verify if you isolate a single device nFAULT with a separate pullup (for testing only) that particular device functions as expected? Thank you.

Regards, Murugavel

Hi,

Thanks for the support on this.

We tried isolating a single device nFault with 10k pullup like you suggested. This did not change anything and the device still behaves as before, pulling nFault low about 100-200µs after the reset pulse. 

We tried with and without a low-side load connected to both outputs.
We also tried looping the reset pulse duration from 1-200µs but it did not change the behavior.
We tried with different states of IN1/IN2 as well.


Just to be 100% clear this is our HW setup per device (the shared nFault and nSleep pull-up / pull-down are outside the scope of the picture). OUT1/2 just routes on to some connector terminals where we can connect our load.
Let me know if you see any issues with it that could explain the behavior.




Best regards, Seb.

Hi Sebastian,

Thank you for trying our suggestion and reporting back. This may be pointing to some other issue in the system. Based on your schematic the MODE is set to Independent half-bridges, ITRIP to about 3.43 A, slew rate to the slowest 1.5 V/us and DIAG with RLVL1OF6. DRVOFF = GND, bridges enabled.

As per the DIAG table in the datasheet with DIAG connected to GND the outputs will support a low-side load, and fault reaction is retry, load connected OUTx to GND. You mentioned this was how you had load connected. Thus far I did not see anything unusual with your schematic.

nFAULT = LOW; Could there be a short in the PCB that may be causing this fault? Was the bare board thoroughly tested for continuity and shorts? I assume all layout related issues were ruled out. Because you mentioned the behavior is the same with and without load connected. Can you also try with a faster SR setting, let's say SR to GND with 100 kΩ resistor? 

An output short to GND can be identified by measuring VIPROPI on the IPROPI pin. A 5 V on this pin indicates a short.  

Do you have one of our EVMs for this device for evaluation purpose? Thank you.

Regards, Murugavel 

Hi,

The voltage on the IPROPI pin is 0V.

Since my last reply we ordered a DRV8245H-Q1EVM.
We got it up an running with the evalutation software.
We then reconfigured the EVM jumpers to match our setup in regards to DIAG,MODE,SR,IPROPI,ITRIP.

Then we tried connecting touchpoints from our PCBA to the J4 header on the EVM (nFault, nSleep, IN1, IN2) and used our processor to drive the DRV8245 on the EVM - this was succesfull.

We also tried the other way around, using the processor on the EVM board to drive the DRV8245 mounted on our PCBA - this was unsuccesfull.

So we have somewhat isolated the root cause to be related to our PCBA. The PCBA has been measured for continuity, shorts, excessive current draws, etc. by our HW team. As part of trying to debug this issue we have also measured the pins connected to the DRV8245 components, verifying the supply level and stability, the various DIAG, MODE, SR resistances.
As previously stated we have 10x of DRV8245 on each PCBA, naturally we tried with different PCBA boards to rule out single production errors, but they all behave the same.

With our current setup we are unfortunately not able to replace the DRV8245 compenents, an interesting test could have been to remove the DRV8245 from the EVM board and solder it directly to our board...

Again, i would like to thank you for the extended support. If you have more interesting things you think we should tests, please suggest so. 
However, i do get the feeling that we are nearing the end of the road in terms of what can be done from support perspective. 

Best regards, Seb.

Hi Sebastian,

Thank you for the update. Based on the EVM comparisons you made it appears like an HW issue with your PCBA like you mentioned. 

Sebastian Hoyer said:

With our current setup we are unfortunately not able to replace the DRV8245 compenents, an interesting test could have been to remove the DRV8245 from the EVM board and solder it directly to our board...

Alternate approach could be to but some DRV8245H in small quantity or request for samples and populate it in your PCBA. Were the devices in your PCBA procured from a distributor or TI direct? Thanks.

Regards, Murugavel

Hi,

Murugavel4637 said:

Alternate approach could be to but some DRV8245H in small quantity or request for samples and populate it in your PCBA. Were the devices in your PCBA procured from a distributor or TI direct? Thanks.

We have ordered some DRV8245H and will try to remove components from our PCBA and then solder/wire-up against the new components. 
I don't have the information as to where the components mounted on the PCBA was ordered from as this is done through a third-party EMS.

Best regards, Seb.

Hi Sebastian,

Sounds good. Thank you.

Regards, Murugavel