Bootloader question: Does it skip the first X bytes of the .HEX file?

Using Arduino Microcontrollers
1

I am just learning bootloading and Arduino ISP for a remote firmware update project. I read some posts online about the format of the .HEX file. It all makes sense until I realized that the first 512 bytes of UNO or first 4KB of MEGA 2560 are for bootloaders. My .HEX file has address starting from 0000. So in principle this could include a bootloader but I can't read machine language and I don't understand bootloader.

If arduino IDE sends this file to arduino via the serial link using bootloader, will the bootloader skip the first X bytes when flashing, or will it simple replace itself with the new stuff, which includes a bootloader? I'm quite curious.

Thank you!

2

liudr:
It all makes sense until I realized that the first 512 bytes of UNO or first 4KB of MEGA 2560 are for bootloaders.

No, the bootloader goes at the end of memory.

See Figure 26-2 in the datasheet

3

Thanks for the reference. I found the figure on chapter 27 bootloader support in the 48/88/168/328 doc. You are right. I think I mixed SRAM address with register in the front with FLASH address with bootloader in the back.

New question!

If I just copy a bootloader to the end of a a.HEX file, will I be able to program the atmega and boatload it in one shot, say with iscp header?

4

liudr:
If I just copy a bootloader to the end of a a.HEX file, will I be able to program the atmega and boatload it in one shot, say with iscp header?

I don't think so....but why would you want to?

You don't need a bootloader if you just want to run a sketch.

5

My thoughts: say I start with an MCU without any bootloader in it, I program it with sketch+bootloader via ICSP, in a large batch, say 100. Then any later time I/client can load a new sketch using the bootloader, no special equipment needed.

6

AVRdude is the program that does everything (upload sketches, set fuses, etc).

You can write a command-line batch file to execute as many AVRdude commands as you want. There's no limit!

7

I'll keep avrdude in my to learn in the summer list. Besides programming a chip for the first time, my other goal is to remotely deploy a firmware and have an arduino programmer program the target system. Avrdude will help me with the first goal.

8

You can read the flash memory from a micro (programmed with a bootloader and a user application) with avrdude. You can then use avrdude to write this copy of the flash to a new micro. The fuses will also need to be set appropriately on the new micro. The new micro should now operate like the original.

9

I'm not really copying firmware. I have the firmware. I just want to understand .HEX file better and how to possibly remotely update firmware.

10

liudr:
If I just copy a bootloader to the end of a a.HEX file, will I be able to program the atmega and bootload it in one shot, say with iscp header?

The entries in a HEX file do not have to be contiguous, and the individual records each specify the actual address to be loaded. Even if it were otherwise, you could simply pad an image file with whatever the erased state of the flash would read, so that no actual programming of those areas would occur. If you dump the flash in its entirety, you obtain such a file anyway.

In any event, if you have a file of the application (sketch) which loads from zero, and a file of the bootloader which specifies its loading addresses, you can combine them so that both the sketch and bootloader are burned as one. I haven't done this, so I am not aware of just how easy it is to specify the fuse settings in the file as well.

11

I'm nor so sure you can get AVRDUDE to burn two separate hex files (as in sketch code and bootloader code) as I think it has to erase flash before it burns the flash. At least I know the behavior of first burning a bootloader via the IDE and then uploading a sketch with the IDE upload using programmer, results in the sketch being installed but the bootloader being erased. Perhaps using AVRDUDE in command line mode one can work around that but I don't recall ever seeing that process documented around here?

Lefty

12

At least I know the behavior of first burning a bootloader via the IDE and then uploading a sketch with the IDE upload using programmer, results in the sketch being installed but the bootloader being erased.

Or, the fuses are set to Not point at the bootload area as the starting location, but instead at the sketch starting location.

Section 27.2 of the datasheet:

The program code within the Boot Loader section has the capability to write into the entire Flash, including the Boot Loader memory. The Boot Loader can thus even modify itself, and it can also erase itself from the code if the feature is not needed anymore. The size of the Boot Loader memory is configurable with fuses and the Boot Loader has two separate sets of Boot Lock bits which can be set independently.

13

I'm nor so sure you can get AVRDUDE to burn two separate hex files (as in sketch code and bootloader code) as I think it has to erase flash before it burns the flash.

I have the entire BATCH script here: http://www.hackster.io/rayburne/avr-firmware-duplicator
but, in general:

To Read and create a disk file image:
flash
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U flash:r:%temp%\backup_flash.bin:r
eeprom
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U eeprom:r:%temp%\backup_eeprom.bin:r
hfuse
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U hfuse:r:%temp%\backup_hfuse.bin:r
lfuse
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U lfuse:r:%temp%\backup_lfuse.bin:r
efuse
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U efuse:r:%temp%\backup_efuse.bin:r

To Write a disk file image into the ATmega328 microcontroller (no line breaks):
flash
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U flash:w:\Users\owner\AppData\Local\Temp\backup_flash.bin
eeprom
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U eeprom:w:\Users\owner\AppData\Local\Temp\backup_eeprom.bin
hfuse
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U hfuse:w:\Users\owner\AppData\Local\Temp\backup_hfuse.bin
lfuse
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U lfuse:w:\Users\owner\AppData\Local\Temp\backup_lfuse.bin
efuse
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U efuse:w:\Users\owner\AppData\Local\Temp\backup_efuse.bin

intelhex.pdf (28.5 KB)

Intel HEX-record Format.pdf (114 KB)

14

Thank you mrburnette! I've read the intel hex format from wiki. Saved first file you posted in my dropbox reference folder. Intel stuff brings some of my lost memories from the 90's. My other thread is converging with this one.

I was able to combine a sketch and a bootloader hex, removing the end of record line. I then used Nick Gammon's sd card flash program. But the program insists that it should use a fuse value that runs code from 0000, not from the bootloader address, and it refuses me to change the bits to the right value to run the bootloader, so yes, I did that but no the bootloader was just dead weight.

I got to change his code so I can programmatically flash a target if the source arduino downloads an update from our servers. That's going to be cool.

15

@liudr,

Check out http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=33291&start=0

Ray

16

Thanks Ray. I did it the simple way, removing the end of record line from sketch hex and attaching the bootloader in the end. This may get complicated when I cross some 64KB boundaries in some projects.

Next step, adapt Nick's code to program the High fuse to D8 instead of D9. His program doesn't recognize the bootloader appended to a regular sketch hex, not yet.