Hi everyone, i'm having trouble with an Intel hex backup in AVRDude. Restoring it isn't working. A simple blink hex worked, but an 80kb hex (with no source) has bricked 2 pro minis. Im guessing either it needs a bootloader, or there's some kind of hex file size limit. It doesn't reach 100% when writing, then no further uploading is possible. I used the same command and exe as arduino, changing only R and W. The programmer uses Tx and Rx, because there's no usb connector Here's the file: data.hex - Google Drive
Have you compared the size of your program to the available memory in a Pro Mini?
I won't open your zip file but do you know if 80K is the file size or the program memory size? If the former, perhaps someone knows a rough relationship between the hex file size and program memory requirments.
The program is 31.9kb, leaving 98 bytes free. Interestingly, when loading the hex into 'WinHex' and converting to / from binary, addresses 23A0 - 7800 were removed. Those bytes were all 0xFF. So the 80kb hex file became 26kb. Strange for AVRDude to add "unnecessary" sections of 0xFF. But hopefully this information helps someone else with redundant data in their hex files. By omitting lines that only have 0xFF, the intel hex file can be shrunk with unknown consequences
31.9 kB is close to the maximum flash size. I think that you should give the size in bytes. Add space for the bootloader and you're probably over the limit.
Have you tried to upload with a programmer?
I agree, I found this statement on an Arduino site.
Flash Memory of 32KB out of which 0.5KB is used by the bootloader code.
It's 32,670 bytes, leaving 98 bytes free. Bytes from 23B8 - 7800 are all 0xFF. Does avrdude back up the bootloader as part of the program memory backup? This is the command, simply changing the IDE command, W to R: C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -carduino -PCOM4 -b57600 -D -Uflash:r:C:\Users\MSI\AppData\Local\Temp\arduino_build_318050/Blink.ino.hex:i
As the boot loader is also stored in flash, I suspect that the answer is yes.
If you still have a working ProMini, you can test by uploading blink (check the size) and next pull it back (and check the size again).
Note that the hex format is (possibly) different for the file created by the IDE and the file that you pulled back; from memory 16 bytes per hex record versus 8 bytes per hex record so you will have double the number of hex records in the latter.
I will see if I can find a ProMini to test, no promises.
1 Like
I have uploaded to a Nano, set as a pro mini in the IDE. Both are atmega328P
Now it makes sense what is happening here. The IDE saves only the flash memory that's needed for the program, then writes 100 bytes of 0xFF to denote the end of the sketch. The bootloader starts at 0x7800. Here's where the problem lies, reading back from flash memory copies the full 32kb. Reuploading the full memory fails. Perhaps avrdude looks for the 100 byte footer?
By editing the recovered hex, deleting everything after the 100 byte sketch footer and updating the byte count, the hex file uploaded and blinked properly. The byte count on the last line was 0x1C, shorter than the usual 0x20. This did not affect the checksum, since I only needed to remove all of the 0xFF bytes. There were 4 on the end of that line. Notepad++ is great here, since it verifies the checksum and byte count by automatically highlighting
1 Like
Does one need a plugin for that? If so, which one?
If not mistaken, the last four bytes indicate the end-of-file. I think that e.g. the wiki article about the Intel hex format has an explanation.
Thanks for the feedback.
No worries. It seemed like it automatically detects the file extension, and highlights accordingly. Unfortunately, I tried to upload the recovered file to the nano. And because there was a lot more bytes of 0xFF than 100 in this one, I deleted the section, hoping none of them were needed. Another 328P won't respond anymore.
stk500_recv(): programmer is not responding
All a part of learning!
This is the file that failed even after deleting the first 0xFF section and beyond: data (1).hex - Google Drive
Get yourself a programmer so you can upload via ICSP. Pololu USB AVR Programmer v2.1 is possibly one of the most universal ones.
Good chance that you can recover your 'broken' Arduinos.
I've tried with the fischl USBASP, and got some errors:
avrdude: Warning: cannot open USB device: Function not implemented
It could just be that I need to use zadig or restore the default driver for the programmer (libusb-win32?)
I did not know that you had a USBASP. Can't help with your programmer problem.
I didn't mention the USBASP because it didn't work for me, but this time I used Nick Gammon's sketch and an Uno. That rewrote the bootloader, and fixed the nano and a pro mini. 2 out of 3 working is pretty good. Now I must keep editing the hex, and trying for a successful upload. Instead of guessing where the sketch ends, I must find out what bytes mark the position
If you use USBASP to program the chip via the ICSP pins, you will not have to edit the file.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.