@Z4c_Sm1th There was a check introduced in 3.6.0-beta3 to ensure the stall detection moves were within generally likely to work limits;
https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-beta3
If you are using stall homing, please test it after upgrading to this release. In this version, a homing move that uses stall endstops will be cancelled and an error message generated if the movement speed is too low (also if it is too high when using TMC2209 or TMC2240 drivers) for stall detection to be definitely feasible. There are small speed ranges that will be rejected by this release but may in practice have worked using previous firmware versions.
Also note:
https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection#background-on-stall-detection
Additionally, the TMC2209 stepper driver used in Duet 3 Mini 5+ (and Duet 3 Tool board TOOL1LC once stallGuard is implemented in firmware), features stallGuard 4. This is optimised for operation with stealthChop, while its predecessor stallGuard 2 (TMC5160 and TMC2260) works with spreadCycle.
So for the TMC2209 on the mini5+ it does need to be in stealtchop - but only for the homing move.
I have looked at the Homing files and config you have posted, you definitely don't want an M18 in homey (I know you said you put it in for testing) because it will power down all the axes and set them all to un homed. Also I would move the M915 out of your homing files and into the config.g. I am not sure that's the issue but its something different from how I have it when I tested this before.
So try without M18 or M915 in the homing files, and with the M915 line in config.g and see how that goes.
If you want to test various M915 settings then you can send the command in the console between homing test moves.
