DRV11873: Cut-out at certain duty cycles - why?

Chris,

Can you check the FG frequency? It's possible you're hitting a false lock as described in: http://www.ti.com/lit/an/slva778/slva778.pdf

Thanks,

Brian

Brian- Excellent, thank you, this seems promising. I'll measure and report back.

Brian-

   I've confirmed that I am receiving false rotor lock occurrences, but unfortunately dithering by 1% around this duty cycle (at a 1s interval) does not solve the problem, nor does 2%, and at 2%, the motor pitch change is too irritating to be a solution anyway. I'm measuring frequency with the host MCU, and at this duty cycle, with dithering, I'm measuring an RPM of 7065-7290. Or 471 - 486Hz. Does this information shed any light on what the problem may be?

-Chris

Chris,

I don't believe I encountered this behavior. Given that you are ~4x the fundamental frequency where the false lock occurs I would have expected varying the PWM by something like 0.05% would have been sufficient to move away from the false lock.

How invested in DRV11873 are you? A newer 12V device in our products in DRV10975, however, it does require I2C interface to configure the motor controller.

I'll think about it a little more and see if I can find any reason that you are having to vary the PWM so much.

Thanks,
Brian

Brian-

    We aren't totally committed, but we are pretty invested at this point. Is there any data I can collect that might help you troubleshoot this problem?

    Are there other benefits to moving to the DRV10975? Efficiency, etc? I really don't want to move to a new part right before we move in to production, but if this is going to be an issue moving forward and there are  other compelling reasons to move to this new part, it may be worth it.

    Right now my workaround is to both dither around a set point and increment duty cycle if a lock is received (interrupt input). Duty cycle has to increase by 3% (from 82 to 85) to get out of the false lock region. Certainly seems like a lot given the documentation. 

    Rapid feedback/help appreciated.

-Chris

Chris,

I'm not sure what more you can collect. It's obvious that the false lock detect is getting triggered.

I agree that your solution is pretty complicated. I looked at characterization data and it looks like the variation of the oscillator isn't as high as stated in the errata document. It's more in the range of 5%. That being said your idea to shift away from the trouble frequency is good, but the exact location will differ across parts.

DRV10975 does have lower RDSon so the efficiency will be better. Drawbacks are that it is a larger package, I2C tuning and higher cost.

I'll brainstorm with the rest of the team to see if there is anything else that we can try.

Thanks,

Brian

Brian-

     Are there (potentially) additional efficiency benefits due to the ability to adjust motor parameters? Or do the motor parameters really only have a significant impact during transients (startup/shutdown)? Can you roughly ballpark the total efficiency benefit? 5-10% range? 20-30% range?

     What has been done on the 10975 to ensure that the rotor lock issue of the 11873 won't occur again? 

Thanks,

Chris

Chris,

RDSon is 0.25 ohms in DRV10975 opposed to 0.45 ohms in DRV11873. So power dissipation and losses in the FETs are almost cut in half.

Additionally DRV10975 is a sinusoidal drive so the acoustics are better and we don't loose the efficiency during the window opening.

The logic in DRV10975 was completely redesigned and synchronization logic was included that eliminates the the false lock seen in DRV11873. DRV10975 has shipped millions of devices without a report of this false lock.

Let me know if there is something else I can do to help out.

Thanks,

Brian

Brian-

    Can you clarify your comment regarding oscillator variation? The app note indicates +/-30%, is it actually closer to +/-5%? This is a pretty big difference, so please confirm. We can (obviously) design around a 10% RPM window much more easily than a 60% window.

-Chris

Brian-

    In addition to the above, we are pursuing the DRV10975 in parallel. I am having an issue with an abnormal BEMF error report, even though operation (appears) to be good. To keep things clean, I've made a new post. Please review ASAP and let me know what I am missing:

Thanks,

Chris

Chris,

I confirmed that current production test is checking the oscillator at +/-11%, however, this is a room temp. All characterization data I've looked at shows better than 11% even across temperature. Since its not a specified item I can't guarantee that the test limits won't change.

Thanks,

Brian

Brian-

Thanks, does this 11% include the VCC voltage range? Or is this just part tolerance?

-Chris

Also, if you have any feedback regarding the DRV10975 issue I am having, I'd appreciate the help.

Sounds good, the DRV10975 seems like the way to go now that we appear to be past the tuning hurdle!