DRV8889-Q1: How to continuously detect OCP using DRV889

Hi Jonggyeon,

Thanks for your post.

JONGYEON BYEON said:

I use the option of CTRL4 to detect overcurrents.
0x0C3A, // [6] (RW) CTRL 4 was set to LOCK:011, EN_OL = 1, OCP_MODE=0, OTSD_MODE=1, and TW_REP=0.
And if the motor pin is shorted, read STATUS with SPI and B11= OCP
0X800 and AND detect short.

This strategy is fine for overcurrent detection. With OCP_MODE = 0 latched fault, when an OC was detected the outputs would be automatically disabled and a latched OCP fault will be reported along with nFAULT LOW. 

JONGYEON BYEON said:

It was confirmed that FAULT and OCP of FAULT Status are LATCHed to 1 when detected.

Understood.

JONGYEON BYEON said:

And I was able to send 0x0CBA and READ to confirm that FAULT and OCP became zero.

So you were writing to CTRL4 0xBA to invoke a CLR_FLT. A CLR_FLT would momentarily clear a latched fault and enable the driver outputs. However, if the fault is still existing - in this case an OC, a latched OCP would happen immediately after output current exceeded and remained  > IOCP for > tOCP. Essentially you were doing an auto retry instantly which may not be the right thing to do immediately after an OCP latched fault kicks in. 

JONGYEON BYEON said:

Do read STATUS with SPI and B11= OCP pins show 0 if there is a continuous short regardless of CLR_FLT if 1 disappears???

Whenever you send 0x0CBA via SPI you'd invoke a CLR_FLT and enable the driver by clearing the faults only to fault again assuming the condition persisted. STATUS OCP 1 and nFAULT = 0 would be present as soon as this latched fault is detected. It will be cleared only for a short moment as soon as CLR_FLT was set to 1 (auto cleared). 

JONGYEON BYEON said:

So would it be right for me to send CLR_FLT while keeping short, not to check B11= OCP, but to continuously check B11= OCP and send CLR_FLT if it's not short? I haven't tried this method yet.
I kept my short and kept sending CLR_FLT. Continuing

Technically, you must not send CLR_FLT while the short is persisting because another OCP would be detected within a few μs. If you'd set the OCP_MODE to 1, the DRV8889-Q1 would automatically retry after tretry about 4 ms. The below table in the datasheet describes the fault reactions and recovery suggestions. 

JONGYEON BYEON said:

However, I aim to stop the motor if the short circuit of the motor occurs and reset the motor if the short circuit of the motor is removed within 10 seconds.
So I want to keep the FAULT and OCP pins down to zero by sending 0x0CBA while keeping the short of the motor pin, but this doesn't seem to work properly. Isn't it the right way to check the state of the short by continuously sending CLR_FLT while keeping the short?

For this purpose you must change the strategy as follows. As soon as an OCP fault was detected either by detecting nFAULT = 0 and/or from reading STATUS register for OCP = 1 start a timer in the controller MCU and wait for 10s. After 10s expires, write to CTRL4 0xBA to perform a CLR_FLT. If the overcurrent condition was removed the driver would continue to operate from this point. However, if the overcurrent condition persisted nFAULT and OCP would latch again. You can repeat this cycle as many time as required. Thank you.

Regards, Murugavel  

Hello. First of all, I appreciate that you answered my question in detail.
You told me that if the OCP occurs with =0x01, the MCU will run the timer and send CLR_FLT after 10 seconds to check the OCP status, right?

However, my customer stops the motor when SHORT occurs and = OCP=0X01, so it's right up to this point.
However, after 10 seconds, I checked the condition of the motor again and told them not to start the initial operation if the OCP is 0X00, but to stop the motor if SHORT occurs and to start the initial operation at any time of 2 seconds 3 seconds 4 seconds if the short circuit of the motor is removed within 10 seconds. I was told to send a DTC code after 10 seconds.

