Duet not starting properly if SBC is not on

[kuon]

I just built a new printer with a brand new duet 6HC, and I have the following issue:

if the raspberry PI is not on before the duet, the PI cannot connect with the duet, and I have the following error in control server:

30 17:18:59 lili systemd[1]: Starting Duet Control Server...
Oct 30 17:18:59 lili DuetControlServer[669]: Duet Control Server v3.4.4
Oct 30 17:18:59 lili DuetControlServer[669]: Written by Christian Hammacher for Duet3D
Oct 30 17:18:59 lili DuetControlServer[669]: Licensed under the terms of the GNU Public License Version 3
Oct 30 17:19:00 lili DuetControlServer[669]: [info] Settings loaded
Oct 30 17:19:00 lili DuetControlServer[669]: [info] Environment initialized
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:00 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:02 lili DuetControlServer[669]: [warn] Restarting full transfer because a bad header format code was received (0xff)
Oct 30 17:19:02 lili DuetControlServer[669]: [fatal] Could not connect to Duet: Timeout while waiting for transfer ready pin
Oct 30 17:19:02 lili systemd[1]: duetcontrolserver.service: Main process exited, code=exited, status=69/UNAVAILABLE

If I start the PI, wait for it to boot, THEN start the duet, it works, but that's cumbersome because I would need a timed relay or something to sequence the power up.

There is no SD card in the duet.

[gloomyandy]

@kuon Do you have 3.4.4 firmware installed on the 6HC board?

[kuon]

Yes, everything is running 3.4.4

M122 report

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.4 (2022-10-20 16:19:01) running on Duet 3 MB6HC v1.01 (SBC mode)
Board ID: 08DJM-956BA-NA3TJ-6J9D6-3S46J-TB8US
Used output buffers: 1 of 40 (14 max)
=== RTOS ===
Static ram: 152824
Dynamic ram: 68024 of which 0 recycled
Never used RAM 129824, free system stack 200 words
Tasks: SBC(resourceWait:,0.7%,472) HEAT(notifyWait,0.0%,328) Move(notifyWait,0.0%,351) CanReceiv(notifyWait,0.0%,798) CanSender(notifyWait,0.0%,335) CanClock(delaying,0.0%,340) TMC(notifyWait,7.8%,91) MAIN(running,90.4%,1231) IDLE(ready,1.1%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:59 ago, cause: power up
Last software reset at 2022-10-29 23:58, reason: User, GCodes spinning, available RAM 128696, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Step timer max interval 131
MCU temperature: min 28.0, current 38.4, max 38.4
Supply voltage: min 23.8, current 23.9, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.1, under voltage events: 0
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: standstill, SG min 0, mspos 8, reads 2751, writes 11 timeouts 0
Driver 1: standstill, SG min 0, mspos 8, reads 2748, writes 14 timeouts 0
Driver 2: standstill, SG min 0, mspos 8, reads 2749, writes 14 timeouts 0
Driver 3: standstill, SG min 0, mspos 8, reads 2749, writes 14 timeouts 0
Driver 4: standstill, SG min 0, mspos 8, reads 2749, writes 14 timeouts 0
Driver 5: standstill, SG min 0, mspos 8, reads 2749, writes 14 timeouts 0
Date/time: 2022-10-30 20:41:08
Slowest loop: 1.55ms; fastest: 0.04ms
=== Storage ===
Free file entries: 10
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 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 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
Code queue is empty
=== CAN ===
Messages queued 567, received 2376, lost 0, boc 0
Longest wait 3ms for reply type 6053, peak Tx sync delay 6, free buffers 50 (min 49), ts 298/297/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 360/2533
SPI underruns 0, overruns 0
State: 5, disconnects: 1, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2ad08
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server v3.4.4
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 39.12, max time between full transfers: 36.7ms, max pin wait times: 27.6ms/1.2ms
Codes per second: 0.11
Maximum length of RX/TX data transfers: 3497/28

[kuon]

Also I noticed that the "status" LED on the mainboard is dim and not blinking, and the status led on toolboards is blinking quickly, like 2Hz.

[o_lampe]

@kuon said in Duet not starting properly if SBC is not on:

If I start the PI, wait for it to boot, THEN start the duet, it works, but that's cumbersome because I would need a timed relay or something to sequence the power up.

Would it be possible to add a G4 S60 command at the beginning of config.g to wait a minute?
Or maybe toggle an IO pin on the PI after boot, which allows Duet to boot? (hold down Duet reset button or the like)

[jay_s_uk]

@kuon the status LED being dim points to there being no firmware on the board.

[o_lampe]

@kuon said in Duet not starting properly if SBC is not on:

Yes, everything is running 3.4.4
M122 report

AFAIK, you must run M122 for each board separately. You've only posted the mainboard status...

[gloomyandy]

"Would it be possible to add a G4 S60 command at the beginning of config.g to wait a minute?"
@o_lampe The problem is that you can't read the config.g file if there is no SBC to provide it....

[kuon]

@o_lampe Yes, and they are all running 3.4.4. But when I tried to fix the issue, the toolboard where disconnected so I didn't think of including the M122 output.

I think the issue occurs even before the duet can start loading the config.g or anything. It just stays here.

[kuon]

I also tried pressing the reset button, but it doesn't do anything. Power cycling the duet fixes the issue and the duet connects to the SBC. But this doesn't help, as I would need to power up the duet after the SBC had booted, and this would require an additional timed relay.

@dc42 what is the duet looking for when booting to try to communicate with the SBC? Should a pin on the ribbon be pulled up and it arrives too late in my case?

[kuon]

I think I found the issue, my 5V power supply for my PI takes about 500ms to run to a steady 5V, but the Duet regulator is faster, (I clearly see a sequence in the LEDs) and what I think is happening is that the duet sees that the 5V pin for the PI is not at 5V and then ignores it (@dc42 might be able to confirm this).

I have removed the INT 5V EN jumper, and I am now providing the duet 5V from the power supply I use for the PI through the EXT 5V KK connector and the issue is gone.

[o_lampe]

@kuon The problem wit RasPi powersupplies is: they produce a little more than 5V. Just check out your'e not toasting the other 5V components with it.

[kuon]

@o_lampe It is a power supply I made myself to convert from 24V, and it has a regulated 5V output which I measured between 4.95 and 5.06V with my scope, so I guess it should be fine.

[dc42]

@o_lampe the Duet is quite happy with a little more than 5V such as the 5.2V typically provided by RPi PSUs. The absolute maximum is 6.5V or 7V AFAIR.

[kuon]

@dc42 Is the behaviour I am observing normal? I mean the duet ignoring the SBC if SBC's 5V comes a bit late after duet powering up.