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, like boards.

    (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 M122 output 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
    

  • administrators

    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 (-:


  • administrators

    Yes, that's what happens when a response to an HTTP command is too big to fit in the available output buffers.


Log in to reply