DRV10987: Fault code questions

Hi Marc,

Do you need assistance on this thread still? If not, please mark as resolved!

Thanks,
Aaron

Hello,

Thank you for your reply.  My problem is still present. After further investigations, here are my observations:

•  I periodically send speed command to the driver using i2c link. I also periodically read fault register, motor speed and motor current.

In some situations the i2c master detects an acknowledgement failure. It seems the driver is not responding to its address, it happens either on read or write access.

So to try to avoid that these i2c acknowledgement errors affect the speed commands sent to the driver, I changed the speed command to be sent by PWM instead of i2c.  In parallel, I also restart the i2c read access after 100ms if an acknowlegment is not received.

After this restart, I am once again able to read the registers, but the PWM speed command is not applied.  In fact, I can hear a speed drop in the motor and then it seems to enter its start up sequence.  Sometimes the motor is not even able to restart.

Some other observations I've noticed are:

• I notice strange behavior on the speed feedback (read though i2c), sometime I read 16383 (0x3FFF) when normally the speed should be between 3000 - 6000.
• Sometimes I read a MotorKt value of 2047 or 0, when for our application it is usually between 50 -70.

My observations often occur when decreasing from 100% to approximately 20% on speed command. I have tried to attenuate decceleration, but the problem still occurs.

Would you have some explanations for this behavior?

Thanks very much.

Marc,

Are you using the DRV10987EVM and GUI or your own customized board and MCU to send I2C commands? Can you check if you followed the I2C protocol instructions and the correct slave address as mentioned in the datasheet?

Regards,

Vishnu

Hello Vishnu,

I am using a custom board. Firstly I was using I2C commands to send speed command and read speed feedback, fault register and motor current. Now I am only using I2C to for register reading, speed commands are sent through PWM.

Most of the time, read accesses works as expected (no communication error and meaningful data). I followed datasheet instructions for my implementation.

Regards,

Hi Marc,

Vishnu will get you a reply on Monday as today is a TI Holiday.

Thanks,
Aaron

Marc,

You will have to convert the register data to motor electrical speed (Hz) using the below equation.

Regards,

Vishnu

Hi Vishnu,

I have been using this equation to convert raw data to speed so far. This doesn't explains speed jumps from [3000; 6000] range to 16383 value, neither inconsistent motorKt values.

I do periodic i2c accesses every 1 ms, Is there a period limit to not go below?

I also notice that spdCmdBuffer is sometimes greater than SpeedCmd. Being lower can be explain by AVS but I have not found explaination for my case. It it a normal behavior?

Regards,

Marc,

The value that you obtain after converting the raw data is the motor electrical speed in Hz. You mentioned 3000-6000 to be the range of motor speed but you didn't mention the units. If the unit is RPM then use the below equation to convert motor electrical speed in Hz to mechanical speed in RPM and vice versa.

Motor mechanical speed (RPM) = 60*Motor electrical speed (Hz)/Pole pairs.

SpdCmdBuffer is greater than SpeedCmd because of AVS. SpdCmdbufer is greater than SpdCmd because the device buffers the speed command value and limits the resulting output voltage so that it is greater than the BEMF voltage of the motor. 

Regards,

Vishnu

Hi Vishnu,

Thanks for your reply.

More test shows that VCC overvoltage protection (fault register = 0x2000) is active before each I2C communication lost (I what missing that because our software was clearing the fault before I can see it occured).

As explained in section 8.3.4 of the datasheet, DRV10987 stop driving the motor and protects itself when overvoltage protection occurs.

Could this explains why driver I2C communication is not responding?

Notice that less frequently, I get a fault register with 0x3FFF value.

As mentioned before, errors occurs when decreasing peed command from 100% to approximately 20%. Mechanical and inductive AVS are both enabled.

Are there cases where AVS is not able to keep VCC under Voc_f?

What are TI recommendations to avoid overvoltage during decceleration?

Best regard,

Marc,

You are right! Overvoltage fault can cause I2C communication failures because during overvoltage (Vcc>28V) device shuts down most of the internal blocks to protect the device. Can you check if you programmed the correct BEMF constant? Decelerating the motor slowly could help avoid voltage surges. Can you decrease the closed loop accelerate to 0.045 Vcc/s? Device uses the Closed loop accelerate value as closed loop decelerate so you should see the motor decelerate slowly.

Regards,

Vishnu

Vishnu,

Thank you for your reply.

I confirm that reducing closed loop accelerate avoid i2c communication error. Unfortunately this is not acceptable for my application.

Investigations showed a driver voltage difference between boards. So some board are closer to 28V than other, this explains why the problem is seen on some boards and not on others.

Slightly reducing Vcc resolved the problem. Nevertheless we still seen some i2c error, but are able to restart almost transparently.

Just a last question, can you tell me what is the impact of the temperature on Vov_r (overvoltage protection rising Vcc threshold)?

Regards,

Marc,

There will be some voltage tolerance on the overvoltage threshold due to process and temperature variation. Here's the range of Vov across variations.

Regards,

Vishnu