DRV8846: VINT not initializing

Hi Kristopher,

Thanks for posting in this forum. Thanks for considering the DRV8846. While the DRV8846 is a good stepper driver we have released new generation stepper drivers in the recent few years. Devices such as DRV8436, DRV8424, DRV8434, DRV8452 are newer GPIO controlled stepper drivers as well as DRV8434S, DRV8452S, DRV8462 are feature rich devices with SPI interface based register controlled operation.

Kristopher Redford said:

In our application we are trying to use the DRV8846RGER Motor driver, however when we power the device on, we leave nENBL floating(Internal pull-down) and drive nSLEEP high from our controller, however VINT stays at 0V, and since we are driving VREF with VINT, VREF is also 0V, we have tried driving VREF separately from a 3.3V supply, however we still do not observe anything on the output of the motor driver. 

Based on the schematic VREF = VINT = 3.3 V TYP. , Rsense = 4.3 Ω, Torque DAC is 50 % both I0 and I1 floating / Hi-Z. This puts the IFS at 58 mA. You mentioned motor current is limited to < 125 mA. Assuming you'd want it closer to 125 mA you may have to set Torque DAC to 100 %. I0 = I1 = GND. 

VINT must be 3.3 V in order for the internal blocks of the device to function. VINT = 0 V points to issues. VINT must be 3.3 V under the two highlighted conditions in the below table.

VINT is disabled with an under voltage condition UVLO. The nFAULT pin is driven low during an undervoltage condition and is released after operation has resumed.  Based on the schematic VM = 12 V, I do not anticipate an UVLO. Could you please verify nFAULT is not driven low?

M0 = M1 = GND suggests Full-step setting, TOFF = 20 μs.

I do not see anything unusual in your schematic. Could you please check for a potential short to GND on the VINT / VREF trace? Thank you.

Regards, Murugavel 

Hello Murugavel, we actually selected this device specifically for its Direction and Clock control, as we do not have an SPI interface available in the current design, but thank you for the consideration, if we end up changing our host controller we might go with such an approach.

From our testing there were no shorts measured on the board and all nets on the part have been continuity tested, I couldn't find any reason that the VINT would still be 0V so we ended up replacing one the three instances of this part we had on the board since they all had the same issue. This resulted in VINT initializing on power up. I would note that the connection from Vint to Vref had already been cut and Vref was provided by an external supply.

I suspect that the part was damaged on power up somehow seeing as three devices all failed at once, or that there may have been a poor connection to the PCB due to heavy thermal sinking in the layout design on the output side of the part. Thank you for your time in responding to my question!