DRV8711 datasheet (home position and TBLANK)

Thank you for your reply! For the 2nd question, I can show you initialization sequence (to avoid a mistake inside software, I shorted STEP signal to GND by wire):
1) After power up, nSLEEP signal goes to high.
2) After 1.2 ms delay, RESET signal goes to high.
3) After 1.2 ms delay, RESET signal goes to low
4) After 1.2 ms delay, nSLEEP signal goes to low
5) Chip is programmed:
a. Register 1: 0x1E9
b. Register 2: 0x089
c. Register 3: 0x07D
d. Register 4: 0x50B
e. Register 6: 0x0F3
f. Register 0: 0xD8B
6) After that nSLEEP goes to high. At this moment 2 windings should be switched on, but only one is switched on.

Hi,
Thank you very much! But now I have some new questions about home position (question 3 is most important for me).
1) Is this effect stable (exactly one step always when waking up after SPI enable)?
2) What is the direction of this extra step?
3) During normal work, in some situations I am using SLEEP signal to remove power from the motor after motor stopping (STEP signal has LOW level and has 0 edges during sleep state). And it is very important to have the same state of windings after wakeup (SW check optical encoder position after waking up, but it affects motor position only if it gives more than 4 half-steps position mistake). Which actions should be avoided to have no this extra step in normal work in sleep state? Is it possible to access / modify registers in sleep state during normal work? Which registers? (for example, can I reprogram current value during sleep state?)

Thank you for your answers

Hi Aleksey

We will check from design side on the details of the issue and get back later.

During nSLEEP, all the SPI and internal registers are accessable and functional.

Could you use the enable/disable via SPI instead of using nSLEEP to release the motor?

Best regards,

Using SPI instead of SLEEP is possible, but it is not easy due to some reasons. Most important of them are:

1) Now we are in mass production stage and we are replacing IC from A4989 to DRV8711. And it is important to have the same SW for both chips because software should work on both board revisions.

2) SPI access is impossible from interrupts. So, we will need to rebuild SW architecture in case if we will use SPI instead of SLEEP signal.

But in any case final decision will depend on your answers.

Hi Aleksey,

Thank of your explain. I think using SLEEP to stop and release the motor in a loading condition or even without load but not stop at a full step point, will alway cause a shaking when wake/enable again.

One way is add an cheap MSP430 for a SPI configuration and translation of MS, ENABLE and decay parameters inputs, so we can keep the MCU/firmware just the same as before. Also we can do upgrade of the driving functions easily in future.

Best regards,

Hi,

Thank you! Shaking is handled by software using optical encoder. We need just to restore windings after waking up at the same state as it was before sleeping (in other words need to keep indexer state). In this case motor shaft after shaking will be finished, can be moved only to 8, 16, 24, 32 (and so on) half steps.

we just need to know is it possible to save indexer state using sleep signal or not?

If yes, we need to know which actions should be avoided during sleep condition to keep indexer state (it is ok for us for example to avoid spi communication during sleep, but we need to be sure - will it save indexer state or not). If not, we will revise sw for using spi programming when need to sleep and wakeup. But the second way is not good for us due to will take additional developing time.

In other words. During our initialization procedure we can see an extra step is performed without any commands from our software. How to avoid this extra step in operatibg state when manipulating sleep sifnal? Which action forces this extra step?

Thank you for understanding.

Thank you for this bad news.
In this case we will revise SW for using ENBL bit in CTRL register to release the motor. But before doing this I need to be sure in success. So, now I have new question. If nSLEEP signal will be always passive (HIGH) and I will release motor power by programming ENBL bit in CTRL register to 0, will be indexer state unchanged after waking up by programming 1 to ENBL bit back?
If no, is there any other way to release motor power without affecting indexer state?

Thanks a lot!
I will try this week. But I think that TI should include this information to datasheet.
Page 14 "This state is entered at power up or application of RESETn.". I think "nSLEEP" should be added here. Also nSLEEP affecting to home position should be present here.
Page 24 (section 7.4.1) has information about resetting indexer by RESET pin, but have no information about resetting by nSLEEP pin.

In any case thanks a lot for your great help!

Hi Aleksey,

Thank you! You are right. We are in pipeline of lots of datasheets updating process, will add this to the list.

Best regards,

Hi,
I have one additional question on the subject.

In case of overtemperature it releases motor and asserts FAULT signal.

Does indexer and STEP input works in this state (in FAULT state)? In other words: will be indexer state predictable when temperature will became safety again or not (in case if STEP pulses can be still present during FAULT condition)?

Depending on this question I will need to sample FAULT pin state always or can sample it only after stop in case of stall detected by optical encoder.

Thank you.

Hi Aleksey,

It is almost not possible to test on the DRV8711EVM for the thermal shutdown before the soldering breaking with hot air. Also it will be hard to heated inside as its a pre-driver.

It will be very little chance for DRV8711 to meet thermal issue in real application. It will be hot for the average driving current and LDO at higher VM, but not reaching too much high to hit thermal shut down during operation. Also we should take care of the PowerPAD and copper area design to make sure the whole driver board include DRV8711 and MOSFETs are under good heat dissipation condition. nFAULT for thermal shutdown should be avoided in normal running condition.

I need to check with designer on the index behavior during different nFAULT conditions and get back to you later.

Best regards,

It is clear that it is almost not possible to test. I have no ideas too how to test it. It is because I am asking you - need I control FAULT pin always or not.
I can assert FAULT pin by OCP for example, but it will never be resetted automatically. So, for this fault type I can sample FAULT pin only after stopping without risk that indexer will be in unpredictable state due to FAULT was asserted and released while SW does not know about this event.

But temperature fault can release FAULT pin without SW actions and there is a risk that SW will not know about this event and will not know that indexer is not synchronized with SW now.

Thanks for checking with designers.