DRV8434SEVM: Stall Detection + Dir over SPI Behaving Strangely

Hello Roi,

We meet again! 

1. I've never seen this happen. Writing 0x18 should suffice. Matter of fact I had an DRV8434SEVM running a stepper for another test. I verified with the GUI, we never write to those reserved bits.

2. I also verified the DIR bit operation in CTRL3 (address 0x05) while SPI_DIR = 1 with the same DRV8434SEVM running a stepper. Note the SPI, DIR and STEP register is CTRL2 (address 0x05 same as DRV8434S but the label is CTRL2) in the DRV8462. 

Stall threshold register 0x08 = 3 seems to be a very low value. Did you do a LEARN on the stepper or used manual threshold mode? What was the setting for upper 4-bits of the threshold and other settings in the CTRL7 (0x09) register? What was the torque count when the motor was running at target velocity with no stall?

Regards, Murugavel

Hi Murugavel,

The pleasure is mine!

Regarding your questions:

• I am doing manual threshold - but the 3 threshold worked on 8462 just fine
• We did not touch the 4 upper bits - so I suppose they are default
• I am consistently receiving a TRQ count of 0 when reading over SPI - I have read a different register (0x03) to check SPI and it is the value I wrote to it (0xC0) so SDO is OK.

I would like to point out that I am still receiving an SPI issue both on 0x00 register and on every SPI write - but the SPI obviously does work.

Thanks!

Roi

Hi Roi,

Thanks for the update. You said "I am consistently receiving a TRQ count of 0 when reading over SPI". So if you program the RSVD bits did that change? What is the read back value of the reserved bits in the DRV8434S. What is the torque count read in the DRV8462 while not stalling?

Regarding SPI error can you share a capture of couple of transactions? Are they compliant the below diagram? SCLK must idle LOW and nSCS must idle high. Clock phase and polarity must be compliant. 

Regards, Murugavel

Hi!

SPI is set as follows - worked the same (or actually better :( ) on the 8462:

• Regular CS - so driven low on usage as you said
• MSB first
• SPI mode 1 - CLK active high, tracking edge
• 5000000 clock speed - have tried different speeds as well to no avail

As said - other data is written and read OK albeit the SPI fault bit being high.

In addition - is there perhaps a flowchart like on the 8462 to try the stall learn process on 8434? I had tried something like the chart in the 8462 datasheet, to no avail.

Thanks!

Roi

Hello,

I have attached a flow chart for the DRV8889-Q1 device which is similar but lower resolution for stall detect. This flow chart could be used as a reference.

8272.DRV8889Q1_Stall_Detect_Flowchart.pdf

Regards, Murugavel

Hi,
This is the process I attempted - to my chagrin it is not working :( 

Hello,

Today is a US holiday.  Expect a response tomorrow.

Regards,

Ryan

I am aware, thanks!

Adding for tomorrow:

I have FINALLY been able to cause it to work by removing ALL logging from the controller chip. It must have added a weird overhead.

 My problem is now a timing + parameter game between:

• SPI speed - have tried 1Mbit to 20Mbit
• Sleep between steps - have tried 10 us up to 1 ms
• Microsteps - have tried nearly all options
• Threshold - have tries from 3 to 200

I am assuming the register params are motor dependent and therefore I will simply need to check these myself - but is there a suggested optimum for the timings?

Thanks!

Roi

Hi Roi,

Thank you for the update. I'm glad you were able to get it to work. As far as the timing and parameters setting while most depend on the application like you mentioned there are boundaries for certain specifications. I have added my comments to the bullet points you posted. I hope this helps. Please close this thread by clicking on "Resolved". Thanks.

• SPI speed - have tried 1Mbit to 20Mbit >> tCLK minimum period specification from the datasheet is 100 ns. Maximum SCLK is 10 MHz. 20 Mbit is out of spec.
• Sleep between steps - have tried 10 us up to 1 ms >> Depending on the application you can choose to sleep between steps. However two behaviors of the device you want to consider. 1) During sleep the H-bridge will be in Hi-Z meaning stepper motor terminals floating and only detent torque will be present. and 2) Waking up from sleep, i.e. soon after nSLEEP = 1 the device takes up to 1.2 ms for the digital and the drive circuits to be active and fully ready for communication and driving. Must account for the wake up time every time the device wakes up from sleep. Note 1.2 ms is the worst case wake up time under the specified operating conditions of the device. 
• Microsteps - have tried nearly all options >> Yes, this can be changed on the fly.
• Threshold - have tries from 3 to 200 >> A thumb rule for mechanically rigid motor stall situations would be to observe the torque count when the motor is running normally at the target velocity and set the threshold to be ~ 50 % of that value. This would be a good starting point from where you could fine tune if needed.

Regards, Murugavel