Duet3 Mini Wifi + Raspberry Pi 3+ SBC - SPI Connection Reset

jgrg1

Hi,

I have a Duet3 Mini wifi with a Raspberry Pi 3B+ SBC. This has been working fine for 4 years. Now, whenever I try to print, the raspberry pi reboots almost immediately and I get an SBC Connection reset error. I narrowed it down to simply turning the heater on via the dashboard in DWC. So there's no stepper motor movement at all. I also made sure the Duet SD card was completely removed.

I just recently flashed a new 64gb Samsung Evo SD card with the image_2024-11-27-DuetPi-arm64.zip image (from here https://github.com/Duet3D/DuetPi/releases) using the official raspberry pi imager software. This runs the 3.5.4 Duet firmware. Also did a sudo apt update/upgrade and allowed labwc to overwrite the various .conf files as part of that upgrade. Same issue, re: SBC connection reset.

Running 'top' in a pi terminal on the new image seems to show a chromium process taking anywhere between 20% and 40% of the cpu usage - which seems high to me. I've tried killing that process and turning on the bed heater, and the pi still resets. The pi PSU seems ok.

Running the Duet in standalone mode works perfectly fine.

M122 output after a reset is:

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.4 (2024-11-24 10:44:24) running on Duet 3 Mini5plus WiFi (SBC mode)
Board ID: R4MQT-XP6KL-K65J0-409NY-3Q02Z-HYPA6
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 103496
Dynamic ram: 108340 of which 0 recycled
Never used RAM 27060, free system stack 208 words
Tasks: SBC(2,ready,1.2%,813) HEAT(3,nWait 1,0.0%,348) Move(4,nWait 6,0.0%,355) CanReceiv(6,nWait 1,0.0%,939) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,334) TMC(4,nWait 6,0.8%,110) MAIN(2,running,97.1%,664) IDLE(0,ready,0.0%,29) AIN(4,delaying,0.8%,264), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:13:31 ago, cause: power up
Last software reset at 2025-04-26 00:53, reason: User, Gcodes spinning, available RAM 27040, slot 2
Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 609192, completed 609192, timed out 0, errs 0
MCU temperature: min 28.5, current 33.6, max 33.9
Supply voltage: min 23.2, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/7, heap memory allocated/used/recyclable 2048/1952/1836, gc cycles 2
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 32783, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 32783, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 32784, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 32783, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 32783, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2025-04-26 22:18:24
Cache data hit count 1807064435
Slowest loop: 4.17ms; fastest: 0.12ms
=== 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 0 -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 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
check 0 clear 3856743
Extruder 0 sensor: ok
=== CAN ===
Messages queued 5606, received 0, lost 0, errs 2946270, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 26 (min 26), ts 3115/0/0
Tx timeouts 0,0,3115,0,0,2491 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 3714/2591
SPI underruns 0, overruns 0
State: 5, disconnects: 5, timeouts: 5 total, 5 by SBC, IAP RAM available 0x0cd20
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.4 (2024-11-25 17:32:26, 64-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 22.38, max time between full transfers: 3773.4ms, max pin wait times: 2031.7ms/10.7ms
Codes per second: 0.25
Maximum length of RX/TX data transfers: 4421/532

I've also just tried it with a brand new ribbon cable, and a freshly flashed 32Gb Sandisk ultra SD card with image_2023-09-06-DuetPi.zip + apt update/upgrade. It still crashes the pi when I turn the bed heater on.

droftarts

@jgrg1 Sounds more like your bed heater is shorting out. I doubt it has anything to do with the Pi/Duet configuration. What happens if you try printing without turning on the heated bed?

Ian

jgrg1

@droftarts Hmm, could be - it's a bedslinger. I'll check the wiring.

jgrg1

@jgrg1 Wiring is all good. Continuity all checks out.

On a whim, I checked the current draw on the USB step down converter I use (https://www.amazon.co.uk/dp/B08KRS85JZ). When I turned the bed heater on, the power draw shot through the roof and the device reset. I tried with a bog standard USB power brick, and even though I get the low power icon on the pi, it doesn't kill the power and works. I'm guessing the USB converter is a heap of junk.