Help! Uploaded CRC is different (25e2595f vs. expected 2080b701)

Shanian79

@deckingman Thanks! Could you send me a link to the correct firmware I should use? I was going to try updating, but I'm new to much of this and I didn't see anything on Github that was specific to the Duet 3 board, so I didn't want to take a chance.

A Former User

@Shanian79
RRF3 v3.0 release https://github.com/dc42/RepRapFirmware/releases/tag/3.0
the Duet2and3Firmware-3.0.zip is common for all boards

and then if you want to go to the very latest do this afterwards
https://github.com/dc42/RepRapFirmware/releases/tag/3.01-RC1
(where you'll find duet3 specific files instead of a bundled zip file)

Shanian79

@bearer Thank You!

Shanian79

Thank you everyone for your help! I'm back up and running!

deckingman

@Shanian79 Glad you got it sorted.

Hugsy

Hi,

This issue is a long time problem on my side with RRF 3.2 on a Duet 3 MB6HC, one G-Code of 78 Mb in particular just cannot be uploaded regardless of how many times I tried.
Can the network start to introduce issues like this ? I don't see anybody else with the same issue on that firmware so hope it's an easy fix.

Thanks is advance for the help, Hugh

PCR

@hugsy please post the output of M122 and your DWC version

Hugsy

@pcr DWC is the 3.2.0 version and here is M122:
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v0.6 or 1.0 (standalone mode)
Board ID: 08DJM-956L2-G43S4-6JTD2-3SN6Q-1U66G
Used output buffers: 3 of 40 (37 max)
=== RTOS ===
Static ram: 150156
Dynamic ram: 93128 of which 96 recycled
Never used RAM 115452, free system stack 182 words
Tasks: NETWORK(ready,119) ETHERNET(blocked,111) HEAT(blocked,270) CanReceiv(blocked,809) CanSender(blocked,371) CanClock(blocked,354) TMC(blocked,55) MAIN(running,1089) IDLE(ready,19)
Owned mutexes:
=== Platform ===
Last reset 03:52:08 ago, cause: power up
Last software reset at 2021-09-17 18:44, reason: User, GCodes spinning, available RAM 115452, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 38.4, current 38.6, max 38.7
Supply voltage: min 24.0, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Driver 0: position 6110, standstill, reads 8388, writes 0 timeouts 0, SG min/max not available
Driver 1: position 6110, standstill, reads 8387, writes 0 timeouts 0, SG min/max not available
Driver 2: position 6110, standstill, reads 8387, writes 0 timeouts 0, SG min/max not available
Driver 3: position 0, standstill, reads 8388, writes 0 timeouts 0, SG min/max not available
Driver 4: position 0, standstill, reads 8388, writes 0 timeouts 0, SG min/max not available
Driver 5: position 0, standstill, reads 8388, writes 0 timeouts 0, SG min/max not available
Date/time: 2021-09-20 14:06:20
Slowest loop: 4.50ms; fastest: 0.06ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 3.2ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 0ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 5 -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
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 2.73ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 1 of 8
-Ethernet -
State: active
Error counts: 0 0 1 0 0
Socket states: 5 2 2 2 2 0 0 0
=== CAN ===
Messages queued 6, send timeouts 0, received 18, lost 0, longest wait 0ms for reply type 0, free buffers 48

PCR

@hugsy Please Update to at least 3.3 stable

Best

Hugsy

@pcr Okay, is there any reports of people having upload issues with 3.2?
I did many modifications to the firmware so the upgrade to 3.3 will take some time. I'll post here when it will be running on my printer.

PCR

@hugsy update is only uploading the ZIP ? you do not have to make andy modyfications

droftarts

@hugsy said in Help! Uploaded CRC is different (25e2595f vs. expected 2080b701):

@pcr Okay, is there any reports of people having upload issues with 3.2?
I did many modifications to the firmware so the upgrade to 3.3 will take some time. I'll post here when it will be running on my printer.

Reports of upload issues usually come down to either network issues or SD card faults (which can be that actual socket on the Duet). As you're using your own firmware version, it would be best to test the official release, with a fresh SD card, to see if you can replicate the issue. Wireshark trace and M122 following an unsuccessful transfer may be useful.

For SD card/socket faults, see https://duet3d.dozuki.com/Wiki/SD_Card#Section_Troubleshooting_SD_Card_issues

Ian

Hugsy

@droftarts I'll try the official release without my motors plugged in and with a fresh sd card to see how does it behave. The printer has special movement that forces it to use a modified firmware so I cannot print with the official release.
The SD card seems to be okay but I'll replace it with something else just to be sure.
I haven't tried Wireshark, I'll give it a try now.

Thanks for the help @PCR and @droftarts !

Hugsy

@droftarts Some news regarding this issue, the SD card seems fine but I changed it to another one without any results.
RRF 3.3 stable is solving the CRC issue but in Wireshark there is a lot of TCP flags ("ZeroWindow" and "Window Full") that are present while uploading and not when downloading. These flags are present with RRF 3.3 and also my custom 3.2 build.
I also tried uploading without CRC check with RRF 3.2 and compared the uploaded files with the original files with Meld, and it's interesting :

It seems like there is a cache leak as full sentences end up written in the G-Code, it might be TCP requests but this is beyond my expertise.

As RRF 3.3 stable solves the problem, I'll start building from it. Thank you for your help!

droftarts

@hugsy If you could post the Wireshark trace, that might be helpful.

@chrishamm can you take a look at this?

Ian

Hugsy

@droftarts Here it is:

It's this bad when uploading but when downloading it's fine.