"...bad header format code was received (0xff)"

ww1g16

Versions:
duetcontrolserver - 3.4.3
duetpimanagementplugin - 3.4.3
duetpluginservice - 3.4.3
duetruntime - .3.4.3
duetsd - 1.1.0
duetsoftwareframework - 3.4.3
duettools - 3.4.3
duetwebcontrol - 3.4.3
duetwebserver - 3.4.3

Describe exactly how to recreate the problem.
This was during the first time setup of the board. I was going through https://docs.duet3d.com/User_manual/Machine_configuration/SBC_setup and after section "4. First Boot", I could connect to Duet Web Control but immediately got an error saying it failed to connect to Duet. I kept going to see if updating the firmware would resolve it, as I'm still able to ssh to the pi. During "6. Update firmware", the update reached 96% before getting no further - I left it overnight in case it was just slow, but no change the next day. At this point I restarted both the pi and Duet and began troubleshooting

How things are connected:

Error messages:

Output of connecting to duet via browser (e.g. 192.168.0.X)

Output of "sudo systemctl start duetcontrolserver"

Output of "systemctl status duetcontrolserver.service"

Output of "sudo journalctl -u duetcontrolserver"

What I've tried so far:
Included SD card
New SD card
Changing Pi
Reseating ribbon cable
Updating firmware via apt-get
Updating firmware via Bossa
I noticed two SPI devices (spidev0.0 and spidev0.1), so tried editing /opt/dsf/conf/config.json to use spidev0.1 instead of the default spidev0.0, but that returns a different error which I believe would imply 0.0 is correct (0.0 returns DCS is not started, 0.1 returned something to do with enable pin)

ww1g16

I also should have prefaced all this with the hardware, which is the Duet 3 6XD connected to a raspberry RPI 4 with the supplied header cable

ww1g16

I've just found some additional debugging instructions here:

https://github.com/Duet3D/DuetSoftwareFramework/wiki/SBC-Setup-Guide#troubleshooting

So please hold on until I've attempted these first as I don't want to waste anyone's time

ww1g16

GPIO continuity

Tested all listed GPIO pins, and all come back as 0Ω

gpioget gpiochip0 25

With 3.3V connected to TfrRdy, returns 1
When disconnected, returns 0

Seems as expected

spidev_test.c

"./spidev_test -D /dev/spidev0.0" returns

spi mode: 4
bits per word: 8
max speed: 500000 Hz (500 KHz)

FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0D

Seems as expected, minus spi mode:4 but I found https://forums.raspberrypi.com/viewtopic.php?t=298486 which seems to suggest the following:

Set Get
0 4
1 5
2 6
3 7

Phaedrux

In cases like this I would suggest getting the Duet setup in standalone mode first with an SD card in the Duet and the Pi disconnected. If you can verify that the Duet is working correctly you can start adding the Pi into the mix. All the configuration you create for the standalone SD card can be copied over to the Pi setup, so it's not lost effort.

ww1g16

@phaedrux Thanks for the suggestion! I've gone ahead and set up the 6XD in standalone mode, and everything seems to have worked as expected. I'm able to connect via web interface, and all is looking like my other duet boards

I've also updated to the latest 3.4.3 release using Duet2and3Firmware-3.4.3.zip just to make sure everything is on the same page.

I've included the output of M122 below in case it becomes useful. How do you suggest I begin bringing the SBC back into the picture?

