RRF3.2alpha - M409 F"d5" causes Duet2Wifi to reboot
-
I know that I'm a bit out in the deep end, but on my self-built RRF 3.2alpha buld (for the kinematics development) I was reliably able to cause the board (Duet2Wifi 1.3) to spontaneously reboot when issuing
M409 F"d5"(no matter whether I choose specific keys or not).M409 F"d4"does not cause this, even with keys that have a max depth of 3, likeboards.(All this while I'm not able to make my kinematics entries surface in the object model, but that's likely my lack of C++ fu).
-
Forgot to include
M122output after a spontaneous reboot. Here goes:M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.02-alpha running on Duet WiFi 1.02 or later Board ID: 08DGM-956GU-DJMSN-6J1DG-3SN6K-9UNZF Used output buffers: 3 of 24 (24 max) === RTOS === Static ram: 27940 Dynamic ram: 93012 of which 60 recycled Exception stack ram used: 272 Never used ram: 9788 Tasks: NETWORK(ready,448) HEAT(blocked,948) MAIN(running,1820) IDLE(ready,80) Owned mutexes: WiFi(NETWORK) === Platform === Last reset 00:04:04 ago, cause: software Last software reset at 2020-05-30 14:09, reason: User, spinning module GCodes, available RAM 9816 bytes (slot 2) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04433000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN Error status: 4 MCU temperature: min 34.3, current 38.1, max 38.3 Supply voltage: min 24.5, current 24.6, max 24.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: 2020-05-31 10:33:57 Cache data hit count 422045362 Slowest loop: 18.86ms; fastest: 0.16ms 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 3.8ms, write time 6.5ms, 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: 41.35ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.23 WiFi MAC address 5c:cf:7f:76:6e:6e WiFi Vcc 3.40, reset reason Unknown WiFi flash size 4194304, free heap 22200 WiFi IP address 192.168.86.203 WiFi signal strength -56dBm, reconnections 0, sleep mode modem Socket states: 0 0 0 0 0 0 0 0 -
Thanks for your report. Unfortunately your M122 report indicates that the last reboot was caused by M999 or emergency stop or firmware update, not anything untowards. if you are able to make this happen again and M122 shows a software reset code other than 0x0003, please post that M122 report.
-
Reading closer, it looks like it's DWC that is disconnecting and connecting again (on repeat, reset time from M122 was 11:32, it's 15:04 here). So this needs to go to DWC/@chrishamm I presume.
-
Reading a bit of source code, I'm almost sure this is because HttpResponder emits a serviceUnavailableResponse which DWC passes on (correctly). So this is working as implemented and not a bug (-:
-
Yes, that's what happens when a response to an HTTP command is too big to fit in the available output buffers.
