Firmware Flash Fails
I upgraded firmware from MK3_3.5.1 to MK3S_3.7.1 after performing the extruder upgrade (MK3 to MK3S). The upgrade seems to look ok on the printer. It's still functional. But in PrusaSlicer is says "flashing failed" with the below log entry pointing to a checksum error. Any help? Thanks.
avrdude-slic3r -v -p atmega2560 -c wiring -P COM5 -b 115200 -D -U flash:w:0:D:\Users\Mahir\Downloads\prusa3d_fw_MK3S_3_7_1.hex:i
avrdude-slic3r: Version 6.3-20160220-prusa3d, compiled on May 20 2019 at 18:52:49
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg WunschUsing Port : COM5
Using Programmer : wiring
Overriding Baud Rate : 115200
AVR Part : ATmega2560
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00
flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00Programmer Type : Wiring
Description : Wiring
Programmer Model: AVRISP
Hardware Version: 15
Firmware Version Master : 2.10
Vtarget : 0.0 V
SCK period : 0.1 usavrdude-slic3r: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude-slic3r: Device signature = 0x1e9801 (probably m2560)
avrdude-slic3r: safemode: hfuse reads as D0
avrdude-slic3r: safemode: efuse reads as FD
avrdude-slic3r: reading input file "D:\Users\Mahir\Downloads\prusa3d_fw_MK3S_3_7_1.hex"
avrdude-slic3r: writing flash (249438 bytes):Writing | ################################################## | 100% 44.21s
avrdude-slic3r: 249438 bytes of flash written
avrdude-slic3r: verifying flash memory against D:\Users\Mahir\Downloads\prusa3d_fw_MK3S_3_7_1.hex:
avrdude-slic3r: load data flash data from input file D:\Users\Mahir\Downloads\prusa3d_fw_MK3S_3_7_1.hex:
avrdude-slic3r: input file D:\Users\Mahir\Downloads\prusa3d_fw_MK3S_3_7_1.hex contains 249438 bytes
avrdude-slic3r: reading on-chip flash data:Reading | #########################avrdude-slic3r: stk500v2_recv(): checksum error
######################### | 100% 32.12savrdude-slic3r: verifying ...
avrdude-slic3r: verification error, first mismatch at byte 0x1ed40
0xd9 != 0x19
avrdude-slic3r: verification error; content mismatchavrdude-slic3r: safemode: hfuse reads as D0
avrdude-slic3r: safemode: efuse reads as FD
avrdude-slic3r: safemode: Fuses OK (E:FD, H:D0, L:FF)avrdude-slic3r done. Thank you.
RE: Firmware Flash Fails
Does this happen everytime you try to flash with the same result (mismatch at 0x1ed40) ? If so, then the flash memory inside the ATMega2560 CPU on the Einsy is toast and you'll need a new board (or replace the CPU if you or anyone around can (de)solder SMDs).
RE: Firmware Flash Fails
Well, that's unfortunate :/ I can do a bit of soldering, but I wouldn't trust myself with an SMD. I guess I can try though if the alternative is a complete new board. Is this something that's usually covered by warranty?
RE: Firmware Flash Fails
Well, that's unfortunate :/ I can do a bit of soldering, but I wouldn't trust myself with an SMD. I guess I can try though if the alternative is a complete new board. Is this something that's usually covered by warranty?
Yes, this should covered by warranty if you're still within the warranty period. In that case, contact Prusa live chat.
RE: Firmware Flash Fails
You might try downloading the firmware again - just in case the error is in the file. It's unlikley, but worth the few minutes it takes to try.
And how are you sending the data to the printer? Slicer via USB? Or some other method?
I only ask because you are getting a chksum error in the file read: avrdude-slic3r: stk500v2_recv(): checksum error
RE: Firmware Flash Fails
ive had it say "failed" but it still took. doesn't mean its perfect, but I have not noticed anything acting odd
I have a Prusa,therefore I research.
RE: Firmware Flash Fails
ive had it say "failed" but it still took. doesn't mean its perfect, but I have not noticed anything acting odd
I checked the avrdude sources to see what 'checksum error' means, and it can only happen as a result of an issue in communication with the board during programming and a retry should finish without trouble. Plus most likely the firmware is flashed OK anyway, because the byte mismatch is only a consequence of the communication error and the error only happened during the verification read from the board.
There are of course many more 'fail' modes of avrdude, and if the failing is deterministic, and with every flash shows the same bit difference between what was intended to be flashed and what got flashed, that'd be a damaged Flash memory. But if it's failing randomly, it's usually communication issues caused by cabling, interference, etc.
RE: Firmware Flash Fails
Voj - a bad byte in a file will illicit the exact same deterministic failure. It is impossible to tell where the failure is at; and a new download is a simple, easy, and reliable method for ensuring the old file is is not part of the problem. Doing a checksum of the file would be best, and I would hope somewhere the flash software would verify the file, but I'm not seeing that this simple check is being done.
You can argue that you are right all day long. I really don't care. But the problem has more causes than you want to believe.
RE: Firmware Flash Fails
By the way - the only reliable way to determine a bad flash block it to READ the image from the chip and compare it to the uploaded HEX. Comparing the expected checksum value is not reliable since an error in the send can corrupt the data (which is what appears is happening).
The logistics are sort of like this:
FILE HEADER
EEPROM IMAGE FILE DATA
FILE FOOTER
IMAGE CHECKSUM
The uploader sends the file image, then checks the resulting flash image against the checksum stored in the file. A file download error or a file send/upload error can cause the checksum mismatch.
RE: Firmware Flash Fails
@tim-m30
I understand this post is pointless, as you've already told me you won't listen, but just in case you change your mind: 🙂
Posted by: tim-m30
The uploader sends the file image, then checks the resulting flash image against the checksum stored in the file. A file download error or a file send/upload error can cause the checksum mismatch.
I'm sorry, but no, that isn't at all what happens. What happens is:
- avrdude reads the Intel HEX file and checks that is has a valid (8-bit additive) checksum. If it doesn't it bails immediately.
- avrdude decodes the Intel HEX file into a binary data image in memory
- avrdude sends the binary image to the Einsy using the STK500v2 protocol, in chunks sized by programming page of the ATMega2560. Each chunk is protected by a (8-bit XOR) checksum.
- avrdude reads the whole contents of the ATMega2560 flash using the same STK500v2 protocol. Here is the first failure reported (stk500v2_recv(): checksum error)
- avrdude compares the received binary image with the transmitted binary image byte by byte to catch any dead bits in Flash. Here is the second failure (verification error, first mismatch at byte 0x1ed40 0xd9 != 0x19). It even prints what and where differs for easier debugging.
- avrdude checks and possibly programs the fuse values on the ATMega2560 (crystal, speed, boot settings, etc.)
From this, it should be rather obvious that the reported error cannot be a result of a corrupted file, since that'd end flashing at Step 1. Neither is a dead flash likely, that wouldn't create the error at Step 4. Once you understand the flashing process, there aren't many more explanations left. A checksum error at Step 4 can only happen as a result of an incorrectly received character.
RE: Firmware Flash Fails
By the way - the only reliable way to determine a bad flash block it to READ the image from the chip and compare it to the uploaded HEX.
That is exactly what the verification pass of avrdude is about.
RE: Firmware Flash Fails
The AVRDUDE software reads records from the file and tests them against the checksum for that record. If it sees a fail, it posts a check sum error, which the user has confirmed is happening.
At verification, the AVRDUDE software compares the EEPROM against the checksums it has from reading the file, which we already know are bad. Hence, a fail there, too.
You can't get a verify to work if the file you are flashing is corrupt.
RE: Firmware Flash Fails
And keep in mind AVRDUDE is NOT commercial software: it was written by a bunch of college kids as hackware. It is not a robust application with adequate error checking.
RE: Firmware Flash Fails
I appreciate all the spirited conversation around my lowly firmware upgrade issue 🙂 I know next to nothing about avrdude, but I'm happy to try anything. Once I have some spare time (hopefully tonight), I'll check all the low hanging fruit - different USB cable, different USB port, redownload the firmware file. Even if it's unlikely or even impossible that the file is the problem, it's not a hard check. Better safe than sorry. I emailed support in case it really is bad flash memory, but no response yet.
RE: Firmware Flash Fails
Takedown - AVRDUDE is reporting a checksum problem between the host and the remote; if I sent you an envelope with 51 pages, and you only count 50, would you trust anything you did with those 50 pages since you don't know which page is missing?
RE: Firmware Flash Fails
//
// File Checksum Integrity Verifier version 2.05.
//
MD5 SHA-1
-------------------------------------------------------------------------
27b563d6403d866b9bb7636efa50dc79 1ad55a8b79a487d421b9858a6d4a27d368419fc2 prusa3d_fw_mk3s_3_7_1.hex
As a baseline ...
RE: Firmware Flash Fails
And it'd help to know how you are flashing: via Plicer/Slic3r or via Octopi xyz or some other way?
RE: Firmware Flash Fails
Tim, as I said, I'll be redownloading the file just in case. No need to preach to the choir. And I did mention in the first post that I'm using PrusaSlicer to do the flashing.
RE: Firmware Flash Fails
Take - not trying to preach, I was just wondering how you are flashing. I didn't read the flash method in your original post; just the bit that Plicer said the flash failed. It was unclear that you actually used Plicer to perform the flash. And with so many folk using Octoprint and people also building their own versions of firmware using a consolidation of tools, it's hard to tell by inference what people are doing.
Questioning everything is a habit I developed by helping too many people with too many subjects and often not getting the full story the first time through. Sorry I came across as pontificating.
RE: Firmware Flash Fails
No worries. You'd think after several millennia of experience using the written word, humans would be more adept at conveying tone via text. Alas, that's not the case. I don't expect this forum to be any different 🙂