System reset during print - RRF3.1.0
-
I know RRF3.1.1 is out but I wanted to give this report incase this isn't one of the reported bugs.
I was 99% through a print and had a reset. Fortunately my print is fine and I can live without the last 1%.Here is an M122 report
m122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.0 running on Duet Ethernet 1.02 or later Board ID: 08DGM-9T6BU-FG3S4-6JTDL-3SD6Q-9SRMF Used output buffers: 1 of 24 (11 max) === RTOS === Static ram: 28180 Dynamic ram: 92348 of which 64 recycled Exception stack ram used: 248 Never used ram: 10232 Tasks: NETWORK(ready,136) HEAT(blocked,1224) MAIN(running,1816) IDLE(ready,80) Owned mutexes: === Platform === Last reset 00:00:10 ago, cause: software Last software reset at 2020-05-19 17:35, reason: Stack overflow, spinning module none, available RAM 9836 bytes (slot 0) Software reset code 0x4111 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f80e BFAR 0xe000ed38 SP 0x2001ffb4 Task NETW Stack: 20002860 20002894 00455625 00000000 00000000 200029b8 20002a54 0000000a 00454c35 200028c4 200055f4 Error status: 0 MCU temperature: min 37.4, current 37.7, max 38.1 Supply voltage: min 23.8, current 23.9, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: standstill, SG min/max not available Driver 1: standstill, SG min/max not available Driver 2: standstill, SG min/max not available Driver 3: standstill, SG min/max not available Driver 4: standstill, SG min/max not available Date/time: 1970-01-01 00:00:00 Cache data hit count 16561366 Slowest loop: 2.42ms; fastest: 0.13ms 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.6ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 8.19ms; fastest: 0.02ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 Interface state active, link 100Mbps full duplex
I can provide other information if required.
-
@jay_s_uk said in System reset during print - RRF3.1.0:
Task
Thanks for the report, but I am almost 100% sure this problem has been fixed in RRF 3.1.1.
-
Thanks for the quick answer. I shall be on my merry way...
-
Yes, that problem is the reason why I wanted to release RRF 3.1.1 so soon after 3.1.0. You can find the history at https://forum.duet3d.com/topic/16390/3-1-0-firmware-reboots-periodically/31. I've never been able to reproduce it, but the M122 report made it clear what the problem was.