Vivedino Troodon Board (non-working w/RRF >=3.1).

[oliof]

@gloomyandy They're TMC2660. I connected the stepper to the port labelled X and tried moving the X stepper. And, just to repeat -- everything works as expected with RRF2.x and 3.0 with no changes to the wiring.

The error message is definitely not correct.

(for clarity: The stepper connectors are labelled E0 X Y E2 E3 E4 E5, this can also be seen on the back).

[jay_s_uk]

@oliof are the 2.05 and 3.0 builds you are using ones supplied by them or ones supplied by duet?

[oliof]

@jay_s_uk they're the genuine Duet3D builds. Formbot3D doesn't provide their own builds.

[jay_s_uk]

@oliof well that just adds to curiousness of it all.
Hopefully you succeed in getting the design files!
If not, maybe @T3P3Tony can step in to see what he can do

[gloomyandy]

@oliof Can you check the m122 output while you are getting the warning to see if the driver status shows a similar message. Was it the same config.g file for both 3.0 and 3.x (x>=1)?

[oliof]

@gloomyandy yes, the same config.g as posted above. I will do some more testing tomorrow.

[oliof]

Here are some photos of the bigfoot stepper modules, the last one with an overlay of the 2660 pinout courtesy of Chase Daigle.

[oliof]

@gloomyandy here's an M122 after an attempted X move:

	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) running on Duet WiFi 1.02 or later + DueX5
Board ID: 0JD0M-9P6M2-NW4SD-6J9D8-3S86Q-9APHL
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 23876
Dynamic ram: 79464 of which 0 recycled
Never used RAM 11076, free system stack 150 words
Tasks: NETWORK(ready,6.6%,249) HEAT(delaying,0.0%,342) Move(notifyWait,0.1%,323) DUEX(notifyWait,0.0%,24) MAIN(running,93.3%,415) IDLE(ready,0.0%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:02:48 ago, cause: power up
Last software reset at 2021-10-05 18:04, reason: User, GCodes spinning, available RAM 11076, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
Step timer max interval 0
MCU temperature: min 25.0, current 25.8, max 25.9
Supply voltage: min 24.2, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 800, standstill, SG min/max not available
Driver 1: position 0, standstill, SG min/max not available
Driver 2: position 0, temperature-shutdown! short-to-ground, standstill, SG min/max not available
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, temperature-shutdown! short-to-ground, standstill, SG min/max not available
Driver 5: position 0, standstill, SG min/max not available
Driver 6: position 0, standstill, SG min/max not available
Driver 7: position 0, standstill, SG min/max not available
Driver 8: position 0, standstill, SG min/max not available
Driver 9: position 0, temperature-shutdown! short-to-ground, standstill, SG min/max not available
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-10-06 07:19:47
Cache data hit count 4294967295
Slowest loop: 4.21ms; fastest: 0.70ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 0.4ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 145255ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 2, completed moves 2, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== DueX ===
Read count 0, 0.00 reads/min
=== Network ===
Slowest loop: 199.91ms; fastest: 0.08ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 2
WiFi firmware version 1.26
WiFi MAC address 3c:61:05:e6:f7:3b
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 19488
WiFi IP address 192.168.86.39
WiFi signal strength -56dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 4 0 0 0 0 0 0

It bears noting that I by now twice did an accidental G0 H2 X1 F300 before a G0 H2 X10 F300 -- and on the X1 move nothing happened; neither a move nor a motor phase error.

[o_lampe]

@oliof I can't say anything about the FW-issues, but i compared the 2660 PCB with the original Duet2. I noticed, there are far more "vias" on the Duet around the 4 output tracks (A1-B2) and the tracks are much wider. The Duet also has more vias below the chip to transfer heat to the PCB backside.
Could you post a picture of an empty driver-socket? I'm missing a big capacitor on the driver to stabilize VMot.

[gloomyandy]

@oliof Are you still getting an error saying:
"motor phase A may be disconnected reported by driver(s) 0"
If you are can you run m122 when that error is being reported. I would expect the motor status to report:
"open-load-A"
or something similar. In your original post it looked like it was reporting the error over and over once it happened was that the case or was it reporting it only when you did a move?

[droftarts]

@oliof is it because it identifies as Duet+DueX5, rather than Duet+DueX2, so it’s not disabling the extra non-existent drivers? How did it identify on old FW versions? There’s definitely a hardware difference between the real boards. See https://duet3d.dozuki.com/Wiki/Duex2_and_Duex5_Features#Section_Using_a_DueX5_with_External_drivers

I’d guess you’d have to look at the Troodon schematic next to the DueX schematic to work out what’s different.

Ian

[jay_s_uk]

@droftarts it doesn't include the Drivers 2, 4 and 9, which are Z, E1 and E6 so it really is a duet+duex5 rather than a duet+duex2

[oliof]

@gloomyandy yes and the M122 is from when I got the error. And yes, it does repeat reporting the error.

[oliof]

@o_lampe .

Yes, the cooling setup is different, but please remember: The hardware is proven to work, it worked fine with RRF until 3.0 and it continues to work well with either older RRF versions or Klipper. The design may not be ideal, but it's solid and functional.

[oliof]

@droftarts it always identifies as a Duet+DuetX5, and as you can see in my config.g, the missing drivers are disabled so they don't report an error. I have not heard back from Formbot3D but if I am not mistaken there's a weeklong holiday so I picked an unfortunate time to expect a speedy answer.

[oliof]

@o_lampe @droftarts one of the easiest discernible differences is that SG_TEST is not connected, i.e. stallguard pin is floating. Since people elsewhere were theorizing the floating stallguard may be a problem, I bridged SG_TEST to the neighboring GND pin (which I confirmed to be going on the GND rail with a multimeter, I also checked my solder attempt and it's got continuity from SG_TEST to VNegative).

Unfortunately no change.

[oliof]

To make it clear @gloomyandy: While I get the phase mismatch error in the console, the driver does not report open load state in M122. That is what you were looking for?

[gloomyandy]

@oliof I was expecting to see it in the m122 output, but there is a lot of "filtering" going on for this condition (motor, current, step speed, must be reported constantly over time), so it's hard to be sure. I've had a good luck at the changes since V3.0 and I can't see anything obvious that would result in what you are seeing.

[oliof]

@gloomyandy I've been spelunking in Platform.cpp and the TMC2660 driver code (in vimdiff between 3.0 and 3.1.0), and nothing jumps immediately out at me that would explain this behavior. There are some changes about the setting and resetting of status bits that may be related, but my C++ knowledge is likely not good enough to see the subtlety that likely causes this failure. Best guess is, it's something about the changed driver initialization, maybe even the missing 10 millisecond pause that's still in 3.0 but was dropped in 3.1 ... I may just add that back, recompile and see if it helps.

[dc42]

@oliof where in the code was this 10ms pause?