Firmware 1.20 released
-
As I work with embedded systems myself I see the typical symptoms of a stack crash. While watching the output from the serial line I could observe some kind of "hartbeat" messages from classes running inside the Duet. All seems normal until I plug the ethernet cable in. Then everything just stops.
-
If you run M122 from USB, how much free memory does it report?
-
I'm not sure wich number you're after so I copied the entire response:
[c]17:34:17.138 : serial: M122
17:34:17.143 : LINK
17:34:17.145 : xmit: 0
17:34:17.145 : recv: 0
17:34:17.145 : fw: 0
17:34:17.145 : drop: 0
17:34:17.145 : chkerr: 0
17:34:17.145 : lenerr: 0
17:34:17.145 : memerr: 0
17:34:17.145 : rterr: 0
17:34:17.145 : proterr: 0
17:34:17.145 : opterr: 0
17:34:17.145 : err: 0
17:34:17.145 : cachehit: 0
17:34:17.145 : ETHARP
17:34:17.145 : xmit: 0
17:34:17.145 : recv: 0
17:34:17.145 : fw: 0
17:34:17.145 : drop: 0
17:34:17.145 : chkerr: 0
17:34:17.145 : lenerr: 0
17:34:17.145 : memerr: 0
17:34:17.145 : rterr: 0
17:34:17.146 : proterr: 0
17:34:17.146 : opterr: 0
17:34:17.146 : err: 0
17:34:17.146 : cachehit: 0
17:34:17.146 : IP_FRAG
17:34:17.146 : xmit: 0
17:34:17.146 : recv: 0
17:34:17.146 : fw: 0
17:34:17.146 : drop: 0
17:34:17.146 : chkerr: 0
17:34:17.146 : lenerr: 0
17:34:17.146 : memerr: 0
17:34:17.146 : rterr: 0
17:34:17.146 : proterr: 0
17:34:17.146 : opterr: 0
17:34:17.146 : err: 0
17:34:17.146 : cachehit: 0
17:34:17.146 : IP
17:34:17.146 : xmit: 0
17:34:17.146 : recv: 0
17:34:17.146 : fw: 0
17:34:17.146 : drop: 0
17:34:17.146 : chkerr: 0
17:34:17.146 : lenerr: 0
17:34:17.147 : memerr: 0
17:34:17.147 : rterr: 0
17:34:17.147 : proterr: 0
17:34:17.147 : opterr: 0
17:34:17.147 : err: 0
17:34:17.147 : cachehit: 0
17:34:17.147 : IGMP
17:34:17.147 : xmit: 0
17:34:17.147 : recv: 0
17:34:17.147 : drop: 0
17:34:17.147 : chkerr: 0
17:34:17.147 : lenerr: 0
17:34:17.147 : memerr: 0
17:34:17.147 : proterr: 0
17:34:17.147 : rx_v1: 0
17:34:17.147 : rx_group: 0
17:34:17.147 : rx_general: 0
17:34:17.147 : rx_report: 0
17:34:17.147 : tx_join: 0
17:34:17.148 : tx_leave: 0
17:34:17.148 : tx_report: 0
17:34:17.148 :
17:34:17.148 : ICMP
17:34:17.148 : xmit: 0
17:34:17.148 : recv: 0
17:34:17.148 : fw: 0
17:34:17.148 : drop: 0
17:34:17.148 : chkerr: 0
17:34:17.148 : lenerr: 0
17:34:17.148 : memerr: 0
17:34:17.148 : rterr: 0
17:34:17.148 : proterr: 0
17:34:17.148 : opterr: 0
17:34:17.148 : err: 0
17:34:17.148 : cachehit: 0
17:34:17.148 : UDP
17:34:17.148 : xmit: 0
17:34:17.148 : recv: 0
17:34:17.148 : fw: 0
17:34:17.148 : drop: 0
17:34:17.148 : chkerr: 0
17:34:17.148 : lenerr: 0
17:34:17.148 : memerr: 0
17:34:17.149 : rterr: 0
17:34:17.149 : proterr: 0
17:34:17.149 : opterr: 0
17:34:17.149 : err: 0
17:34:17.149 : cachehit: 0
17:34:17.149 : TCP
17:34:17.149 : xmit: 0
17:34:17.149 : recv: 0
17:34:17.149 : fw: 0
17:34:17.149 : drop: 0
17:34:17.149 : chkerr: 0
17:34:17.149 : lenerr: 0
17:34:17.149 : memerr: 0
17:34:17.149 : rterr: 0
17:34:17.149 : proterr: 0
17:34:17.149 : opterr: 0
17:34:17.149 : err: 0
17:34:17.149 : cachehit: 0
17:34:17.149 : MEM HEAP
17:34:17.149 : avail: 1024
17:34:17.150 : used: 0
17:34:17.150 : max: 0
17:34:17.150 : err: 0
17:34:17.150 : MEM UDP_PCB
17:34:17.150 : avail: 5
17:34:17.150 : used: 2
17:34:17.150 : max: 2
17:34:17.150 : err: 0
17:34:17.150 : MEM TCP_PCB
17:34:17.150 : avail: 16
17:34:17.150 : used: 0
17:34:17.150 : max: 0
17:34:17.150 : err: 0
17:34:17.150 : MEM TCP_PCB_LISTEN
17:34:17.151 : avail: 4
17:34:17.151 : used: 0
17:34:17.151 : max: 0
17:34:17.151 : err: 0
17:34:17.151 : MEM TCP_SEG
17:34:17.151 : avail: 16
17:34:17.151 : used: 0
17:34:17.151 : max: 0
17:34:17.151 : err: 0
17:34:17.151 : MEM REASSDATA
17:34:17.151 : avail: 2
17:34:17.151 : used: 0
17:34:17.151 : max: 0
17:34:17.151 : err: 0
17:34:17.151 : MEM FRAG_PBUF
17:34:17.151 : avail: 8
17:34:17.151 : used: 0
17:34:17.151 : max: 0
17:34:17.151 : err: 0
17:34:17.151 : MEM IGMP_GROUP
17:34:17.152 : avail: 8
17:34:17.152 : used: 0
17:34:17.152 : max: 0
17:34:17.152 : err: 0
17:34:17.152 : MEM SYS_TIMEOUT
17:34:17.152 : avail: 8
17:34:17.152 : used: 6
17:34:17.152 : max: 6
17:34:17.152 : err: 0
17:34:17.152 : MEM PBUF_REF/ROM
17:34:17.152 : avail: 4
17:34:17.152 : used: 0
17:34:17.152 : max: 0
17:34:17.152 : err: 0
17:34:17.152 : MEM PBUF_POOL
17:34:17.152 : avail: 5
17:34:17.152 : used: 0
17:34:17.152 : max: 0
17:34:17.152 : err: 0
17:34:17.152 : === Diagnostics ===
17:34:17.153 : Used output buffers: 1 of 32 (15 max)
17:34:17.153 : === Platform ===
17:34:17.153 : RepRapFirmware for Duet version 1.20.1RC2 running on Duet 0.6
17:34:17.153 : Static ram used: 44836
17:34:17.153 : Dynamic ram used: 40508
17:34:17.153 : Recycled dynamic ram: 672
17:34:17.153 : Stack ram used: 3520 current, 5528 maximum
17:34:17.153 : Never used ram: 6760
17:34:17.154 : Last reset 00:07:46 ago, cause: power up
17:34:17.154 : Last software reset time unknown, reason: Stuck in spin loop, spinning module Network, available RAM 8620 bytes (slot 2)
17:34:17.154 : Software reset code 0x2041 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0x20087e6c
17:34:17.155 : Stack: 000bfb1f 01c8a8c0 fffffff9 00ffffff 20087ebc 20070fe8 01c8a8c0 20087ebc 000a6221 000a6220 21000000 20087ea0 2007a938 00000000 2007376c 200737a8 20087ebc 0000012c 2007aea8 75207369 01c8a8c0 2007376c 000a5b1d 2001376c
17:34:17.155 : Error status: 0
17:34:17.155 : Free file entries: 10
17:34:17.155 : SD card 0 detected, interface speed: 21.0MBytes/sec
17:34:17.155 : SD card longest block write time: 0.0ms
17:34:17.155 : MCU temperature: min 26.2, current 27.3, max 27.8
17:34:17.156 : Date/time: 1970-01-01 00:00:00
17:34:17.156 : Slowest main loop (seconds): 0.009165; fastest: 0.000104
17:34:17.156 : === Move ===
17:34:17.156 : MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, MaxWait: 0ms, Underruns: 0, 0
17:34:17.156 : Scheduled moves: 0, completed moves: 0
17:34:17.156 : Bed compensation in use: none
17:34:17.157 : Bed probe heights: 0.000 0.000 0.000 0.000 0.000
17:34:17.157 : === Heat ===
17:34:17.157 : Bed heaters = 0, chamberHeaters = -1 -1
17:34:17.157 : === GCodes ===
17:34:17.157 : Segments left: 0
17:34:17.157 : Stack records: 1 allocated, 0 in use
17:34:17.157 : Movement lock held by null
17:34:17.157 : http is idle in state(s) 0
17:34:17.157 : telnet is idle in state(s) 0
17:34:17.157 : file is idle in state(s) 0
17:34:17.157 : serial is ready with "M122" in state(s) 0
17:34:17.158 : aux is idle in state(s) 0
17:34:17.158 : daemon is idle in state(s) 0
17:34:17.158 : queue is idle in state(s) 0
17:34:17.158 : autopause is idle in state(s) 0
17:34:17.158 : Code queue is empty.
17:34:17.158 : === Network ===
17:34:17.158 : Free connections: 16 of 16
17:34:17.158 : Free transactions: 24 of 24
17:34:17.158 : Locked: 0, state: 2, listening: 0x0, 0x0, 0x0
[/c] -
The "heartbeat" message
[c]17:36:25.475 : N151 M10534
17:36:25.476 : serial: M105
17:36:28.535 : N152 M10533
17:36:28.537 : serial: M105
17:36:31.062 : Class GCodes spinning
17:36:31.062 : Class Move spinning
17:36:31.062 : Class Platform spinning
17:36:31.062 : Class Network spinning
17:36:31.062 : Class Network spinning
17:36:31.064 : Class Heat spinning
17:36:31.064 : Class PrintMonitor spinning
17:36:31.601 : N153 M10532
17:36:31.602 : serial: M105
17:36:34.660 : N154 M10539
17:36:34.661 : serial: M105
17:36:37.720 : N155 M10538
17:36:37.721 : serial: M105
17:36:40.786 : N156 M10537
17:36:40.787 : serial: M105
[/c] -
I upgraded my Duet WiFi firmware from 1.19 to 1.20 yesterday. All seems to be working but I'm getting strange error messages when I start a print. They start at layer 0 but I was slow to capture them - each layer gives an error like this:
[c]17:34:59Error: Bad command: // starting layer 19 at 2.47368mm
17:34:47Error: Bad command: // starting layer 18 at 2.4mm
17:34:35Error: Bad command: // starting layer 17 at 2.2mm
17:34:24Error: Bad command: // starting layer 16 at 2.18947mm
17:34:12Error: Bad command: // starting layer 15 at 2mm
17:34:01Error: Bad command: // starting layer 14 at 1.90526mm
17:33:49Error: Bad command: // starting layer 13 at 1.8mm
17:33:37Error: Bad command: // starting layer 12 at 1.62105mm
[/c]The print worked OK but layer height was 0.2mm so I'm a little surprised by some of the layer heights.
What does this mean, please?
Thanks.
Richard
(edited to correct the starting layer from 1 to 0)
-
OK, I figured out what it is. The slicer was adding a comment to the beginning of each layer. This was in the format "// starting layer [layer_num] at [layer_z]mm"
The // was being interpreted as a comment but is no longer being interpreted so. I have changed the setting to "; starting layer [layer_num] at [layer_z]mm" and will try this as soon as I have finished the running print and can try another.
I'll report back once I confirm that this is the issue and is sorted.
-
This is confirmed - it was a slicer setting, nothing at all to do with the Duet firmware but a bit strange that the prior version didn't report errors with that format. Anyway, all sorted, thanks.
OK, I figured out what it is. The slicer was adding a comment to the beginning of each layer. This was in the format "// starting layer [layer_num] at [layer_z]mm"
The // was being interpreted as a comment but is no longer being interpreted so. I have changed the setting to "; starting layer [layer_num] at [layer_z]mm" and will try this as soon as I have finished the running print and can try another.
I'll report back once I confirm that this is the issue and is sorted.
-
This is confirmed - it was a slicer setting, nothing at all to do with the Duet firmware but a bit strange that the prior version didn't report errors with that format. Anyway, all sorted, thanks.
OK, I figured out what it is. The slicer was adding a comment to the beginning of each layer. This was in the format "// starting layer [layer_num] at [layer_z]mm"
The // was being interpreted as a comment but is no longer being interpreted so. I have changed the setting to "; starting layer [layer_num] at [layer_z]mm" and will try this as soon as I have finished the running print and can try another.
I'll report back once I confirm that this is the issue and is sorted.
It's because RRF now recognises lower case command letters, and also parses lines of gcode more thoroughly.
-
I'm not sure wich number you're after so I copied the entire response:
…
17:34:17.154 : Last reset 00:07:46 ago, cause: power up
17:34:17.154 : Last software reset time unknown, reason: Stuck in spin loop, spinning module Network, available RAM 8620 bytes (slot 2)
17:34:17.154 : Software reset code 0x2041 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0x20087e6c
17:34:17.155 : Stack: 000bfb1f 01c8a8c0 fffffff9 00ffffff 20087ebc 20070fe8 01c8a8c0 20087ebc 000a6221 000a6220 21000000 20087ea0 2007a938 00000000 2007376c 200737a8 20087ebc 0000012c 2007aea8 75207369 01c8a8c0 2007376c 000a5b1d 2001376c
...Thanks, that should help me to track the problem down.
-
@dc42
I've gone back to 1.19 while your busy finding the rodent messing around in the Network task in the 0.6 hardware. I kept the newest DWC and found that this also works with 1.19 FW. Nice with some new functionality. I'm not sure wether all the new controls works for real with 1.19 but the extended system edit possibilities are welcome. -
I have it on my list to investigate your report before the 1.20.1 release, however I need to get the prototype laser filament sensors completed and shipped first to avoid additional delay to production of filament sensors.
-
Just tried to upgrade from 1.19 to 1.20. I've uploaded DuetWifiFirmware.bin, but I cannot connect anymore to the printer via wireless. Any idea?
-
Adding some bits. I also tried connecting through USB but the serial device is not recognized by my linux machine (before upgrading used to work).
EDIT: i have tried the fallback procedure #2 described at https://duet3d.com/wiki/Updating_main_firmware but it still doesn't work. -
The USB interface code did not change between 1.19 and 1.20, so I don't understand why you can't access the Duet over USB any more. Do you have any evidence that the firmware update succeeded in other ways, e.g. because an attached PanelDue is working?
-
I don't own a PanelDue. I don't know how to debug this.
-
So as far as you know, the board isn't running at all. See https://duet3d.com/wiki/What_to_do_if_your_Duet_or_Duet_WiFi_won%27t_respond.
-
I just want to report that the github link on this wiki page is broken. https://duet3d.com/wiki/Updating_main_firmware
-
I just want to report that the github link on this wiki page is broken. https://duet3d.com/wiki/Updating_main_firmware
Works for me. Maybe it got fixed between your post and mine?
-
Works for me. Maybe it got fixed between your post and mine?
Weird…I still get a 404 when I try the link.
-
I just tried it again (using the link in deckingman's post above) and it works for me.