(excuse the heater faults, this is just a barebones config.g from the configurator and nothing is plugged into the 6XD other than USB and Ethernet)

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6XD version 3.4.3 (2022-10-05 09:07:12) running on Duet 3 MB6XD v1.0 or later (standalone mode)
Board ID: 08DLM-956DA-M2NS4-6J9DA-3S86Q-KA3LT
Used output buffers: 1 of 40 (13 max)
=== RTOS ===
Static ram: 151256
Dynamic ram: 96076 of which 0 recycled
Never used RAM 103340, free system stack 206 words
Tasks: NETWORK(ready,37.9%,227) ETHERNET(notifyWait,0.2%,423) HEAT(notifyWait,0.0%,360) Move(notifyWait,0.0%,351) CanReceiv(notifyWait,0.0%,943) CanSender(notifyWait,0.0%,335) CanClock(delaying,0.0%,343) MAIN(running,61.7%,1127) IDLE(ready,0.2%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:01:26 ago, cause: software
Last software reset at 2022-10-07 22:31, reason: User, GCodes spinning, available RAM 102148, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 1754
MCU temperature: min 33.0, current 34.9, max 35.2
Supply voltage: min 0.2, current 0.2, max 0.3, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 0.1, current 0.2, max 0.3, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 1 queued, 1 completed
Driver 0: ok
Driver 1: ok
Driver 2: ok
Driver 3: ok
Driver 4: ok
Driver 5: ok
Date/time: 2022-10-07 22:48:12
Slowest loop: 10.91ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.4ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
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 ===
Segments left: 0
Movement lock held by null
HTTP is idle 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
Code queue is empty
=== CAN ===
Messages queued 778, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 433/0/0
Tx timeouts 0,0,432,0,0,344 last cancelled message type 4514 dest 127
=== Network ===
Slowest loop: 10.91ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 1 of 8
= Ethernet =
State: active
Error counts: 0 0 0 1 0 0
Socket states: 5 2 2 2 2 0 0 0
=== Multicast handler ===
Responder is inactive, messages processed 0

Phaedrux

Now that you're certain the board is working and the firmware is up to date. I suggest downloading a fresh copy of DuetPi and a fresh SD card and try connecting again.

If you're still having issues we can take a deeper look with @dc42 and @chrishamm

ww1g16

Certaintly. So just to record the order of operations I'm going through:

Flash A2 SD card with DuetPi from https://pkg.duet3d.com/DuetPi.zip using BalenaEtcher
, setup wpa_supplicant
Add just flashed SD card to Pi4, remove the working card we just setup from the 6XD
Pi4 and 6XD connected with ribbon cable
Official USB C 5V3A power supply to Pi, generic USB C power supply to 6XD from a separate charger, default "Int 5V EN" jumper installed (all others not present)
Power on both, don't change anything else and just wait until duet3.local goes live

I can't get any further through DWC because of this 'Connecting...' window, but in the background you can see a mention of "Could not connect to Duet: Board is not available (no header))"

Remove power from Pi4, plug in HDMI, reconnect power to Pi4
Going through setup menu for language, wifi, etc, but pressing SKIP to downloading updates as that previously ended up never finishing.
Running sudo journalctl -u duetcontrolserver

Phaedrux

Please try a sudo apt update sudo apt upgrade again.

ww1g16

Here is the output of both of those commands, with 'upgrade' still running but after 30 mins of waiting at this stage, it look to have gotten stuck again at 'Setting up reprapfirmware (3.4.3-1)'. I've got to head out for a while, so I'll leave it running.

sudo_apt_get_update.txt
sudo_apt_get_upgrade.txt

Trying to navigate to DWC whilst that's going on results in:

"Failed to open IO device: Error 16. Cannot put line into event mode."

Phaedrux

Thanks for that. At this point I think your best bet is to run in standalone mode until @chrishamm returns and can take a look at your error messages.

chrishamm

@ww1g16 It looks like there is a problem with the SPI link between the Duet and SBC. Can you try out another cable and check if the problem persists? If it does, we can exchange your board. In that case please send a mail to warranty@duet3d.com, CC your reseller, and include a link to this thread.

ww1g16

@chrishamm Yup certainly. I'll get a couple ordered to give them a go, and then get back to you

ww1g16

@chrishamm Update now that the new ribbon cables have arrived, unfortunately still the same issue. To ensure there were no remnants from before, I repeated the steps from before: set it up in standalone mode (all okay), updated the firmware, removed the SD card from Duet, installed a fresh copy of DuetPi, and then went through the setup process on the Pi 4. But I'm still seeing the same warnings/error messages as posted above. I'll go ahead and email warranty@duet3d.com as suggested.

UPDATE: Email now sent