DRV8832: FAULTn refuses to de-assert

Hi Tim,

Thank you for posting to the Motor Drives forum.

Have you taken a look at the nFAULT signal? If you have, can you send a scope shot showing IN1, IN2, and nFAULT? I want to confirm that this is an OCP event being triggered.

Did you attached a picture? I see that there is something attached but I cannot see it. Can you resend it?

Can you provide the part of your schematic showing the driver?

Hi Pablo,

I have very limited scope facilities - a single channel portable Velleman (I no longer have access to lab facilities)
- what in particular do you need to see?
IN1 and IN2 will be driven by the logic gates FWD/REV, then I make the motor stall (by hand) and the gates then asset HIGH both IN1/IN2

My attachment was the schematic - I'll try it again here...

Hi Tim,

I would like to see the nFAULT pin when you stall the motor. In the meantime, I will look through your schematic to see if there is anything that could cause the nFAULT to not de-assert. Expect a reply from me by 8/26.

Thanks Pablo, I've ordered a 4-ch Picoscope, it should be here in a day or so...

every blessing
Tim

Hi Tim,

I would like to clear some confusion I have. Is your main concern that the DRV8832 is not de-asserting the nFAULT without having to power cycle VCC after stalling the motor? Is my assumption correct?

In the case of the DRV8832, the only way to de-assert the FAULT is to power cycle the VCC as specified in Table 2 of the datasheet. Also looking through your schematic, it looks like both IN1 and IN2 become high when nFAULT is driven low (a fault occurs). I am assuming you are trying to activate the outputs by setting both Inputs HIGH. However, this method will not automatically de-assert the nFAULT and enable the outputs. 

If your goal is to have a way for the driver to self-recover after a fault (in this case an OCP fault when stalling the motor) without the need to power cycle VCC, then your current solution might not work. 

Let me do some research to try to figure out if there is a way to self-recover from a fault using your current design. Expect a reply from me by 8/27 US time. 

Dear Pablo,

My design goal was to follow the data sheet section 7.3.5 that on a stall condition FAULTn would be driven low - Quote "the operation of the motor driver will continue" so I use the FAULTn = LOW to drive the IN1 and IN2 HIGH to BRAKE the motor and quote again " The current limit fault condition is self-clearing and will be released when the abnormal load (stall condition) is removed" and so return the IN1 and IN2 to their previous state to continue the motor operation after the FAULTn is released.

If this is not a correct procedure then I'm am surprised.

My scope hasn't arrived yet.

every blessing
Tim

Hi Tim,

I think fundamentally you are confusing current limit fault with an overcurrent protection fault. I know that they sound similar and the description in the datasheet might not be perfect. However, there is a difference between the two types of faults. I suggest reading this FAQ to learn about the difference between the two. In general, current limit uses the current sensing circuitry (Rsense) to monitor the current through the load and begins to regulate the output current when the motor current exceeds the limit set by the RSENSE resistor. In your case, Rsense=0.91Ω and the limit is set to 200mV/0.91Ω=220mA (equation 1 on datasheet). On the other hand, OCP is independent of the current limit circuitry (Rsense) and is triggered when the current through the FETs is higher than 1.3A  min for longer than 2µs. There can be three cases that can occur:

1. IOUT < 220mA
   1. No OCP or current limit fault is triggered. Motor is under normal operation.

2. 220mA < IOUT < 1.3A
   1. Current limit fault is triggered but no OCP is triggered. This case happens mainly during motor start-up or stalling. The fault will clear itself when the motor current drops below 220mA. However, in the case that the start-up or stall current of the motor is above 1.3A, then OCP fault will be triggered and the fault will not self-clear. VCC has to be cycled to remove the Fault.
3. IOUT>1.3A
   1. OCP is triggered and nFAULT is latched LOW. VCC has to be power cycle to unlatch nFAULT and re-activate the outputs.

Once you get the scope, I would like to take a look at the nFAULT signal and voltage at SENSE pin to see what fault is being triggered (either current limit or OCP).

Hi Pablo,

With respect  I don't think I am confusing OCP and current limit via Rsense. Because FAULTn is refusing to reset after a normal stall I then begin to wonder if OCP plays a part. The Picoscope arrives tomorrow via UPS... so by the time you get to work Friday and on your second "coffee" (assuming you're in the US, I may have some traces for you to see:-)

