3.5.0b1+ Wifi error - SPI timeout
-
@OwenD thanks for reporting this. Versions 1.x and 2.x of the WiFi firmware use different versions of the Expressif SDK. I guess either one of those SDK versions is mis-reporting RSSI, or they have changed the interface and we didn't pick that up. I will check the version 2.x code.
-
-
So for some reason this has reared it's head again a couple of times lately.
My system has a 5v power supply which powers the duet and switches a 24 volt power supply via the ATX pin as required.
Before resetting I ran M111 P14 S1, then M122
YAT seems to have dumped that report due to the volume of lines added, so I've only got the report immediately after restarting.For some reason the MCU voltage shows a very low value until I run M80 and kick the 24v power supply into action. Not sure if that's related.
It does the same regardless of this wifi anomaly.Error: failed to retrieve WiFi status message: SPI timeout ResponseTimeout, pending=1 ESP reported status change ResponseTimeout, pending=1 Error: failed to retrieve WiFi status message: SPI timeout ResponseTimeout, pending=1 ESP reported status change ResponseTimeout, pending=1 Error: failed to retrieve WiFi status message: SPI timeout ResponseTimeout, pending=1 ESP reported status change ResponseTimeout, pending=1 Error: failed to retrieve WiFi status message: SPI timeout M111 P14 S1 Debugging enabled for modules: WiFi(14 - 0xffffffff) Debugging disabled for modules: Platform(0) Network(1) Webserver(2) Gcodes(3) Move(4) Heat(5) Dda(6) unused1(7) unused2(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) Display(15) SbcInterface(16) Can(17) M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5beta2+ (2023-02-12 12:52:31) running on Duet WiFi 1.02 or later Board ID: 08DGM-917NK-F2MS4-7J1DA-3S86T-TZTWD Used output buffers: 1 of 26 (11 max) === RTOS === Static ram: 22216 Dynamic ram: 79456 of which 12 recycled Never used RAM 8284, free system stack 184 words Tasks: NETWORK(ready,10.9%,377) ACCEL(notifyWait,0.0%,348) HEAT(notifyWait,0.0%,327) Move(notifyWait,0.0%,361) MAIN(running,87.9%,502) IDLE(ready,1.1%,30), total 100.0% Owned mutexes: WiFi(NETWORK) USB(MAIN) === Platform === Last reset 00:01:21 ago, cause: power up Last software reset at 2023-02-15 03:34, reason: StuckInSpinLoop, Platform spinning, available RAM 7040, slot 0 Software reset code 0x4080 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0040080f BFAR 0xe000ed38 SP 0x20003014 Task NETW Freestk 488 ok Stack: 00414fdf 00459cc2 010f0000 e8000000 400985ff 41c475a6 3edb9368 3331bb4c 40000000 b5ddd8b0 388ab355 bb360b61 3e2aaaab 3f800000 3f800000 41d94ba3 4354c416 41200000 3f800000 80000010 00414fa5 b5ddd8b0 388ab355 20010fbc 3e2aaa01 3f800000 20011248 Error status: 0x00 Aux0 errors 0,0,0 Step timer max interval 0 MCU temperature: min 29.3, current 33.6, max 33.8 Supply voltage: min 0.3, current 0.5, max 0.5, under voltage events: 0, over voltage events: 0, power good: no Heap OK, handles allocated/used 99/15, heap memory allocated/used/recyclable 2048/384/116, gc cycles 0 Events: 0 queued, 0 completed Driver 0: ok, SG min n/a Driver 1: ok, SG min n/a Driver 2: ok, SG min n/a Driver 3: ok, SG min n/a Driver 4: ok, SG min n/a Driver 5: Driver 6: Driver 7: Driver 8: Driver 9: Driver 10: Driver 11: Date/time: 1970-01-01 00:00:00 Cache data hit count 3368987419 Slowest loop: 7.82ms; fastest: 0.14ms 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 1.0ms, write time 0.0ms, max retries 0 === Move === DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000 no step interrupt scheduled === DDARing 0 === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 === GCodes === Movement locks 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 ready with "M122" 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 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Q0 segments left 0 Code queue 0 is empty === Filament sensors === Extruder 0 sensor: ok === Network === Slowest loop: 7.76ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 0 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 2.1beta3 WiFi MAC address bc:dd:c2:89:a0:bb WiFi Vcc 3.39, reset reason Power up WiFi flash size 2097152, free heap 45652 WiFi IP address 192.168.1.163 WiFi signal strength -29dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0 ok WiFi: <ESC>[0mConns: 0:free, 1:free, 2:free, 3:free, 4:free, 5:free, 6:free, 7:free
-
Some more info this morning.
Normally I discover this problem either when I walk out to the garage to get a beer and see the PanelDue flashing ans SPI error, or I can't connect to DWC.
This morning I opened my phone (to a previously open tab) and DWC was frozen.
When I tried refreshing, it just said connecting and that the drive wasn't mounted.Suspecting an SD card issue, I checked the PanelDue wasn't displaying any errors.
Sending M20 resulted in a normal listing, so the SD card has to be mounted.
Maybe this is a red herring?
DWC from my laptop just doesn't connect. "Can't find host"M20 Begin file list random-moves-test.g Outer_Trays_0.2mm_PLA.gcode freak_Pin_0.14mm_PA-CF.gcode Inner_Trays_0.2mm_PLA.gcode SKEW_100mm_0.2mm_PLA.gcode cube_0.2mm_PLA.gcode Freak body large skirt_0.2mm_PA-CF.gcode YACS_0.2mm_PLA.gcode calibration_0.2mm_PLA.gcode monitor-pad-right_0.2mm_PLA.gcode calibration piece _0.2mm_PLA.gcode Box1_0.2mm_PLA.gcode EspChunky_0.2mm_PA-CF.gcode pump-filter_0.2mm_PA-CF.gcode End file list
If I send M111 P14 S1, I immediately get a barrage of busy responses in YAT .
M111 P14 S1 Debugging enabled for modules: WiFi(14 - 0xffffffff) Debugging disabled for modules: Platform(0) Network(1) Webserver(2) Gcodes(3) Move(4) Heat(5) Dda(6) unused1(7) unused2(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) Display(15) SbcInterface(16) Can(17) ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy ResponseBusy M111 S0 ok
If I try to do a network scan I get this
M587.1 Error: M587.1: failed to start scan: another SPI transfer is pending
-
Can you try flashing back to 1.27 and seeing if this still happens? If so, I think it may be the module.
-
@Phaedrux
Can't rule out a hardware issue I guess.
Have reverted back to 1.27 and will monitor.
I did an M122 before and after the change.
This is the network section. Note the not ready number and lack of IP address.=== Network === Slowest loop: 29273.09ms; fastest: 100.43ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 0 of 8 = WiFi = Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 42217, noresp 1 Failed to get WiFi status Socket states: 6 0 0 0 0 0 0 0
After reverting and restart.
= WiFi = Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 2 WiFi firmware version 1.27 WiFi MAC address bc:dd:c2:89:a0:bb WiFi Vcc 3.38, reset reason Power up WiFi flash size 4194304, free heap 24848 WiFi IP address 192.168.1.163 WiFi signal strength -35dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0
-
Hi, I have also been getting instability issue with the wifi since going to 3.5.0b1.
The duet will drop off from the network midprint or even not connect at all unless i power it down and then back up.
-
@StreetFurnitureAustralia
Are you getting the same SPI timeout messages noted in this thread?
Can you connect via USB and grab the same reports as above?
My error is quite random and very specific.
It has not reappeared since rolling the wifi back to 1.27 but it only happened occasionally so I'm not ready to say it's definitely firmware yet. -
@OwenD I can't replicate it but when it happens again then I can try and get it.
-
@OwenD I'm not in the office but a colleague sent me thisreceived_6062637163802703.mp4
As you can see its being spammed
-
@StreetFurnitureAustralia
That's the same behaviour
Can you try to get the reports as shown above and then roll the wifi back to 1.2.7
I haven't had a repeat since rolling back but it's infrequent for me, so I can't be sure it's the firmware -
@OwenD I will try just never don't this before, is there a way to log this via the duet webinterface and not need to connect a laptop directly?
-
@StreetFurnitureAustralia
No, if the wifi module can't connect then the only way to get the info is via a terminal like YAT using the usb connection
If you roll back to 1.27 and have no further issues it's at least showing the same results as I'm getting
Maybe it's an Aussie only issue?
Wifi channel or something related? -
@OwenD could make sense, This is at my work and we use Unifi wifi gear. How about yourself?
-
Good morning @dc42 ,
I would like to share my case in this post, I don't know if it will help.
After a while (X), usually the next day, my printer loses connection and I have to reset it to get a new IP address. In addition, it often changes IP addresses, and I have even been given IP addresses that have already been assigned to other Duets.
The commands I used to use to establish a connection no longer work:
M552 S-1 G4 S1 M552 S0 G4 S1 M552 S1
To solve this problem, I have had to use the following commands:
M552 S-1 G4 S1 M400 M552 S0 G4 S1 M400 M552 S1
If I don't perform these steps, sometimes I can't connect the printer. I suppose that these commands cannot be launched during a print to switch from M552 S1 to M552 S2 (although I haven't tried it).
Finally, I would like to share the results of M122 and the object model and M540 command, as I think this may be where one of the problems lies:
In M122, the MAC address is visible.
In the object model and the M540 command, the MAC address is "00:00:00:00:00:00".6/4/2023, 12:19:43 M540 MAC: 00:00:00:00:00:00 6/4/2023, 12:04:07 M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5beta2+ (2023-02-10 11:58:19) running on Duet WiFi 1.02 or later === Network === Slowest loop: 6.76ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) 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 2.1beta3 WiFi MAC address e8:68:e7:79:5f:a3 WiFi Vcc 3.39, reset reason Turned on by main processor WiFi flash size 2097152, free heap 43068 WiFi IP address 192.168.1.18 WiFi signal strength -54dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0
-
@OwenD I couldn't get the info due to time restraints at work but I have rolled it back.
-
-
@StreetFurnitureAustralia
I also did not get any re-occurences with WiFi 1.27
I have been running RRF3.5b4 and WifFi version 2.1b4 for several days now with no errors.
May be too early to tell but it may be fixed. -
@OwenD I can't see beta 4 only beta 3.
-
@StreetFurnitureAustralia
Typo on my part.
RRF is b3
-
@OwenD ok cheers will give it a try