Firmware update bricked printer - SPI connection has been reset

Phaedrux

Can you use the USB bossa firmware flashing instructions to reflash the 6Xd with the stock 3.5.2 firmware? Then attempt to setup the board standalone by setting up an SD card with the 3.5.2 DWC files without any other canbus boards connected. If that works, go from there and add the expansion boards.

https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_firmware#fallback-procedure-2

@p8blr said in Firmware update bricked printer - SPI connection has been reset:

This is an edit because nobody has responded yet, but I took a spare 6XD that I had, re-imaged the NVME, connected everything, ran sudo apt-get update, sudo apt-get upgrade (this updated firmware on the 6XD to 3.5.2) and I still get the same SPI errors.

This is a little strange and makes it sound like it's actually an issue with the ribbon cable or Pi itself.

p8blr

@timschneider Thanks for your reply!

I'll change it to G4 S10

daemon.g

Everything at 24V

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6XD version 3.5.2 (2024-06-11 17:13:17) running on Duet 3 MB6XD v1.0 (SBC mode)
Board ID: 08DLM-956DA-M2NS4-6JTD6-3S86M-1B3GT
Used output buffers: 1 of 40 (24 max)
=== RTOS ===
Static ram: 153768
Dynamic ram: 95836 of which 0 recycled
Never used RAM 93460, free system stack 163 words
Tasks: SBC(2,ready,1.0%,805) HEAT(3,nWait 6,0.0%,367) Move(4,nWait 6,0.0%,211) CanReceiv(6,nWait 1,0.1%,794) CanSender(5,nWait 7,0.0%,329) CanClock(7,delaying,0.0%,351) MAIN(2,running,98.7%,444) IDLE(0,ready,0.1%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:22:18 ago, cause: power up
Last software reset at 2024-08-30 16:53, reason: User, Gcodes spinning, available RAM 100512, slot 2
Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 20.7, current 35.2, max 35.5
Supply voltage: min 24.0, current 24.3, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 99/48, heap memory allocated/used/recyclable 2048/904/84, gc cycles 0
Events: 3 queued, 3 completed
Driver 0: ok
Driver 1: ok
Driver 2: ok
Driver 3: ok
Driver 4: ok
Driver 5: ok
Date/time: 2024-08-30 18:01:44
Slowest loop: 2.84ms; 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 3, maxWait 25922ms, 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 3, completed 3, 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
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.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 0x20000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 12107, received 127720, lost 0, errs 1, boc 0
Longest wait 3ms for reply type 6060, peak Tx sync delay 380, free buffers 50 (min 48), ts 6691/6690/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 52433/52433
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x256f8
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.2 (2024-06-12 07:12:47, 64-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 39.69, max time between full transfers: 40.7ms, max pin wait times: 32.3ms/2.7ms
Codes per second: 0.19
Maximum length of RX/TX data transfers: 6102/988

M115 B0
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6XD FIRMWARE_VERSION: 3.5.2 ELECTRONICS: Duet 3 MB6XD v1.0 FIRMWARE_DATE: 2024-06-11 17:13:17

Thanks!

p8blr

@Phaedrux

So know it may not have been super clear with my scatter-brained posts, but that was actually something I tried. I got the same SPI errors in standalone mode. That last section of brake code that I posted is what I determined set it off. I discovered it by clearing config.g, and slowing adding in my code one section in a time.

p8blr

@dc42 What am I doing wrong?

I also tried the old method:

sudo rm -f /etc/apt/sources.list.d/duet3d-unstable.list
sudo bash -c "echo 'deb https://pkg.duet3d.com/ stable armv7' > /etc/apt/sources.list.d/duet3d.list"
sudo apt update
sudo apt dist-upgrade

But that also didn't upgrade the firmware to 3.5.3-rc.1

p8blr

@chrishamm how do I update to 3.5.3-rc.1 in sbc mode? Can you please send me the exact commands? I’ve tried all possible combinations and it doesn’t work. I updated in standalone mode, but when I connected my pi and tried to audio apt update/upgrade it downgraded my 6xd without asking me. I also have no way of manually updating DWC.

jay_s_uk

@p8blr it looks like 3.5.3-rc1 isn't currently on the DSF package feed so you can't update to it in SBC mode

p8blr

@jay_s_uk Interesting. How did you check that so I know for future reference? Is there no manual way to update firmware in SBC mode?

jay_s_uk

@p8blr was reported in the other thread. And you shouldn't manually update as there may be breaking changes between the firmware and DSF

timschneider

@p8blr was the extended delay able to get rid of the unknown driver messages?

the M122 looks normal to me.

p8blr

@timschneider The delay didn't make a difference, however, changing the brake code to S10 from S1000 seems to have fixed that particular issue.

M569.7 P0.2 C"out3" S10 ; driver 2 on board 6XD uses port out3 to control the brake
M569.7 P0.3 C"out4" S10 ; driver 3 on board 6XD uses port out4 to control the brake
M569.7 P0.4 C"out5" S10 ; driver 4 on board 6XD uses port out5 to control the brake
M569.7 P0.5 C"out6" S10 ; driver 5 on board 6XD uses port out6 to control the brake

Note that I was playing with increasing that value because my servos were getting position recovery errors.

chrishamm

@p8blr It's now available, looks like the GitHub Actions workflow for prereleases wasn't triggered correctly. Sorry for the inconvenience.

p8blr

@chrishamm Didn't work.

Process:
Removed SD card from duet, connected RPI ribbon cable, powered on, M997 S2 F"unstable", sudo apt update, sudo apt full-upgrade

chrishamm

@p8blr /dev/gpiochip4 is correct for the Pi 5. Is it still the same board or did you replace it?

p8blr

@chrishamm Exact same board. I'll reimage the pi and try again.

chrishamm

@p8blr If it's actually caused by a system update, don't use apt to install the latest system package versions, instead use M997 S2 only to update DSF. I'll investigate.

p8blr

@chrishamm new image with no updates works. M997 S2 F"unstable", M997 S2