I certainly hope I am not going to see currents over 1.3A in this relatively small motor, see attached curves (PDF hopefully attached).

Really appreciate all your help, which is why I'm investing in the Picoscope.

every blessing
Tim

GW370 3V 3RPM curves.pdf

Tim,

Thank you for sharing the torque curves. I am looking forward to seeing the scope shots.

Hi Pablo,

The 'scope arrived a bit late in the day... so I'll spend the weekend trying to get you some decent traces for Monday,

every blessing
Tim

VILIM across RISEN.docx

Tim,

That sounds good. I am looking forward to seeing the traces. I'm confident that the scope shots will help us find the root cause.

Hope you had a good weekend Pablo? Mine was busy with scopes and wave-forms.

Please see attached pdf file of descriptions and traces...

Standing by to perform and more tests.

every blessing
Tim

4263.FAULTn not de-asserting.pdf

Hi Tim,

My weekend was busy as well. Thank you for providing such detailed test report I appreciate it. I've looked though your report and I will answer a few of your question here:

1. The motor reversal generates high currents but these seem to be controlled by the DRV8832 PWM(?) and stay within any OCP trip levels, so no FAULTn assertion?

1. If you do the calculation, when the motor switches direction, the Isense value is 900mV which will be a current value of around 1.6A (0.9V/0.56Ω). The datasheet states a minimum OCP trip value of 1.3V  and maximum value of 3A. In some cases, when the current is on the lower limit value (which is the case here), OCP might not be triggered and instead the current is being regulated by the driver's current limit circuitry. I believe this is what's happening in your case.

You provided a lot of information which is good. I will take some more time to keep reviewing the data and give you a more concrete root cause. Expect a reply from me either later today or by noon US central time. 

Thanks Pablo,

I’ve asked my motor supplier to send me curves on a less powerful motor, about 2/3rd the torque. This may help with the current spikes but not sure about the FAULTn signal.... I’m trusting you can search out the issue.

every blessing
Tim

Hi Tim,

Here are some of my comments regarding your report:

• I'm not 100% sure, based on the scope shots, if an OCP fault is really happening when you stall the motor. Do you have the capability to use cursors to measure the time delta between the region marked by the black lines shown below? It looks to me that the motor begins to stall when the Isense voltage begins to rise to ~200mV. This device has a typical OCP deglitch time of around 2µs. If the time delta between this region is close to 2µs, this will give me more confidence that an OCP fault in indeed being triggered. 

• I'm very puzzled as to why nFAULT is dropping low right before starting up the motor (like you show in figure 4). What are you using for the main power supply? A DC battery or a bench power supply? My main theory for this phenomena is that there might be some part of your circuit drawing some significant amount of current at that point which surpasses the current limit set by you power supply and causing the voltage to drop momentarily. This might cause an under-voltage fault which self-clears when the supply voltage goes back to nominal value. I will research this more because this event is very strange. I'll keep you updated on what I find.

Here is some of my theories as to what could be causing the nFAULT to not de-assert after the stall. I also provided a few tests you can do to verify the validity of my theories:

• OCP could simply be triggered when you stall the motor. But like I said before, I'm not convinced this is what's happening based on the scopes your provided. Knowing the time delta between the region I asked you to measure in my first bullet point will further solidify this theory. 
• The high current that occurs when reversing the motors (900mV) could be causing the internal logic of the driver to malfunction. Even though it is not mentioned in the datasheet for this part, TI strongly recommends that the ISENSE pin voltage is less than 800mV to ensure driver operates properly. One easy way to test this theory is to use a lower Rsense, let's say around a 0.25Ω resistor, and repeat the same experiment. If the same results are observed, then it will disprove this theory.
• Your current design using the SN74LVC to force IN1 and IN2 to be HIGH when nFAULT drops low might be clashing with the fault logic of the device. In all fault events, with the exception of current limit, the H-bridge FETs are disabled (high-Z state). When you force the H-bridge into BRAKE mode while the fault logic of the driver is trying to disable the outputs, this might cause some internal coalition and making the internal logic unable to clear the fault (when a non-OCP fault occurs). One way to test this theory is by repeating the experiment but not changing the states of the INx signals when nFAULT drops low. If nFAULT clears itself afterwards, the BINGO! this will solve your problem.
• The motor you are using, specially if it is an old motor or has some manufacturing defects, could be causing an internal short of some sort. Have you used more than one motor when you ran the experiment? Try running the experiment again with different motors (either of the same motor or similar motors to the one you used originally in your experiment).

