Somehow, we spent a lot of time with "intermediate effects" due to incomplete TMC223 spec.
1.) If the device somehow ended up in stalled mode (getstatus2 never read out) - these bits survive
the "proper" init sequence.
So its obligatory for using stall detection to read status 2 at init time - otherwise these bits will be set/cleared at first readout.
In our case we used stall detection for referencing - with the effect that the first reading of status 2 during referencing had this bit set
if stall occured "pre-reset".
A state diagram concerning that would be nice to have in the docs + extra init suggestions.
2.) In our application - I set the stalling parameters at init time - expecting that the thing will stop in any situation further on.
This is not the case.
On some movements I just readout status 1 looking at the "moving" bit.
In this situations - the controller doesn´t stop if stalled (!!!!!)
The controller only stops on "stall" if status 2 is read out frequently.
It even looks that the controller checks stalled condition during status 2 readout _ O N L Y _
This means there is some latency on detecting the stall - depending on the polling interval of status 2...
I haven´t checked the newest datasheets so far - but - these fundamental issues should even be documented in a preliminary datasheet.
rgds.
