Duet3 + SBC (Timeout while waiting for transfer ready pin)

andywm

Hello, I need help troubleshooting this issue;

A few months ago, I converted one of my machines to use an SBC mode Duet3 6HC. The machine now randomly halts. DWC will report status=disconnected. And this warning will be in the console;

"Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin"

At this point the duet itself seems to be in a sailfafe mode, all the fans on max, all the heaters off. And requires a power cycle to restore communication.

Here are some details about my setup;

Duet3 6HC 1.02a
Pi4 /w duet ISO for the Pi with DSF.
Pi PSU Meanwell LRS-75-5. Adjusted the output trim pot to 5.1v.
Duet 5v Select to 5V_EXT
24v System PSU.
Commoned ground between 24v PSU and 5v PSU.
Included GPIO ribbon used. Currently ran straight with pi in temporary position.
Cables running power and control signals to tool CAN boards pinned aside and clear of this cable.
I've updated DSF and all the cand devices firmware at least once since experiencing the issue.
(M115) FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.5.3 ELECTRONICS: Duet 3 MB6HC v1.02 or 1.02a FIRMWARE_DATE: 2024-09-18 11:27:36

The problem itself is intermittent, as far as I can tell random. If it's a short enough print, it may finish or may fail on like the third layer. Some of the above are as a result of troubleshooting steps I've already tried. e.g. Updating firmware, managing interference around the ribbon cable, ensuring a common ground, 5.1v is as a result of that's what the Pi PSU does for instance. But I am just taking wild guesses, and am basically at the end of what I can think to try.

Here are some pictures of the electionics bay if it helps, and I'll include M122 dumps before an issue has occured, and immediately after a restart post issue.

