Duet 0.6.5 SD-card reader death. Any thoughts?
-
I have a Duet 0.6.5 (supplied by RepRapPro) and a DuetWifi (recently bought from Think3DPrint3D), both running Ormerod 2's.
(Both using the SD cards supplied with the respective equipment.)
After 2+ years of use, last night the Duet 0.6.5 freezes and falls off the network.After diagnosing a while, I realise that I can communicate with the 0.6.5 via USB , but M503 reports that it can't read the SD card.
I can read the SD card fine, I try other SD Cards, including the one in my working DuetWifi. M503 reports no dice to all.
I've erased and reflashed with various firmwares, just in case, all to no avail.So I've got Octoprint running in a rudimentry fashion, but realise that there is going to be some work to get it functioning as the Duet web interface.
I just thought I'd mention it here in case anyone has any other thoughts…
(I've also mislaid the original SD card now in the workshop with all the swapping around, I'm not having a good time! ) -
On some older Duets the soldering of the pins at the back of the SD card socket to the PCB wasn't complete. So I suggest you use magnification to check whether there is a fillet of solder between each SD card pin and the PCB.
If that's not the problem, it's either the contacts inside the SD card socket, or the processor that is faulty. Both can be replaced, but replacing the SD card socket is easier.
-
Thank you for your input David. Especially as an older Duet, it's not anything to do with you and not your problem
Checking the SD-card socket soldering is a good idea I hadn't considered (even though it wasn't moved, I've been around long enough to know anything is possible)
Just to clarify what you mean by "the processor", is there a processor specifically for the SD card or are you referring to the main Atmel processor? -
I mean the main Atmel processor.
-
Update: Interestingly, with no SD card in , M122 reports "SD card 0 detected, interface speed: 0.2MBytes/sec"
I'll update this thread when I dismantled and found anything else.
[[language]] Send: M122 Recv: === Diagnostics === Recv: Used output buffers: 2 of 32 (13 max) Recv: === Platform === Recv: Static ram used: 45820 Recv: Dynamic ram used: 39916 Recv: Recycled dynamic ram: 280 Recv: Stack ram used: 3240 current, 4224 maximum Recv: Never used ram: 8064 Recv: Last reset 01:21:16 ago, cause: power up Recv: Last software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00000000, BFAR 0xe000ed38, SP 0xffffffff Recv: Spinning module during software reset: GCodes, available RAM 8864 bytes (slot 0) Recv: Error status: 0 Recv: Free file entries: 10 Recv: SD card 0 detected, interface speed: 0.2MBytes/sec Recv: SD card longest block write time: 0.0ms Recv: MCU temperature: min 19.7, current 54.1, max 128.6 Recv: Date/time: 1970-01-01 00:00:00 Recv: Slowest main loop (seconds): 1.005859; fastest: 0.000000 Recv: === Move === Recv: MaxReps: 0, StepErrors: 0, MaxWait: 0ms, Underruns: 0, 0 Recv: Scheduled moves: 56, completed moves: 56 Recv: Bed compensation in use: none Recv: Bed probe heights: 0.000 0.000 0.000 0.000 0.000 Recv: === Heat === Recv: Bed heater = 0, chamber heater = -1 Recv: Heater 0 is on, I-accum = 0.0 Recv: Heater 1 is on, I-accum = 0.3 Recv: === GCodes === Recv: Segments left: 0 Recv: Stack records: 1 allocated, 0 in use Recv: Movement lock held by null Recv: http is idle in state(s) 0 Recv: telnet is idle in state(s) 0 Recv: file is idle in state(s) 0 Recv: serial is ready with "M122" in state(s) 0 Recv: aux is idle in state(s) 0 Recv: daemon is idle in state(s) 0 Recv: queue is idle in state(s) 0 Recv: Code queue is empty. Recv: === Network === Recv: Free connections: 16 of 16 Recv: Free transactions: 24 of 24 Recv: Locked: 0, state: 2, listening: 0x0, 0x0, 0x0 Recv: === Webserver === Recv: HTTP sessions: 0 of 8 Recv: FTP connections: 0, state 0 Recv: Telnet connections: 0, state 0 Recv: ok
-
The SD card detect signal doesn't work on the older Duets since we enabled MCU temperature monitoring, because of a bug in the SAM3X processor.