Crash in firmware on M956 3.4.5->3.5.0-beta.4

r3cvr

To reproduce in console:
M955 P0 C"spi.cs4+spi.cs3" I25
M955 P0
Accelerometer 0 type LIS3DH with orientation 25 samples at 1344Hz with 10-bit resolution, SPI frequency 2000000
M956 P0 S1000 A0
<crash>

Was intermittently working (I captured many traces) and crashing, but now consistently crashing for some reason.

config-3.g

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.0-beta.4 (2023-06-08 23:39:39) running on Duet WiFi 1.02 or later
Board ID: 08DGM-956GU-DJMSJ-6J9FG-3SD6J-9UPHG
Used output buffers: 1 of 26 (24 max)
Error in macro line 56 while starting up: Heater 0 not found
=== RTOS ===
Static ram: 23236
Dynamic ram: 77116 of which 12 recycled
Never used RAM 9924, free system stack 164 words
Tasks: NETWORK(1,ready,15.4%,219) HEAT(3,nWait,0.1%,329) Move(4,nWait,0.0%,364) MAIN(1,running,84.0%,743) IDLE(0,ready,0.5%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:03:23 ago, cause: software
Last software reset at 2023-06-18 18:55, reason: HeatTaskStuck, Gcodes spinning, available RAM 7780, slot 0
Software reset code 0x0143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x20004770 Task ACCE Freestk 4294946641 ok
Stack: 20005958 2000412c 20000150 e000e000 006af974 0045f435 0045ddf6 6100f000 00000001 e000e000 0045f435 2000d0e0 00023264 2000d110 0043104b 2000d0e0 a5a5a5a5 a5a5a5a5 20004bb4 a5a5a5a5 004310ef a5a5a5a5 0045dd1d a5a5a5a5 00000000 00000000 00000000
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 30.5, current 32.2, max 32.7
Supply voltage: min 24.3, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/2, heap memory allocated/used/recyclable 2048/32/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min n/a
Driver 2: standstill, SG min n/a
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Date/time: 2023-06-18 18:59:03
Cache data hit count 4294967295
Slowest loop: 133.66ms; fastest: 0.19ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 0.7ms, 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, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
=== DDARing 0 ===
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
Heater 2 is on, I-accum = 0.0
=== GCodes ===
Movement locks 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 0
Code queue 0 is empty
=== Network ===
Slowest loop: 61.46ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= WiFi =
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
Firmware version 1.27
MAC address 5c:cf:7f:76:6c:93
Module reset reason: Turned on by main processor, Vcc 3.36, flash size 4194304, free heap 21968
WiFi IP address 192.168.1.188
Signal strength -48dBm, channel 0, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

dc42

@r3cvr the usual reason for resets while collecting accelerometer data is noise on the accelerometer INT or CS signal, causing an excessive number of interrupts. Keep the accelerometer cable well away from stepper motor cables in particular.

r3cvr

@dc42 It may have been a signal issue the first time, however I don't think it is anymore when it won't stop crashing despite rebooting itself. I see when it gets stuck - I had the usb console hooked up hoping to see some output on it, which means that the duet wasn't completely power cycled even when I attempted to hard power cycle it. Anyway, there is some left-over state maybe in the lis3dh itself that causes this crash even after it reboots, and there is no longer a signal issue, at least temporarily.