TMC2130 sensorless_homing fails after cancelling print from host

[truglodite]

Description

Bug Report (bugfix 2.0.x)

Steps to Reproduce

1. Start a print using host (octoprint)
2. While printer is moving, cancel print from host.
3. Host sends M114 to log position, then sends a 'cancel script' as follows...
4. M84 ;disable steppers
5. M104 S0 & M140 S0 ;disable hotend and hotbed
6. M106 S0 ;disable fan (...this is the end of the cancel script)
7. Then I send G28 (from host) to home all

Expected behavior:
After G28 is sent, home all as usual. To be more specific... z raises 5mm to clear stuff, x moves home, y moves home, then x and y move to the z_safe_probing spot, z lowers until the inductive probe triggers over a probe target near the left front corner (the target is a piece of aluminum tape on top of the glass bed).

Actual behavior:
After G28 is sent, z raises 5mm, but x doesn't home all the way left instead it stays there, then similarly y stays put, the carriage then appears to move toward a false z_safe_homing position, then starts to lower z at a bad spot for probing (no target). The end result is the probe never triggers and the nozzle crashes into the bed. I have to quickly kill marlin to stop my z motors from grinding away and damaging the nozzle.

Additional Information

With my little knowledge I can only conclude that the tmc diag pins may be somehow stuck on 'triggered' after cancelling.

If I force this failure, a marlin reboot gets everything working again. Sensorless homing and stallguard for x and y are working perfectly for me aside from this issue after cancelling a print. I have homed for maintenance and let the printer sit longer than DEFAULT_STEPPER_DEACTIVE_TIME. After that homing still seems to work as it should. So it doesn't look like the M84 alone in my cancel script would cause this.

The closed issue #8890 is different in that G28 only worked once for him, and I can do many G28's or G29's in a row without issue... until AFTER I cancel the print. I figured I'd mentioned it since it seems related.

My config is pretty standard; RAMPS_EEB with stealthchop enabled and no modifications to spreadcycle thresholds. I do have some of pins my pins swapped around from defaults due my setup and having a bad Mosfet, but I don't see how this would cause a problem. This problem exists for me regardless which marlin branch I try (both current 1.1.x and 2.0.x bugfix). My attached configs & pins files are for 2.0.x since I'm currently using 2.0.x files I downloaded a couple of days ago.

configs.zip

[Thairay]

i got the same issue but I do not use the diag pins of my tmc2130.
Most of the time the x carrier will crush into the max position if this error occurs.

[truglodite]

I had another occurrence of failed homing. This time x homed properly, then y didnt move, a move after for z safe homing, and z lowered to crash the bed. So I think I have more diagnostics to do, but it sure seems like g28 is not always working how it should.

[Thairay]

Its like it is saving the coordinates at the ending position of g28 instead of at the endstops position. But only occurs if a print was cancelled.

[truglodite]

It's been a while, but I haven't experienced anymore occurrences of this issue. I presume a marlin or tmc driver update fixed the problem. So I'm closing this issue.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.