I apologize for all the homework I just assigned to you but I strongly believe it is imperative that we validate each of these theories in order to find the root cause. Please let me know if you have any questions about anything I mentioned in this reply. 

Hey Pablo, thank you for the setting of the homework! I work from home these past 10 years so all work is home work :-)

The motors I have are new, from the factory but do have some other lower power motors, also new. It seems then a fine balance between the torque required to drive the motor and the torque generated when stalled. So I have ordered another motor closer to the target of 4 - 8 Kg.cm to open/close the door. I'll try all the other suggestions too over the next few days, hopefully before your Labour Day.

Regarding the traces from my Picoscope - I wonder if you have the free software from them, I could send you the output file and you can search them to your hearts content etc...
Any of the Picoscope 2000 to 6000 series use the same software

'Talk' again soon,
every blessing
tim

Hi Tim,

I will try to get the software to view the scope files. 

Hi Pablo, Friday at last......

I have reviewed and answered all your homework points... and I think your BINGO! assertion is the one......

IN1 and IN2 cannot be set in BRAKE mode (HIGH) in conjunction with FAULTn being asserted, which is my "Design 2". A previous iteration "Design 1" would invert the current states of INxx when driving the motor at STALL, so this just constantly reversed the motor direction and consequently kept the current driving the motor back and forth - no good for my power consumption, but at least FAULTn would assert and de-assert correctly.

So "Design 2 thought it should BRAKE the motor, thus eliminating the current drain... but as a consequence it seems we cannot do this on the falling FAULTn signal. This is an undocumented "clashing with the fault logic" idea of yours.