Is there any other way??
I don't think I answered the part about what I said at the end.
If SHORT is removed without sending CLR_FLT, will the OCP pin be updated to 0X00? Of course, MotorIC won't work until CLR_FLT is sent!
If this is correct, I think I can keep checking OCP's STATUS while running a 10-second timer in the MCU when SHORT occurs, and then send CLR_FLT if it becomes 0X00. Is it impossible??

Hi Jonggyeon,

Thanks for the follow up.

JONGYEON BYEON said:

You told me that if the OCP occurs with =0x01, the MCU will run the timer and send CLR_FLT after 10 seconds to check the OCP status, right?

Yes correct. My assumption of the chain of events was as follows.

1. As an example I considered one of the output wires broke and short circuited a pair of coil connections.
2. OCP was detected, OCP bit 1b and nFAULT = LOW. Outputs were automatically disabled.
3. If the short circuit was momentary and was fixed withing 10 s by itself (let's say a moving vehicle hit a pot hole) or manually while testing OCP.
4. CLR_FLT issues after 10 s.
5. OCP bit 0b and nFAULT = HIGH, all outputs are normal.

JONGYEON BYEON said:

However, my customer stops the motor when SHORT occurs and = OCP=0X01, so it's right up to this point.

True.

JONGYEON BYEON said:

However, after 10 seconds, I checked the condition of the motor again and told them not to start the initial operation if the OCP is 0X00, but to stop the motor if SHORT occurs and to start the initial operation at any time of 2 seconds 3 seconds 4 seconds if the short circuit of the motor is removed within 10 seconds. I was told to send a DTC code after 10 seconds.

This is not how the OCP protection works in the DRV8889-Q1.

JONGYEON BYEON said:

If SHORT is removed without sending CLR_FLT, will the OCP pin be updated to 0X00? Of course, MotorIC won't work until CLR_FLT is sent!
If this is correct, I think I can keep checking OCP's STATUS while running a 10-second timer in the MCU when SHORT occurs, and then send CLR_FLT if it becomes 0X00.

After a short detection OCP will be latched to 1b. The DRV8889-Q1 does not automatically change OCP to 0b when the short condition is removed. This is how a latched setting for OCP behaves. The OCP bit can be cleared only with a CLR_FLT. In this latched mode, the only way to find out if a short is still there is to do a CLR_FLT to re-enable the outputs and see if OCP is detected again. 

There is another OCP mode, the auto retry mode selected by OCP_MODE = 1b in the CTRL4 register. In this mode you do not need to do anything with the MCU. The fault is cleated automatically after tRETRY which is 4 ms for this device. 

The chain of OCP or short circuit events would be as follows.

1. Short circuit happens.
2. OCP was detected. OCP bit 1b and nFAULT = LOW. Outputs were automatically disabled.
3. After tRETRY of 4 ms the DRV8889-Q1 automatically clears the fault, nFAULT = HIGH, FAULT and OCP bits are cleared 0b and the outputs goes active.
4. If the short circuit or OC condition persisted OCP will be detected again. This repeats indefinitely from the above step #2. Whenever the short circuit is removed this cycle will be exit and the device function normally.
5. If for some reason the device temperature increased during the repeated events #2 to #4, a TSD thermal shutdown protection will happen. All outputs would be disabled.
6. Depending on the OTSD_MODE bit setting in CTRL4 there are two possibilities.
   1. OTSD_MODE = 0b. This would be a latched fault OTS, TF and FAULT set 1b, nFAULT = LOW. It will not be cleared even after the device cools down, until a CLR_FLT is issued.
   2. OTSD_MODE = 1b. OTS, TF and FAULT set 1b, nFAULT = LOW. After the IC cools below the hysteresis temperature level the outputs would be enabled again, OTS, TF and FAULT reset 0b, nFAULT = HIGH and the cycle repeats from #2.
7. The above operation is a built-in auto retry feature in the DRV8889-Q1.

I hope this helps. Thank you.

Regards, Murugavel 

Once again, thank you for your answer.
Eventually, I sent CLR_FLT every second, and when it returns in 10 seconds, it continues to reset and CLR_FLT for 10 seconds in case of OCP and OL occurrence, and then if it's disabled, I'm not sure if it's going to work properly.

Can you answer additional questions in this post?
This is a temperature issue of DRV889.
I'm currently using OTSD_MODE as 1 and TW_REP as 0. According to the person in charge of the test, my step motor actuator currently doesn't work in high temperature and humid environment. The high temperature I'm talking about here probably goes up from zero to 90 degrees, is there a way to get rid of the temperature limit? Even if it's not working properly. The company next door that uses other company's BD63800 IC told me that they've lifted all the temperature conditions.

Hi Jongyeon,

JONGYEON BYEON said:

Eventually, I sent CLR_FLT every second, and when it returns in 10 seconds, it continues to reset and CLR_FLT for 10 seconds in case of OCP and OL occurrence, and then if it's disabled, I'm not sure if it's going to work properly.

That sound okay.

JONGYEON BYEON said:

I'm currently using OTSD_MODE as 1 and TW_REP as 0. According to the person in charge of the test, my step motor actuator currently doesn't work in high temperature and humid environment. The high temperature I'm talking about here probably goes up from zero to 90 degrees, is there a way to get rid of the temperature limit?

The OTSD threshold is hard-coded in the DRV8889-Q1 device and cannot be changed. The MIN specification is 150 °C. The DRV8889-Q1 should function at TA = 90 °C. Could you please share the schematic? What is the VM voltage and the set motor IFS full-scale current, and the SR setting used? We've verified the device to work as expected up to 150 °C.  

Regards, Murugavel 

Hi Jongyeon,

JONGYEON BYEON said:

This is my IC setting currently in use.
500PPS(1/8 4000PPS), SLEW 35V/us, TRQ_DAC 43.75%
The test voltage is 13.2V input, but since it goes through the DIO, the voltage delivered to the VM will actually be between 12.5V and 12.6V.

For the VREF pin, 5V is output from the MCU, 6.8kohm and 13kohm are voltage-divided, and about 3.3V is delivered.

Speaking of SLEW, is there a big difference in EMC performance between 10V and 35V? I know that the lower the figure, the better.

The settings look fine. Slew 35 V/us setting is mostly used in many applications and pass EMC.

JONGYEON BYEON said:

Is there a result of which frequency band is affected by the noise according to this option? We are preparing for an EMC test and are suffering from noise near the 100MHZ band. This is the CURRENT CE test.

See below CISPR-25 data we did using an DRV8889-Q1EVM. 

8267.DRV8889-Q1 CISPR-25 data.pdf

In the STRC (ripple control) decay mode the TOFF time for current regulation is variable based on the current target and motor BEMF. Usually lower frequency PWM vs. STDD (dynamic decay) fixed TOFF for current regulation. The PWM frequency tends to be higher perhaps even in the 100 kHz range.

Adding four capacitors to GND from each of the outputs AOUT1,2 and BOUT1,2 closer to the stepper motor connector on the PCB will help mitigate the switching EMI. Values could be 4.7 nF to 10 nF range sometimes higher if the motor harness has longer wires. Thank you.

Regards, Murugavel   

Hello, thank you for your response.
The answer and data you provided seem to be about the radiation noise of the motor, but the part I have a problem with is the current noise flowing through the harness as CE.
It is showing a problem in the 100 MHz band, not 100k.
The pin of the step motor is directly connected to the PCB substrate and is soldered
The length of the power harness is approximately 1.8 M.
When the capacitor of the motor output was added, it was confirmed that the motor radiation noise improved, but conversely, the CE test deteriorated.

I'm using Smart tune Dynamic Decay for stall detection. In this case, does it affect when changing TOFF value from default value to something else? If there is an impact, at our motor level of 4000pps, can we know which one is more suitable for noise, short or long?

Hi Jongyeon,

JONGYEON BYEON said:

The answer and data you provided seem to be about the radiation noise of the motor,

Understood. I just wanted to share all the test results we had for this product.

JONGYEON BYEON said:

The answer and data you provided seem to be about the radiation noise of the motor, but the part I have a problem with is the current noise flowing through the harness as CE.
It is showing a problem in the 100 MHz band, not 100k.

I understand. What I was suggesting, was, due to switching at 100 kHz the harmonics may be extending to higher frequency bands. 

JONGYEON BYEON said:

The pin of the step motor is directly connected to the PCB substrate and is soldered
The length of the power harness is approximately 1.8 M.

Having filters in the power supply to VM pin should help mitigate this. The EVM schematic shows a pi-filter we have in this path with L and Cs you could reference.

JONGYEON BYEON said:

I'm using Smart tune Dynamic Decay for stall detection. In this case, does it affect when changing TOFF value from default value to something else? If there is an impact, at our motor level of 4000pps, can we know which one is more suitable for noise, short or long?

For stall detection you must use STRC (ripple control) decay. This is what you have in your registers setting. In this decay mode TOFF settings are ignored and it is automatically controlled by the device. Thank you.

Regards, Murugavel 

Thank you for your answer.
Half a year ago, I didn't have a problem with the same motor and the same motor IC setting value.

Can there be an impact if the value delivered to VREF changes? I asked a question before, but I didn't get an answer.
As a result of checking the circuit, nothing else has been changed except for the voltage value (2.9V > 3.3V) and LIN IC transmitted to VREF due to the change in resistance.
The setting of the motor IC delivered by SPI is the same.

If I don't use SMART TUNE, TRQ_COUNT doesn't get to me? I only use TRQ_COUNT and I don't use FAULT related to stall. I'm just using it to do DRVOFF when TRQ COUNT goes below a certain level.
What are some options I can't use other than TOFF with the SMARTTUNE option??
If I don't use the BLANK option, I'm told that if I use 500ns, I follow the slew setting, does this have an impact too? Is it still unavailable if I use smart?

EMC measurements were made with the same IC setting in the past.
The difference is the value delivered to VREF + the current ce result value in PCB with different LIN IC. The motor was also manufactured in the same place, but I think there may be a deviation.

Hi Jongyeon,

JONGYEON BYEON said:

Can there be an impact if the value delivered to VREF changes? I asked a question before, but I didn't get an answer.
As a result of checking the circuit, nothing else has been changed except for the voltage value (2.9V > 3.3V)

Sorry this was missed. If VREF was changed from 2.9 V to 3.3 V but TRQ_DAC was used to set the same current there should be no impact. However if the TRQ_DAC was not changed the current setting would be higher which would change the switching pattern which may have an impact.

JONGYEON BYEON said:

If I don't use SMART TUNE, TRQ_COUNT doesn't get to me? I only use TRQ_COUNT and I don't use FAULT related to stall. I'm just using it to do DRVOFF when TRQ COUNT goes below a certain level.

TRQ_COUNT is available only in smart tune ripple control STRC decay mode. It does not work in all other decay modes.

JONGYEON BYEON said:

What are some options I can't use other than TOFF with the SMARTTUNE option??

The STRC decay is self controlled and does not provide any user option to change the way it works. A change in supply voltage VM would change the on and off time TON and TOFF. 

JONGYEON BYEON said:

EMC measurements were made with the same IC setting in the past.
The difference is the value delivered to VREF + the current ce result value in PCB with different LIN IC. The motor was also manufactured in the same place, but I think there may be a deviation.

Was the PCB changed or same PCB with different LIN IC? Also did the cable harness change compared to the past? 

Regards, Murugavel 

Thank you for your kind answer.
1. VREF values have changed and the remaining SPI settings are the same.
In the end, 2.9V + TRQ_DAC 43.75% and 3.3V + TRQ_DAC 43.75%.

2, 3. So if I use the START function, there are not many functions that I can control, right? Except for the torque limit, step, PPS, or diagnostic trouble, right?

4. MCU, DRV889, and LIN IC are in my PCB, but the placement of PCB elements changed as LIN IC changed. I was using the same cable harness.
The software will also be applied in the same way as the past results.
I wonder if the change in VREF to that extent affects the 50 to 100 MHz band to the extent that it changes the pattern shape. I'd rather be happy if it was solved by voltage division resistor or PWM because it's a VREF value problem.

Hi Jongyeon,

JONGYEON BYEON said:

1. VREF values have changed and the remaining SPI settings are the same.
In the end, 2.9V + TRQ_DAC 43.75% and 3.3V + TRQ_DAC 43.75%.

See below high level block diagram. VREF and TRQ_DAC ultimately scale the sine DAC output to the Itrip comparator for current regulation. The ultimate value would be the analog level that goes the -ve inputs of the Itrip comparators. 

JONGYEON BYEON said:

2, 3. So if I use the START function, there are not many functions that I can control, right? Except for the torque limit, step, PPS, or diagnostic trouble, right?

Please clarify if you were referring to the DRV8889-Q1EVM GUI START function. There are several other settings in the GUI other than the ones you mentioned. I'm not following here.

JONGYEON BYEON said:

4. MCU, DRV889, and LIN IC are in my PCB, but the placement of PCB elements changed as LIN IC changed. I was using the same cable harness.
The software will also be applied in the same way as the past results.
I wonder if the change in VREF to that extent affects the 50 to 100 MHz band to the extent that it changes the pattern shape. I'd rather be happy if it was solved by voltage division resistor or PWM because it's a VREF value problem.

Thanks for the details. Based on the internal architecture of the device it is hard to say convincingly that VREF change caused this problem. Nonetheless this would be an easy to check item with small modifications, correct? Thank you.

Regards, Murugavel  

Hello.
It's an easy way to do it, but since there is no  laboratory schedule in Korea at the moment, I thought we should prepare in advance to prepare for it.
As a result, it can be said that there was little EMCeffect from VREF pins.
However, the noise significantly decreased when the SLEEP pin was lowered to LOW, so it seems correct that it is related to DRV8889.

This is the difference when the nSleep pin is made Low and High. The motor is not running.

Also, I just removed the DVDD of 470nF, so when I opened the DVDD, I got the same result value as when I made the nSLEEP Low.
Is there a reason for using DVDD as 470nF? Is it for power stabilization or noise cancellation? Does it matter if a small value is included??
DVDD is known as a pull-up power source for DRVOFF pins and nSCS pins.

When I attached 470nF to 220pF, it worked tremendously, but the logic function malfunctioned, and when I attached 1nF, there was no malfunction for a short time, but I don't think I can use it. Is there any way to improve the noise caused by DVDD??
When I removed the DVDD of 470nF, there was less noise than when I went to sleep mode, as mentioned earlier.
Or should I disconnect the circuit of DVDD related parts such as drvoff pins or nSC pins and insert resistance in the middle??
I suspect a function related to DVDD is a problem, but when I lowered DVDD's 470nF, I found that there was a problem with the IC logic and it was not possible to clearly detect the fault.
What are the things related to DVDD?

Do you have any doubts?
It's hard because there are so many cases of charge pump, logic, DVDD..

Hi Jongyeon,

JONGYEON BYEON said:

As a result, it can be said that there was little EMCeffect from VREF pins.
However, the noise significantly decreased when the SLEEP pin was lowered to LOW, so it seems correct that it is related to DRV8889.

When nSLEEP is HIGH even when the motor is not running, the charge pump is active, the on-chip DVDD LDO is active, internal digital is active - internal digital has a 10 MHz digital clock for the digital blocks which is active when device is awake. While the device is awake, VREF based current regulation is active when outputs are enabled even when the STEP inputs are not present.   

JONGYEON BYEON said:

Also, I just removed the DVDD of 470nF, so when I opened the DVDD, I got the same result value as when I made the nSLEEP Low.
Is there a reason for using DVDD as 470nF? Is it for power stabilization or noise cancellation? Does it matter if a small value is included??
DVDD is known as a pull-up power source for DRVOFF pins and nSCS pins.

If proper DVDD supply is absent entire internal digital and charge pump will likely malfunction. This may be why you saw the same result as nSLEEP LOW with DVDD capacitor removed because the digital may have stopped working in this case. 

The DVDD LDO requires 470 nF for LDO regulator stability, hence our recommendation for this value, not lower or not higher. We cannot guarantee LDO functionality for a smaller value of the DVDD capacitor or capacitor removed. 

JONGYEON BYEON said:

Or should I disconnect the circuit of DVDD related parts such as drvoff pins or nSC pins and insert resistance in the middle??
I suspect a function related to DVDD is a problem, but when I lowered DVDD's 470nF, I found that there was a problem with the IC logic and it was not possible to clearly detect the fault.

The DVDD external load should be around 1 mA nominal and must not exceed 2 mA else the device may malfunction. Pull-up to DVDD with low current should be okay, please double check the values and make sure the loading is around 1 mA. Proper DVDD voltage is required for operation of the entire digital core of this driver. Thank you.

Regards, Murugavel   

Hello, thank you for your response.
As you can see from my circuit at the top, there is nothing connected except DVDD and nFault pin. When 470nF was lowered to a certain value (for example, 1nF or less), the noise decreased, but it was confirmed that it did not work properly.
We tried to remove both the capacitors between CPH and CPL and the capacitors between VCP and VM. However, the result was that only when we physically disconnected the VM pin to disable the DVDD, made nSleep Low, or removed the 470nF capacitor of the DVDD showed low noise levels in the 50-100 MHz range.
I've followed all the reference circuits and now it's not working out here so I'm trying to get out of this, is there any other information that can help me??? All pins are already following the reference.

Hi Jongyeon,

Sorry to hear you're till unable to identify a solution for EMC issues in your system. 

JONGYEON BYEON said:

As you can see from my circuit at the top, there is nothing connected except DVDD and nFault pin.

This is fine and is used by several applications that are currently shipping with no issues. 

JONGYEON BYEON said:

When 470nF was lowered to a certain value (for example, 1nF or less), the noise decreased, but it was confirmed that it did not work properly.

Noise decreased because the digital core may have stopped working. This may allude to a layout based issue as the source of the interference harmonics. 

JONGYEON BYEON said:

We tried to remove both the capacitors between CPH and CPL and the capacitors between VCP and VM. However, the result was that only when we physically disconnected the VM pin to disable the DVDD, made nSleep Low, or removed the 470nF capacitor of the DVDD showed low noise levels in the 50-100 MHz range.

If I understood correctly, removing CPH and CPL and VCP and VM capacitors did not make any change. This means charge pump was not the source of the interference. 

If you stopped the drivers internal digital functionality this interference is gone which means there is some sort of antenna effect. This points to some sort of board layout related issue. Was the thermal tab connected to GND? 

JONGYEON BYEON said:

I've followed all the reference circuits and now it's not working out here so I'm trying to get out of this, is there any other information that can help me??? All pins are already following the reference.

There are several products that are currently shipping since 2020 that passed EMC tests using the recommended capacitors and layout from TI. Some common options used for EMC mitigation were using capacitors up to 10 nF on outputs to GND, using pi filter for VM power supply as in our EVMs - see below, and using a ferrite bead in series with the capacitor leg from VCP to VM connection for cases were charge pump was the source of EMC. 

How is the EMC spectrum looking, 1) when the motor is disconnected from the PCB and 2) when the motor is connected to the PCB with short wires? Thank you.

Regards, Murugavel