timeout while waiting for transfer ready pin

TobiAsis

Hi.

I have trouble connecting to my duet in sbc mode.
It is a duet 3 mini 5+, and a raspberry pi 4. I installed everything according to the documentation, both the newest firmware on the board and on the pi. Unfortunately I keep getting the error "Could not connect to Duet: timeout while waiting for transfer ready pin". I tried connecting a different pi, which works with my other 6hc board and this one shows the same error.

In fact, I can take any of my two pis and connect them to my 6hc board and it works just fine, while they will both not work on my duet 3 mini 5+.
I also exchanged ribbon cables. No difference. They work with the 6hc but not the mini.

Funny thing is, that it all used to work fine two weeks ago, and now it does not anymore.
Any ideas? Is it possible that the board is broken?
I am not entirely sure, but I might have put the ribbon cable on with an offset of one pin, while the pi was already powered on (the duet was not). I immediately unplugged it and connected it the wrong way. Could this damage anything permanently?

I can still connect to the duet mini via pronterface and updated the firmware this way, I can also send commands. Only the SBC mode does not work...

Cheers
Tobi

droftarts

@TobiAsis Send M122 to the Mini 5+ and post the response. If it says (standalone mode) rather than (SBC mode) in the first line, eg:

RepRapFirmware for Duet 3 Mini 5+ version 3.5.1 (2024-04-19 14:41:25) running on Duet 3 Mini5plus WiFi (standalone mode)

rather than

RepRapFirmware for Duet 3 Mini 5+ version 3.5.1 (2024-04-19 14:41:25) running on Duet 3 Mini5plus WiFi (SBC mode)

take the SD card out of the SD card socket.

Ian

TobiAsis

@droftarts Thanks for your reply. The Board is in SBC mode and has no SD card inserted.
See response to M122:

SENDING:M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.1 (2024-04-19 14:41:25) running on Duet 3 Mini5plus Ethernet (SBC mode)
Board ID: KPLT0-NT8LU-F65J0-409NA-KR03Z-Z9GFM
Used output buffers: 1 of 40 (1 max)
=== RTOS ===
Static ram: 103232
Dynamic ram: 103360 of which 12 recycled
Never used RAM 34812, free system stack 156 words
Tasks: SBC(2,nWait 7,0.0%,970) HEAT(3,nWait 6,0.0%,372) Move(4,nWait 6,0.0%,355) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,334) TMC(4,nWait 6,0.0%,122) MAIN(1,running,98.9%,856) IDLE(0,ready,0.3%,30) AIN(4,delaying,0.8%,265), total 100.0%
Owned mutexes: USB(MAIN)
=== Platform ===
Last reset 00:00:35 ago, cause: power up
Last software reset at 2024-05-02 15:04, reason: User, Gcodes spinning, available RAM 42120, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Error status: 0x00

MCU revision 3, ADC conversions started 35579, completed 35578, timed out 0, errs 0
MCU temperature: min 16.1, current 19.6, max 19.8
Supply voltage: min 0.3, current 0.8, max 0.8, under voltage events: 0, over voltage events: 0, power good: no
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: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 1: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 2: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 3: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 4: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 5: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 6: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0
Date/time: 1970-01-01 00:00:00
Cache data hit count 84872674
Slowest loop: 0.25ms; fastest: 0.00ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, 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 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "M122" 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 178, received 0, lost 0, errs 170972, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 26 (min 26), ts 178/0/0
Tx timeouts 0,0,177,0,0,0 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 0, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 0/1
SPI underruns 0, overruns 0
State: 0, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x0d90c
Buffer RX/TX: 0/0-0, open files: 0

Tobi

droftarts

@TobiAsis said in timeout while waiting for transfer ready pin:

I am not entirely sure, but I might have put the ribbon cable on with an offset of one pin, while the pi was already powered on (the duet was not). I immediately unplugged it and connected it the wrong way. Could this damage anything permanently?

I'm checking whether this may cause a problem. Can you remember which way the ribbon cable was shifted when it went on? Can you post a picture of how the Duet and RPi are connected?

If I remove the SD card from my Mini 5+, I get an M122 very similar to yours. So I think it's getting no connection on the transfer pin. Check that it's not short circuited behind the Duet, if it is already mounted, and that there's nothing between the pins of the expansion connector (stray pieces of metal), and that the pins are fully soldered.

Ian

TobiAsis

@droftarts I put the ribbon cable on that way:

bent pin.jpg

Once I realized the issue, I removed it and plugged it in the right way. I removed everything else from the duet, so nothing apart from power and ribbon cable is connected there right now:

The duet is mounted on standoffs, there is nothing behind it. The solder points look flawless and there is not metal pieces there:

ribbon duet.jpg

Cheers
Tobi

droftarts

@TobiAsis I think it's possibly that putting the cable on incorrectly has damaged the MCU of the Duet. 5V power is on pins 2 and 4, which has connected to pin 4 (5V, which is okay) and pin 6, which is ground, on the Duet. Did you have the Duet plugged into a PSU? If so, that should have grounded the 5V. If not, I think it has then shorted from the Duet GND, through pin 22 on the Duet (SBC_DATA_RDY - I think this is the transfer ready pin), and back to GND on the Pi, on pin 20. So most likely it has shorted the logic on the Duet MCU for that pin.

It sounds like the board can still be used as in standalone mode, ie without the SBC. ~~I don't know if there's a way to use a different pin on the Duet for SBC_DATA_RDY.~~ It won't be possible to use a different pin on the Duet without a custom firmware build, and it still may depend if there is further damage than just the circuitry related to this pin.

Ian

TobiAsis

@droftarts Hi Ian, thanks for your reply.

So it is what I expected. A costly learning experience, but now I know to be extra careful with the connections. I will still be able to use it in standalone mode on another project, I just need to learn now how to set everything up without SBC.

Have a good day!
Tobias