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

[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?

[oliof]

@dc42 it's possible I've been confused by vimdiff's output, I will need to re-check what I saw last night ... When I'm back home later today. Sorry for the confusion; I am still trying to understand what's going on...

[oliof]

@dc42 microseconds, not milliseconds -- sorry for the mixup. In src/Movement/StepperDrivers/TMC2660.cpp; line 1030 in the 3.0 release. The whole driver bringup has been significantly changed between 3.0 and 3.1. My gut says it's a likely candidate to dig into since the failure happens on first move attempt.

[dc42]

@oliof I suspect the problem may be caused by the code in the new driver that checks the microstep position and adjusts it to be zero before it enables the driver. This code should be disabled for drivers that have been disabled. I will look at implementing than in the next 3.4beta.

[oliof]

@dc42 I do have a Duet2Wifi with a blown driver (E0, so driver 3 IIRC). I never upgraded that board to RRF3, and had packed it away to send for repairs. I hadnot gotten around to sending this board out, so I was able to do a comparison with the Troodon board.

In the simple test bench setup with one stepper connected to driver 0 (X), this board does not exhibit the same failure mode as the Troodon board. In fact, it just works without any complaints.

Of course this might be because there actually are traces and resistors on the board for this driver (or the driver is only partially broken instead of completely missing), so the behavior of the overall board could very well be different.

Since I noticed you got the change landed already, I'll see that I get my build environment up and running again for a (hopefully) quick build and feedback cycle.

[oliof]

@dc42 looks like my build environment was in good enough shape that I could build the latest 3.4-dev checkout -- and I can confirm the issue is resolved. I now get a move out of the motor without errors.

[o_lampe]

@oliof I tried to find their TMC2660 drivers sold separately, but computer says NO
Would be cool to add them as driver 10+11 to a Duet2. For now we can only use external drivers without SPI on the CONN_LCD pins.