So "Design 3" in back on the drawing board (well at least a TINA Simulation!). Some advice on how to BRAKE the motor would be useful...
 - using LOGIC, rather than a micro-controller - (that will be "Design xx" and an IoT one - if the current drain can be kept below the ten's of microamps).

Homework_Pablo@TI.pdfThe Picoscope traces are available on my BOX link, if you'd like to view them:
every blessing,
Tim

Hi Tim,

Thank you for the information.

I'm glad that we found the root cause. Now it's a matter of finding ways to solve this issue.

I looked through your report and here are some of my comments:

• I think I found an explanation for the sporadic nFAULT drops. This device goes to a low power sleep mode when both IN1 and IN2 are low for a certain amount of time. The device is pulled out of the low power sleep mode when either of the INx signals is HIGH. However, when the device is exiting sleep mode, nFAULT is pulled low for a brief moment (this is described in section 7.3.2 in the datasheet). If you look closely at the waveform you attached in the previous report you sent (waveform is attached below), the device goes to sleep mode when both INx signals are low but nFAULT is asserted when the device is pulled out of sleep mode.
  • 
• My main theory as to why nFAULT is staying low when placing device in BREAK mode is that the INx signals are going high very quickly after nFAULT drops which is violating some internal logic timing. A good quick experiment you can try doing is to add some timing delay to the signal that is changing states. For example, if IN1 is "1" and IN2 is "0" and after the stall happens and both IN1 and IN2 are "1", add the delay on IN2. You can add delay by adding either a capacitor on the signal line or adding some inverter gates in series with the signal trace. If you know other more efficient and easy ways to add delay, feel free to use those methods.
• Is there a specific reason why you want to place device to BRAKE mode when stalling? I know you mentioned it is to save power but if your main goal is low power consumption, the better solution would be to bring the device to coast or sleep state. The device will go into a low power sleep mode after both INx signals are LOW for a certain amount of time. The one main issue with this solution is that when the device is pulled out of sleep mode, the nFAULT signal is pulled low momentarily which is going to  pull both INx signals LOW (because of logic gates) which puts the device back into sleep mode. This creates an endless repeating cycle where the device is constantly put to sleep and awaken. However, if you can find a way to NOT make the device go back to sleep when the device is being awaken, this solution would be ideal for low power consumption. Using a micro-controller would help fix the problem.

Have a great labour day weekend and I am looking forward to your response.

Hey Pablo,

Here in the UK we don't have a labour day....our holiday was last weekend.

Yes you're right about the FAULTn signal exiting sleep mode, I had forgotten that.

I will try to slug one of the INx signal somehow and let you know.

I'm going to have to respin the design anyway so I will look at ways to stop the motor on a stall, "reverse and try again" for example - a one-shot should help.

Yes a micro can be reprogrammed easily but the logic way is quicker to implement at this stage.

Enjoy your long weekend, every blessing
Tim

Hi, Tim,

Do let us know how your experiment works out!

Have a great weekend.

Dear Pablo (and Don),

Hope Labour Day was peaceful for you - some parts there are not so peaceful :-(

I managed to slug IN1 and IN2 (with a 47uF cap) to give a 600us delay after FAULTn asserts - but no differences detected - it still fails to de-assert. See attachment.

Should I try for more delay - eg double the 47uF cap? Somehow I don't think so. It seems that the OCP logic is confused by the rapid assertion of a BRAKE condition. I will avoid BRAKE on the next re-spin.

I'm also considering using a buck-boost TPS63031 to drive and isolate the DRV8832 in the case of a OCP triggered FAULTn (TPS63031 has an enable pin which can be activated via a push button should the JAM result in a stuck FAULTn).
-do you think it viable?

every blessing
Tim

FAULTYn! Delays on IN1 and IN2.pdf

Hi Tim,

I would say go ahead and try to increase the delay. If you see the same results then we can more confidently rule this out as a solution. 

This could be a viable solution. The concern I have is whether the TPS63031 can source the necessary current during start-up or stall. The datasheet states that the maximum average current in the switches is limited to 1-A. Based on the scope shots you sent previously, the spikes in Isense were around 900mV peak across Rsense when the motor is reversed. You were using 0.56Ω for Rsense which means the current was peaking at around 1.6-A for a brief moment. I suggest posting to the power management forum and asking if the device can handle this current transient.

Sorry for delay Pablo - I was doing some field trials on my door opener and your DRV8832 (which were successful, but no motor stalling)

So I tried double, 2 x 47uF, no change then added a 330uF cap to the 2 x 47uF (total 424uF) - still no change to FAULTn.

Then I caused one of the INx signals to fall by connecting a discharged 330uF in it's HIGH state - this released FAULTn !! - see last trace of the attached.

every blessing,
Tim

More delays added.pdf

Tim,

This is very interesting. It seems like the internal logic does not like it when INx signals are forced HIGH after nFAULT drops low. I am definitely going to research this issue more and try to understand what exactly is happening internally. It will take me a few days to do my research but I'll let you know what I find out. Expect a reply from me by Wednesday of next week or earlier.

Hi Tim,

Unfortunately I don't have much information to share with you at the moment. 

For the sake of bringing this thread to a conclusion, I will close the thread for now. If you need any further assistance, feel free to reply to this thread. If the thread gets locked, you can post a new thread by clicking on the "Ask a related question" button.

That's a disappointment Pablo, it seems then we should avoid using the BRAKE (IN1=IN2=HIGH)  generated from a FAULT assertion, due to an unknown race condition within the DRV8832 logic..

I am doing a respin  f the PCB, redesigning the logic anyway, and so I will go back to reversing the IN1 and IN2 on a FAULT condition, as this was working... but adding a short delay between reversals (if it's still jammed). Also now considering the TPS22918 5.5-V, 2-A LOAD SWITCH to cope with any unexpected OCP condition.

Do you think a common mode choke in the OUT1 and OUT2 signals to the motor would reduce spikes or would that compound the mystery surrounding the FAULT signal?

every blessing
Tim

Tim,

I personally have not seen common-mode chokes used for motor voltage pike reduction. Using varistors or TVS diodes at the motor outputs are the most common ways I have seen of reducing motor voltage spikes. If you have used common-mode chokes for this purpose in the past and has worked for you, then I see no issue using them. The common-mode chokes should not cause any false triggers of the nFAULT signal.

By the way, if you have not looked through the motor drivers product page on ti.com, we have many useful technical documents here that may help you in your design. The "Best Practices for Board Layout of Motor Drivers" application report provides useful tips for PCB layout.