significant "Warning: SPI connection has been reset"

Nuramori

Things were fine before I updated to 3.5.2, now I can barely get through homing the printhead before it fails.
I am on "Bookworm"

Here's the M122:

6/26/2024, 12:10:44 AM	m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.2 (2024-06-11 17:13:58) running on Duet 3 MB6HC v1.0 or earlier (SBC mode)
Board ID: 08DJM-956L2-G43S4-6J1F2-3SJ6T-1A6QH
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 155360
Dynamic ram: 90232 of which 4656 recycled
Never used RAM 73256, free system stack 143 words
Tasks: SBC(2,rWait:,0.7%,797) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,0.0%,234) CanReceiv(6,nWait 1,0.0%,771) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,339) TMC(4,nWait 6,9.6%,53) MAIN(2,running,89.6%,101) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:23:42 ago, cause: power up
Last software reset at 2024-06-25 23:38, reason: User, Gcodes spinning, available RAM 73328, slot 1
Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 38.4, current 39.1, max 40.0
Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.0, max 12.0, under voltage events: 0
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/288/288, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a, mspos 856, reads 60402, writes 0 timeouts 0
Driver 1: standstill, SG min n/a, mspos 424, reads 60401, writes 0 timeouts 0
Driver 2: standstill, SG min 19, mspos 888, reads 60400, writes 2 timeouts 0
Driver 3: standstill, SG min 0, mspos 984, reads 60400, writes 2 timeouts 0
Driver 4: standstill, SG min n/a, mspos 456, reads 60402, writes 0 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 60402, writes 0 timeouts 0
Date/time: 2024-06-26 00:09:45
Slowest loop: 24.91ms; fastest: 0.08ms
=== 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 18, maxWait 132035ms, 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 1, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 123, completed 123, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], 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
=== 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 0x80000007
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 422, received 936, lost 0, errs 0, boc 0
Longest wait 1ms for reply type 6013, peak Tx sync delay 6, free buffers 50 (min 49), ts 234/234/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 51918/277
SPI underruns 0, overruns 0
State: 5, disconnects: 9, timeouts: 9 total, 9 by SBC, IAP RAM available 0x24cfc
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: 32.53, max time between full transfers: 30.8ms, max pin wait times: 26.8ms/0.1ms
Codes per second: 0.06
Maximum length of RX/TX data transfers: 4379/1428
6/26/2024, 12:10:37 AM	Warning: SPI connection has been reset

chrishamm

@Nuramori said in significant "Warning: SPI connection has been reset":

State: 5, disconnects: 9, timeouts: 9 total, 9 by SBC, IAP RAM available 0x24cfc

Those resets were caused by the SBC. What kind of microSD card do you have? Is it possible that you enabled debug logging at some point in /opt/dsf/conf/config.json? And do you have enough free space on the card, does it have enough voltage to ensure that the CPU isn't throttled? And can you confirm that the Pi has no excessive load spikes?

Nuramori

@chrishamm said in significant "Warning: SPI connection has been reset":

@Nuramori said in significant "Warning: SPI connection has been reset":

State: 5, disconnects: 9, timeouts: 9 total, 9 by SBC, IAP RAM available 0x24cfc

Those resets were caused by the SBC. What kind of microSD card do you have? Is it possible that you enabled debug logging at some point in /opt/dsf/conf/config.json? And do you have enough free space on the card, does it have enough voltage to ensure that the CPU isn't throttled? And can you confirm that the Pi has no excessive load spikes?

I have this card:
SanDisk 128GB Ultra microSDXC UHS-I Memory Card with Adapter - Up to 140MB/s, C10, U1, Full HD, A1, MicroSD Card - SDSQUAB-128G-GN6MA [New Version]

It’s running on a new Pi5 with 8gig memory. It has a lot of free space, as it was not an upgraded OS, but built clean off of raspianOS bookworm using the guidelines (I then moved my previous config files over onto the new SBC.).

Firmware 3.5.1 was running on this SBC without an issue.

I’ll check on the debug setting. There’s nothing else running on the SBC.

I have a dedicated meanwell PSU for the Pi5, and voltages are spot on, and ample amp supply for it.

Nuramori

@chrishamm logging level is set to "info"

This is the top portion of the config.json file.

"AutoUpdateFirmware": true,
  "PluginSupport": true,
  "RootPluginSupport": false,
  "PluginsFilename": "/opt/dsf/conf/plugins.txt",
  "PluginAutoRestartInterval": 2000,
  "LogLevel": "info",
  "SocketDirectory": "/run/dsf",
  "SocketFile": "dcs.sock",
  "StartErrorFile": "/run/dsf/dcs.err",
  "Backlog": 4,
  "SocketPollInterval": 2000,
  "BaseDirectory": "/opt/dsf/sd",
  "PluginDirectory": "/opt/dsf/plugins",
  "NoTerminateOnReset": false,
  "HostUpdateInterval": 4000,
  "MaxMessageAge": 60,
  "SpiDevice": "/dev/spidev0.0",
  "SpiBufferSize": 8192,
  "SpiTransferMode": 0,
  "SpiFrequency": 8000000,
  "SpiConnectTimeout": 500,
  "SpiTransferTimeout": 500,
  "SpiConnectionTimeout": 4000,
  "MaxSpiRetries": 3,
  "GpioChipDevice": "/dev/gpiochip4",
  "TransferReadyPin": 25,
  "CpuTemperaturePath": "/sys/class/thermal/thermal_zone0/temp",
  "CpuTemperatureDivider": 1000,
  "BufferedPrintCodes": 32,
  "BufferedMacroCodes": 16,
  "MaxCodesPerInput": 32,
  "MaxBufferSpacePerChannel": 1536,
  "MaxCodeBufferSize": 256,
  "MaxMessageLength": 4096,
  "FirmwareComments": [
    "printing object",
    "MESH",
    "process",
    "stop printing object",
    "layer",
    "LAYER",
    "BEGIN_LAYER_OBJECT z=",
    "HEIGHT",
    "PRINTING",
    "REMAINING_TIME"
  ],
  "ModelUpdateInterval": 250,
  "MaxMachineModelLockTime": -1,
  "FileBufferSize": 32768,
  "FileInfoReadLimitHeader": 16384,
  "FileInfoReadLimitFooter": 262144,
  "MaxLayerHeight": 0.9,
  "LayerHeightFilters": [

Nuramori

@chrishamm A quick update. On an intuitive guess, I performed a "rpi-update" to update the Pi5 firmware. This seems to be working so far, as I have not had any issues at the moment, and am running a print. I will report back if this proves to be successful.

Nuramori

@chrishamm so far so good. It looks like all the reset issues have gone away.