Save existing binary

I’ve got VSCode, PlatformIO etc. working and talking to the ‘Melzi’ motherboard of an Anet A2 printer. Is there any way to save the original binary before risking overwriting it?

Do you mean a previously by PlatofrmIO compiled firmware on your computer (so basically your .pio\build\<env>\firmware** files) or what’s programmed on your motherboard right now?

Max:
I mean what was shipped with the board.

Sure, just instruct the flasher program avrdude to read out the flash, EEPROM and all fuses (high fuse, low fuse, extended fuse) of your microcontroller and save it to a file. Just like Pololu - 5.8. Reading and writing from EEPROM and flash says.

Once you have the COM port of your connected motherboard (see Windows device manager, in this example COM3), open a PlatformIO CLI and execute the command

C:\Users\<user>\.platformio\packages\tool-avrdude\avrdude.exe -patmega1284p -carduino -PCOM3 -b115200 -Uflash:r:dumped_firmware.hex:i -U eeprom:r:dumped_eeprom.hex:i -U lfuse:r:lfuse.hex:i -U hfuse:r:hfuse.hex:i -U efuse:r:efuse.hex:i 

Max:
Thanks a lot - I can communicate directly with the board via PuTTY, so I know what settings to use.

Max:
I found a version of avrdude and got it to run.
It seems to prefer -pm1284p for this board.
Alas, I get stk500_getsync() not in sync: res p=0x73
Any suggestions please?
Regards, Ralph

What exact command are you using?

The one you suggested, running from within the directory where I downloaded avrdude.exe, with the board model changed to what is listed with .\avrdude -p? :

.\avrdude.exe -pm1284p -carduino -PCOM3 -b115200 -Uflash:r:dumped_firmware.hex:i -U eeprom:r:dumped_eeprom.hex:i -U lfuse:r:lfuse.hex:i -U hfuse:r:hfuse.hex:i -U efuse:r:efuse.hex:i

I’ve read elsewhere that some boards are protected against firmware dumping until you erase them completely.

Usually when it’s responding with “something” but garbage the bootlauder baud rate may be wrong. Looking at Marlin/ini/avr.ini at bugfix-2.1.x · MarlinFirmware/Marlin · GitHub not only 115200 is used, but some use 57600. Can you change the 115200 to 57600 in the command?

You may also try and change the -carduino upload method to -c stk500v2, maybe the bootloader uses that.

Oddly, the 57600 was the answer - I was sure I had got communication via PuTTY at 115200, but obviously not! Anyway, thank you very much. Now to see if I can upload a new version…

The application and the bootloader can have choose to operate at different baud rates, so that’s normal.