Random reboot?



  • Last reset 00:04:02 ago, cause: software
    Last software reset at 2020-05-11 00:56, reason: Stuck in spin loop, spinning module GCodes, available RAM 8372 bytes (slot 0)
    Software reset code 0x4043 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f80f BFAR 0xe000ed38 SP 0x20001f74 Task 0x5754454e
    Stack: 00404541 0040467a 61000000 00000000 00000000 00000000 00000000 3e178897 3e1cd04f 41700000 3e3a339e 3e638ea6 41cd957a 00000000 47608000 37d33333 4354c416 00000000 00000000 60000010 00404659 00000800 200180b8

    What does this reset code mean? What was it doing -- I've had a few random reboots -- usually after a print.


  • administrators

    Which Duet, and what firmware version?



  • Duet Ethernet with Duex5 - V2.05.1



  • @dc42 another random reboot -- right at the start of the print -- during homing routine

    Last reset 00:54:25 ago, cause: software
    Last software reset at 2020-05-14 09:22, reason: Stuck in spin loop, spinning module GCodes, available RAM 8372 bytes (slot 3)
    Software reset code 0x4043 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x20001f9c Task 0x5754454e
    Stack: 0040453b 004048be 81000000 422e23d8 41231c2c 00000000 c0000000 3e178897 3e1cd04f 41880000 3e3a332a 3e638e2e 419e24dd 00000000 475a4500 37d33333 4354c416 a0000000 0000002b 80000010 000003c8 200180b8 004060ed



  • @dc42 keeps doing it periodically
    11:05:23 PMM122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05.1 running on Duet Ethernet 1.02 or later + DueX5
    Board ID: 08DGM-9T6BU-FG3S0-7JTD4-3S06K-1A4ZD
    Used output buffers: 1 of 24 (15 max)
    === RTOS ===
    Static ram: 25708
    Dynamic ram: 96296 of which 0 recycled
    Exception stack ram used: 320
    Never used ram: 8748
    Tasks: NETWORK(ready,752) HEAT(blocked,1236) DUEX(suspended,168) MAIN(running,3724) IDLE(ready,156)
    Owned mutexes:
    === Platform ===
    Last reset 00:04:23 ago, cause: software
    Last software reset at 2020-05-29 23:00, reason: Stuck in spin loop, spinning module GCodes, available RAM 8372 bytes (slot 2)
    Software reset code 0x4043 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x2000323c Task 0x454c4449
    Stack: 00445ad1 00444aba 61000000 a5a5a5a5 00445ad1 a5a5a5a5 a5a5a5a5 20003264 20003104 00000002 200048ec 02a70ba0 20004cf4 20001780 20003264 20004cec 00000004 200030dc 20001794 20003264 200030d4 00000001 200032bc
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms, max retries 0
    MCU temperature: min 25.1, current 25.2, max 26.9
    Supply voltage: min 24.3, current 24.7, max 24.8, 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
    Driver 5: standstill, SG min/max not available
    Driver 6: standstill, SG min/max not available
    Driver 7: standstill, SG min/max not available
    Driver 8: standstill, SG min/max not available
    Driver 9: standstill, SG min/max not available
    Date/time: 2020-05-29 23:05:22
    Cache data hit count 531514393
    Slowest loop: 4.08ms; fastest: 0.07ms
    I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
    === Move ===
    Hiccups: 0, FreeDm: 160, MinFreeDm: 160, MaxWait: 0ms
    Bed compensation in use: none, comp offset 0.000
    === DDARing ===
    Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 0 is on, I-accum = 0.3
    Heater 1 is on, I-accum = 0.0
    === GCodes ===
    Segments left: 0
    Stack records: 1 allocated, 0 in use
    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
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 7.24ms; fastest: 0.02ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 2 of 8
    Interface state 5, link 100Mbps full duplex



  • With 2.05.1 i get randomly disconnected as well...i just get back to 2.04 and all are fine now(duet wifi)


  • administrators

    @kazolar, I suspect the problem is too many interrupts arriving from the DueX, causing the main processor to spend too much time servicing them. So:

    1. Do you have any endstops or other inputs connected to the DueX? If so, what sort of devices are connected? If they are endstop switches, are the wired NO or NC?

    2. Are you able to upgrade to RRF 3.1.1? That release has additional diagnostics, in particular it reports the I2C transaction rate.



  • @dc42 i have duex5 fully loaded with end stops -- I've mentioned it before, I NEVER use NO end stops. I plan on upgrading to v3 -- but due to ongoing need for PPE, I am still printing shields, so don't have time to do that -- I will move the boards into a new case to make wiring much easier to see. This generally happens very infrequently, normally it happens right at the start of a print. My start is heat up the bed to 75, heat 3 extruders to 140, home call bed probe routine then park and heat up to final temp -- the last part is where it tends to reboot - it has done all the probe triggering and is just waiting.


  • administrators

    Just a thought: if you are parking the machine with one or more axes against the endstop switches while it is heating, try moving the head slightly away from the endstop so that it is no longer triggered.



  • @dc42 ok, so, normal condition for the triplicate print is the 4th tool is inactive and is parked and obviously triggering an endstop, the heat up actually starts right after the probing completes and several optical end stops are triggered at that point. I have an option to run gcode that backs them all off the trigger point, I'll do that next time, but unlike the i2c emi issue, this one is really hard to hit, it happens ones every 5-10 days.


Log in to reply