Firmware 1.20 released
-
I have just put an old 06 board that I had spare onto an new setup this evening and I can confirm and 100% replicate Captain_sq's findings. Without en ethernet cable attached, everything works fine (USB communication and PanelDue). However, if an IP address is not specified either in the config file or manually over USB using M552, as soon as the ethernet cable is plugged in the board just goes into a boot loop and communication via USB and PanelDue die. If an IP address is specified beforehand, then there are no problems… other than the fact that I don't want to use hard-coded IPs on my system.
I rolled back to version 1.19 and this behavior stops, anything newer and it's dead.
-
Thanks @Captain_sq, that confirms where the problem lies. Unfortunately I have not been able to reproduce the problem here.
It looks like the DHCP code in the Lwip TCP/IP stack is looping indefinitely. I've looked at the code and I didn't see any obvious cause. However, some changes in the functions concerned have been made in version 2 of Lwip, and I have back-ported these to the version used by RepRapFirmware. So please can you try the new binary at https://www.dropbox.com/s/ozuw60nflckpq6c/RepRapFirmware.bin?dl=0 and see if it resolves the problem when you set the IP address in the M552 commandback to all zeros. If it doesn't, please post another M122 report obtained after the new firmware reboots in the same way.
-
Thanks, I'll try it when I come home from work today.
The fact that you are not able to reproduce the phenomena leads me to think about the possibility of HW revision changes in the affected chips differ from your/mine board. Any errata info available?
-
I think that's unlikely. The only chip involved is the SAM3X8E and the datasheets indicate that it hasn't been revised in years (Microchip considers SAM3 chips to be "legacy devices" these days). I think the different behaviour is more likely to be due to a difference in the DHCP response from your router or its timing.
-
Tried the last FW you sent. Unfortunately, the problem remains (when using DHCP).
FWIW, I have an ASUS RT-N66U Router. Works like a charm with all my other devices. Here's the Duet info:[[language]] (21:06:41.110) M122 (21:06:41.267) === Diagnostics === (21:06:41.267) Used output buffers: 1 of 32 (1 max) (21:06:41.267) === Platform === (21:06:41.267) RepRapFirmware for Duet version 1.21RC0+1 running on Duet 0.6 (21:06:41.267) Static ram used: 44836 (21:06:41.267) Dynamic ram used: 40764 (21:06:41.267) Recycled dynamic ram: 416 (21:06:41.267) Stack ram used: 3520 current, 4316 maximum (21:06:41.267) Never used ram: 7972 (21:06:41.267) Last reset 00:00:33 ago, cause: software (21:06:41.267) Last software reset time unknown, reason: Stuck in spin loop, spinning module Network, available RAM 8032 bytes (slot 3) (21:06:41.267) Software reset code 0x2041 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0x20087e64 (21:06:41.267) Stack: 000c10d7 00000001 fffffff9 00000001 20087ebc 20070fe8 00000001 20087ebc 000a76e3 000a7fb4 21000000 2007a9ac 0000012c 00000123 00000000 2007376c 200737a8 2007a938 00000127 2007aea8 000000f0 be5a1f3c 01c8a8c0 2007376c (21:06:41.267) Error status: 0 (21:06:41.267) Free file entries: 10 (21:06:41.267) SD card 0 detected, interface speed: 21.0MBytes/sec (21:06:41.267) SD card longest block write time: 0.0ms (21:06:41.267) MCU temperature: min 24.0, current 25.8, max 26.1 (21:06:41.267) Date/time: 1970-01-01 00:00:00 (21:06:41.267) Slowest main loop (seconds): 0.000401; fastest: 0.000101 (21:06:41.267) === Move === (21:06:41.267) MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, MaxWait: 0ms, Underruns: 0, 0 (21:06:41.267) Scheduled moves: 0, completed moves: 0 (21:06:41.267) Bed compensation in use: mesh (21:06:41.267) Bed probe heights: 0.000 0.000 0.000 0.000 0.000 (21:06:41.267) === Heat === (21:06:41.267) Bed heaters = 0, chamberHeaters = -1 -1 (21:06:41.267) Heater 1 is on, I-accum = 0.0 (21:06:41.267) === GCodes === (21:06:41.267) Segments left: 0 (21:06:41.267) Stack records: 2 allocated, 0 in use (21:06:41.267) Movement lock held by null (21:06:41.267) http is idle in state(s) 0 (21:06:41.267) telnet is idle in state(s) 0 (21:06:41.267) file is idle in state(s) 0 (21:06:41.267) serial is ready with "M122" in state(s) 0 (21:06:41.267) aux is idle in state(s) 0 (21:06:41.267) daemon is idle in state(s) 0 (21:06:41.267) queue is idle in state(s) 0 (21:06:41.267) autopause is idle in state(s) 0 (21:06:41.267) Code queue is empty. (21:06:41.267) === Network === (21:06:41.267) Free connections: 16 of 16 (21:06:41.267) Free transactions: 24 of 24 (21:06:41.267) Locked: 0, state: 2, listening: 0x0, 0x0, 0x0 (21:06:41.267) -
Have you given up on this? I have no problems to live with the quirk as it is an old legacy board and does not disrupt operation when the workaround has been applied. Although, maybe this should be documented in a FAQ or in the WIKI.
/Thom
-
Are there any plans to enable network drive functionality on the duet? I ask because it would make scripting functionality a lot simpler, I'm planning to make an attachment to allow a USB dial indicator to write a CSV mesh levelling file by just dragging it across the bed without lifting.
-
Have you given up on this? I have no problems to live with the quirk as it is an old legacy board and does not disrupt operation when the workaround has been applied. Although, maybe this should be documented in a FAQ or in the WIKI.
/Thom
Please can you run the 1.21RC1 release and get another M122 report when the problems happen again, as I no longer have the symbol files and assembly listing for that temporary release so I can't relate the software reset data to the code.
-
Are there any plans to enable network drive functionality on the duet? I ask because it would make scripting functionality a lot simpler, I'm planning to make an attachment to allow a USB dial indicator to write a CSV mesh levelling file by just dragging it across the bed without lifting.
We have no plans to do this with the current Duets. There probably isn't enough memory to run a protocol like CIFS or NFS, and the protocols that provide a block-level interface over the network can't handle local reads/writes at the same time. But the next generation Duets will eventually be able to provide this.
Meanwhile there are HTTP and FTP commands available to manipulate files on the SD card via the network.
-
Ok, thanks for the quick response David, just a convenience thing, I'll have to dig back in my memory banks for http and ftp manipulation.
-
Have you given up on this? I have no problems to live with the quirk as it is an old legacy board and does not disrupt operation when the workaround has been applied. Although, maybe this should be documented in a FAQ or in the WIKI.
/Thom
Please can you run the 1.21RC1 release and get another M122 report when the problems happen again, as I no longer have the symbol files and assembly listing for that temporary release so I can't relate the software reset data to the code.
I already did. It's here in this thread, in the 11'th post:
https://www.duet3d.com/forum/thread.php?id=4195 -
Thanks, I've made a note to look at that report.
-
I have a proposal for you David. I'll send my 0.6 Duet to you (I'll cover the freight cost myself). I'll swap it for any other Duet type board you might have in your bins, as long as it works.
/Thom
-
It's by no means clear that the problem is with the Duet.
-
It's by no means clear that the problem is with the Duet.
I'm not saying it does, although there are some circumstantial evidence pointing in that direction (1.19 worked fine /w DHCP). I was thinking more in terms of giving you a chance to examine the actual board in your lab. It's up to you if you think that doing so has any value or not, I can live with the fixed IP address in order to benefit from the new features in the latest FW releases.
/Thom
