Export Compiled Binary - Difference between hex files with and witout bootloader

New in this forum.

I was looking for this very subject and found this thread:

but I'm not sure that the initial question was clearly answered so I'll try to add my own experiments.

The Arduino IDE (1.8.2) Sketch->Export Compiled Binary creates two files in the original sketch directory:

  1. BlinkWithoutDelay.ino.standard.hex (2428 bytes).
  2. BlinkWithoutDelay.ino.with_bootloader.standard.hex (3804 bytes).

I uploaded both files using the serial interface and the ISP.

A) Upload using USB/FTDI.
Of course, the chip must have the boot loader installed.
Both files 1) and 2) can be uploaded normally and seem to work exactly the same (at least with this simple sketch).

B) Upload using ISP programmer (I use an Arduino as ISP).

File 1) overwrites the boot loader. The chip cannot be reprogrammed again using method A).
File 2) uploads both the sketch AND the boot loader. The chip can be reprogrammed again with same or another sketch using method A).

So, the real utility of file 2) is that it allows to burn both the sketch and the boot loader in a single operation. This may be handy if a number of boards must be setup from scratch.

Let me know if I got it right.

That's my understanding also, though I've never tried it. I did a quick skim of the other thread but I don't understand why it wasn't working. Yes, you need the fuses set for the bootloader, but the fuses on an Arduino should already be set correctly. Even when you do Upload Using Programmer it still leaves the fuses the same as they were set when you do a Burn Bootloader.

I use the Arduino as ISP with Avrdude at command level with same parameters for both the bootloader or the sketch with bootloader.

This is the Batch file:

@ECHO Usage: Boot[comm port] [file] [ENTER]
@if "%1"=="" goto NO_COMM
@ECHO Set fuses
@.\avr\avrdude -C.\avr\avrdude.conf -v -patmega1284p -cstk500v1 -PCOM%1 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xF7:m 
@ECHO Burn bootloader
@if "%2"=="" goto ALTFILE
@.\avr\avrdude -C.\avr\avrdude.conf -v -patmega1284p -cstk500v1 -PCOM%1 -b19200 -Uflash:w:.\avr\optiboot_atmega1284p.hex:i -Ulock:w:0x0F:m 
@.\avr\avrdude -C.\avr\avrdude.conf -v -patmega1284p -cstk500v1 -PCOM%1 -b19200 -Uflash:w:.\hex\%2.hex:i -Ulock:w:0x0F:m 
@if errorlevel 1 goto ERROR
@goto DONE
@ECHO Comm port missing!
@ECHO Something went wrong - Nothing done!
@echo Error level: %errorlevel%

The command line uses one or the other based on the presence of the second parameter (the sketch file).

C:setuP\boot 3 -> Burns the bootloader (optiboot_atmega1284p.hex)

c:>setup\boot 3 blink -> Burns the bootloader and the sketch

As you may see the fuses are set in both cases the same and it works fine as far as I can tell but I'm not an expert in this so it may be that I'm lucky.

Sorry to bump, but since we are on that topic,

Does uploading using method A still uploads and overwrites the bootloader? I'm not clear on that.

I have some nanos with new and old bootloader (optiboot) and I'd love for all of the nanos to be optiboot without having to use the arduino as ISP

Uploading via USB/Serial uses the bootloader, it does not erase the bootloader in the process.

Uploading via ISP will always erase the bootloader - the only way an ISP programmer can erase the flash is do do a chip erase operation, which erases the entire flash (and the EEPROM unless EESAVE fuse is programmed). So, if you want to continue being able to program via serial when you do an upload via ISP, you must use the version of the .hex with the bootloader included.

OK. I was hoping I found an easy way to change the bootloader

OK. I was hoping I found an easy way to change the bootloader

There is an easy way to use a bootloader, connect an ISP programmer and use that to put the preferred bootloader on it.

The bootloader (which is what is used when you do a serial/usb upload) will not overwrite itself, and this is good, because otherwise you could upload something that hosed the bootloader; as it is, there is nothing you can upload over the serial port that will damage the bootloader

Hey guys - this topic is a few months old - but I’m confused about what the ‘bootloader’ is exactly in the case of, for example, the ATTiny chips.

I’m using the ATTinyCore, and my understanding is that when I write the ‘bootloader’ to, in this case an ATTiny44A, all I’m really doing is writing fuse settings, which seems to be confirmed by looking at the avrdude verbose output because I can really only see it writing and confirming the efuse, hfuse and lfuse.

However, after uploading my sketch to the ATTiny44 with the programmer (after setting the fuses by writing the ‘bootloader’), if I go into the folder where it dumped my HEX files, I still see a regular .hex file and then still an additional .with_bootloader.hex file sitting there. I understand the purpose of the .with_bootloader.hex file in the case of an Arduino because it allows serial reprogramming, but what’s the purpose of the ‘bootloader’ here? Does the .with_bootloader.hex contain the fuse settings somehow? And if so, why is it the .with_bootloader.hex file 104 bytes larger than the normal .hex file, when it would really only need to be 3 bytes larger?

Basically, if I’m going to send one of these .hex files to Digikey for automatic programming of my chips, which one of these .hex files should I send them? Digikey wants my fuse settings documented separately, so even if the .with_bootloader.hex file contains them, I feel like I should be good with the standard .hex file, but I just want to be sure before I drop a $50 first article setup fee.

The with bootloader hex is bogus. If you use my core, except for the chips where we can produce a bootloader-included image that works (ie, ones that use a bootloader and have hardware bootloader support - most dont and use virtual boot if you use the optional serial bootloadet, which rewrites 2 of the vectors when writing the sketch, so the with bootloader hex wouldn't work), it deletes this non-usable hex immediately.

@DrAzzy thanks for the response . . . I figured the hex with bootloader was pointless, but I didn't know it wouldn't work.

I do use your core. Thanks for all your work on it! I might have an old version of it . . . I'm not sure how to tell which version I have from looking at the readme.md file - it says it's for Arduino version 1.6.x, so a bit at least. Did you add the feature of deleting the non-usable hex later?

That functionality was added in ATTinyCore 1.1.3; release notes for 1.2.2 indicate that at that time an issue relating to export compiled binary on linux and mac OS was fixed as well, I forget the details.

Note that we are now on 1.3.2.