No Issue M122

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.3 (2024-09-18 11:27:36) running on Duet 3 MB6HC v1.02 or 1.02a (SBC mode)
Board ID: 0JD4M-958L1-M24TD-6J9F2-3S46J-K0TFX
Used output buffers: 1 of 40 (18 max)
=== RTOS ===
Static ram: 155352
Dynamic ram: 92292 of which 2744 recycled
Never used RAM 95604, free system stack 202 words
Tasks: SBC(2,ready,0.9%,820) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,0.0%,335) CanReceiv(6,nWait 1,0.1%,796) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,9.4%,55) MAIN(2,running,89.3%,101) IDLE(0,ready,0.3%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:04:43 ago, cause: power up
Last software reset at 2024-10-27 12:20, reason: User, PrintMonitor spinning, available RAM 127816, slot 2
Software reset code 0x0009 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU temperature: min 17.1, current 31.9, max 32.0
Supply voltage: min 24.2, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.3, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a, mspos 8, reads 45138, writes 17 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 45136, writes 19 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 45137, writes 18 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 45139, writes 16 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 45144, writes 11 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 45145, writes 11 timeouts 0
Date/time: 2024-11-08 14:14:19
Slowest loop: 2.72ms; fastest: 0.06ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP* is doing "M122" 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
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 2521, received 21516, lost 0, errs 0, boc 0
Longest wait 2ms for reply type 6031, peak Tx sync delay 6, free buffers 50 (min 49), ts 1417/1416/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 10023/10023
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x24d04
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.3 (2024-09-21 10:23:58, 64-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 0.03, max time between full transfers: 60.6ms, max pin wait times: 60.0ms/3.9ms
Codes per second: 0.00
Maximum length of RX/TX data transfers: 4568/1176

Post Restart after Issue M122

Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin)

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.3 (2024-09-18 11:27:36) running on Duet 3 MB6HC v1.02 or 1.02a (SBC mode)
Board ID: 0JD4M-958L1-M24TD-6J9F2-3S46J-K0TFX
Used output buffers: 1 of 40 (18 max)
=== RTOS ===
Static ram: 155352
Dynamic ram: 92292 of which 2744 recycled
Never used RAM 95604, free system stack 202 words
Tasks: SBC(2,ready,1.0%,789) HEAT(3,nWait 6,0.0%,329) Move(4,nWait 6,0.0%,335) CanReceiv(6,nWait 1,0.1%,796) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,9.4%,55) MAIN(2,running,89.2%,101) IDLE(0,ready,0.3%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:01:30 ago, cause: power up
Last software reset at 2024-10-27 12:20, reason: User, PrintMonitor spinning, available RAM 127816, slot 2
Software reset code 0x0009 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU temperature: min 38.3, current 41.1, max 41.3
Supply voltage: min 24.2, current 24.3, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.3, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a, mspos 8, reads 35486, writes 17 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 35484, writes 19 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 35485, writes 18 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 35488, writes 16 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 35493, writes 11 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 35493, writes 11 timeouts 0
Date/time: 2024-11-24 15:53:17
Slowest loop: 2.71ms; fastest: 0.06ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP* is doing "M122" 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
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 873, received 7144, lost 0, errs 0, boc 0
Longest wait 2ms for reply type 6031, peak Tx sync delay 5, free buffers 50 (min 49), ts 452/451/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 1, checksum errors: 0
RX/TX seq numbers: 32749/3474
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x24d04
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.3 (2024-09-21 10:23:58, 64-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 13399
Full transfers per second: 37.25, max time between full transfers: 94282.7ms, max pin wait times: 499.9ms/257.3ms
Codes per second: 0.41
Maximum length of RX/TX data transfers: 4788/1212

Polyneutron21

@andywm I have the same issue. I had Chinese boards that played nice until they started getting drop outs. I purchased a genuine Duet 3 6HC and used the included cable to connect the Pi5 to the 6HC and "Timeout waiting for transfer pin. I noticed a 16 gb micro-SD card in the 6HC and thought it may be the issue, but no. Then I tried a new 24-40 pin cable and still had the same issue. Formatted thee 64GB stick with 2024-09-19-DuetPi_arm64.img and tried it after booting all Led's were bright but still had the same issue, tried a different Pi5 with a fresh copy and still "timeout waiting for transfer pin.

20250213_143138[1].jpg

I am at the end of my rope,

droftarts

@Polyneutron21 Did you remove the SD card from the 6HC? It won't be running in SBC mode if it is still in the 6HC. In our experience, most "Timeout while waiting for transfer ready pin" issues are caused by interference on the ribbon cable; see https://docs.duet3d.com/en/User_manual/Machine_configuration/SBC_setup#warning-lost-connection-to-duet-timeout-while-waiting-for-transfer-ready-pin-error
You appear to have a stepper driver cable running pretty close to the ribbon cable.

If you have a second Raspberry Pi, I'd also test with that, in case it's an issue with the RPi rather than the Duet. Also worth checking the 6HC functionality by setting it up in Standalone mode, if possible.

Ian

Polyneutron21

@droftarts I did remove the 16GB micro SD but this did not resolve the "Timeout waiting for transfer pin" and I have two Pi 5's and have tried both. The one dedicated to the SBC roll used to work fine. I took the Pi5 off the display and tried that one with a fresh image but that didn't work either. I also have two 24-40 pin cables and neither of those make a difference.

Polyneutron21

@Polyneutron21 I looked at the contents of the Micro SD that came with the 6HC and put it back into the 6HC then connected to the ethernet and only the red and green lights are on but I don't see any communication through the router. Do I need a jumper or something to tell it to go to stand alone mode?

droftarts

@Polyneutron21 Has the 6HC ever communicated with the RPi? If not, probably bench testing the 6HC and a Pi would be a good idea, ie with nothing else plugged in apart from power and the ribbon cable between them.

What firmware version is on the 6HC, and have you updated the DuetPi? I believe there were some issues initially with RPi 5 support (@chrishamm will know better). To update see https://docs.duet3d.com/en/User_manual/Machine_configuration/SBC_setup#update-firmware

There is also a newer RPi image, see https://forum.duet3d.com/topic/37011/duetpi-bookworm-2024-11-27-now-available, it may be worth trying that.

Do I need a jumper or something to tell it to go to stand alone mode?

No, just the SD card in the 6HC SD socket. You also need correct command to enable networking in config.g - M552 S1 P0.0.0.0, or send it via a USB connection using YAT. You may need to have the correct version of DWC on the SD card, to match the firmware version.

Ian

Polyneutron21

@droftarts I just shh into Pi and updated to version 3.5.4 and still waiting for transfer PIN. I will take out the Pi5 again and then put the card in and follow the instructions on getting it to stand alone. What is the point of all this. I think it is time to move past duet.

jay_s_uk

@Polyneutron21 good luck with klipper!

Probably best to sort out your wiring as suggested rather than complaining something doesn't work

Phaedrux

@Polyneutron21 said in Duet3 + SBC (Timeout while waiting for transfer ready pin):

What is the point of all this.

That may be a good question actually. Is there something you require the Pi for, rather than just standalone mode?

Polyneutron21

@Phaedrux I would rather use SBC mode. if I cannot get the SBC mode straight, there is little to no point. I have Two Manta M8P with integrated CM4 with 8 gb memory and 16GB EMMC and I had klipper on the emmc for years. CanFD was the clear choice as Can was too flakey. I still have a couple EBB36 tool boards but UUID's kept getting lost.

Polyneutron21

@jay_s_uk I took it out of the printer, connected it to a 24 VDC power supply and the pi to the computer with the USBC and the 24-40 pin cables. The wiring could not be simpler yet there was no change. I updated the firmware in the Pi 5 to 3.5.4 but the transfer pin faulted there as well. The update did finish.

Then I took it all down to pieces and used only the microSD card that came with the board and a USBC cable to the computer and the computer doesn't see it and the device manager doesn't have it.

jay_s_uk

@Polyneutron21 maybe you need to flash the board with firmware then. Best look at bossa recovery for the board you have