by TRINAMIC_BD » 02 Nov 2006, 16:30
The cause in most of these cases lies in a random synchronization between the updating of the StallGuard information inside the TMC246 / TMC 249 with the read out by the user. Especially when the TMC428 is used, reading out of the StallGuard value typically is not synchronized with the update inside the driver.
Solution in systems using the TMC428:
General procedure to read out StallGuard information via the TMC428:
The StallGuard values are read using the TMC428 registers datagram_low_word and datagram_high_word. An update of these registers is forced by writing to one of the registers and polling the CDGW bit, which becomes cleared as soon as the update has happened. In order to detect a stall within the fullstep period where it has occured, trigger the read out at least once per fullstep.
Addition to avoid false detection of stall:
However, the StallGuard values might have been read by the TMC428 in a phase, where the values were invalid. To avoid erroneous detection of a stall, trigger the read out procedure a second time, directly after detection of a stall condition. Only if the second read out still signals a stall condition, a valid stall has been detected.
Systems which directly interface the TMC246 / TMC249 via a microcontroller:
In these systems, there is a given synchronization between the sending out of (micro)steps and the reading in of the StallGuard information. In order to avoid reading the StallGuard bits during the internal update period of the driver, do not use data from SPI datagrams directly following the SPI datagram which has initiated the next fullstep, i.e. which has toggled PHA or PHB bits. The TMC246 / TMC249 updates the stall information within 1 chopper period plus 8 microseconds after toggling of the PHA / PHB bits. A safe point of time to read out the StallGuard bits is for example the SPI datagram, which initiates a phase toggle, or the one preceding it (in microstep applications).