NEWER New Optiboot bootloader

Sorry to keep bleeting on Bill... it is just that I am still not sure of my understanding.

I fully appreciate your points on variance, which is why I was confining myself to the bootloader images on GitHub.

In an earlier over you said that “The optiboot version number is stored in the last two bytes of the chip”. So, I went and looked. This is what I see:

~> hexdump -s 0x550 -C optiboot_atmega328.hex
00000550  30 30 30 30 37 45 30 30  37 42 0d 0a 3a 30 30 30  |00007E007B..:000|
00000560  30 30 30 30 31 46 46 0d  0a                       |00001FF..|
00000569
~>

What am I missing? I think I see 0x46 0x46 0x0d 0x0a as the last few bytes of the file. Ignoring the cr/lf, is that v6.6 I read.

This is no way a criticism or challenge, it is just that when the information doesn't reconcile, I'm not sure of my understanding!

Best regards, Martin

optiboot_atmega328.hex is ascii file in intel hex format :slight_smile:
Look inside:

:027FFE00020679

last two bytes of data are 02 06 just like Bill said.

hexdump -s 0x550 -C optiboot_atmega328.hex
:
What am I missing?

The .hex file is already an ascii-ized file of hex characters, so if you use "hexdump", you are dumping the ascii data rather than the binary content represented by the .hex file. You either want "avr-objdump" or "tail":

tail -3l optiboot_atmega328.hex 
:027FFE00[color=red]0206[/color]79
:0400000300007E007B
:00000001FF
> avr-objdump -march=avr -s optiboot_atmega328.hex 
optiboot_atmega328.hex:     file format ihex
Contents of section .sec1:
 7e00 1f92cdb7 deb71124 84b714be 982f9d70  .......$...../.p
  :
 7fc0 f1cf282e 80e0e8df e0e0ff27 0994      ..(........'..  
Contents of section .sec2:
 7ffe [color=red]0206[/color]                                 ..

Ah.... That's explained that. I just needed a nudge in the right direction.

Now, why does the answer to one question lead to a whole bunch of suplimenty questions?

westfw:

> avr-objdump -march=avr -s optiboot_atmega328.hex 

optiboot_atmega328.hex:    file format ihex
Contents of section .sec1:
7e00 1f92cdb7 deb71124 84b714be 982f9d70  .......$...../.p
  :
7fc0 f1cf282e 80e0e8df e0e0ff27 0994      ..(........'.. 
Contents of section .sec2:
7ffe 0206                                ..

Section? (blue highlighting)

I can't find any reference in the Intel Hex File Format or the avr_objdump documentation.
Is it a "compiler thing"? Writing to two sections of memory, which, in this case just happen to be contiguous?

Many, (many), thanks for your patience, Martin

mprowe:
Ah.... That's explained that. I just needed a nudge in the right direction.

Now, why does the answer to one question lead to a whole bunch of suplimenty questions?

Section? (blue highlighting)

I can't find any reference in the Intel Hex File Format or the avr_objdump documentation.
Is it a "compiler thing"? Writing to two sections of memory, which, in this case just happen to be contiguous?

Many, (many), thanks for your patience, Martin

They are not contiguous, the .sec1 is actually section .TEXT, and .sec1 is the .version section.

.TEXT ends at 0x7FCD
.version starts at 0x7FFE

So, there is about 31 bytes of FLASH unused between them.

Chuck.

Section?

For a .hex file, I think it assumes that any discontinuity in the data starts a new "section." (I can delete a line from the middle of the contiguous code space, and suddenly I have three sections instead of two.)

For .elf and .o files, sections are a "big deal", and too complicated to explain here.
The optiboot implementation uses a separate section for the version number, which is what permits it to be place "at the end of Flash" while the code itself is placed "at the beginning of the bootloader section." (note that "bootloader section" is a hardware thing that is not particularly related to the .elf file "code sections.")

Bill,

Would you mind clarifying one thing?

I tried compiling Optiboot for my 1284p and on github, your boards.txt has this comment and low fuse setting:

Select full swing crystal oscillator (7F rather than FF)

optiboot1284.bootloader.low_fuses=0x7F

If I look at the fuse calculator here it looks like:
0x7F has CKDIV8 enabled and 0xFF is External Crystal
Now full swing appears to be 0xF7 without changing anything else, so is this a late-night typo?

Thank you very much.

Now full swing appears to be 0xF7 without changing anything else, so is this a late-night typo?

Yes, it appears so. I have the F7 value in the *_isp targets in the Makefile, but the wrong values in boards.txt.
Sigh. I've created Boards.txt fuse values for ATmega1284 are wrong. · Issue #174 · Optiboot/optiboot · GitHub

I hate to bug you again, but I had trouble burning the bootloader to my 1284P, so I attempted some troubleshooting and read a bunch of other things.

Since lock bits are not clear in my mind, I will simply state my findings, without attempting to comment.
So here it is: maniacbug has the lock bits as 0x0F instead of 0x2F. I was getting a verification error when attempting to burn the bootloader with 0x2F for the lock bit, but I was successful with 0x0F.

I will do some reading in an attempt to understand the lock bits, but I thought I should mention this.
And I apologize for not specifying earlier that I am looking at boards.txt for 1.6

Edit: After spending some time reading the datasheet, I think this is what needs to happen:
Unprogramming (1) bootloader lock bits BLB11 and BLB12 (0x3F) removes any restrictions accessing the boot loader, necessary to be able to write it to the chip.
Programming (0) them both (0x0F) locks writing to the boot loader and reading from it as well.
Only programming BLB11 (0x2F) just locks the bootloader for writing.

So, if I understand this correctly, both 0x0F and 0x2F lock the bootloader for write, which makes sense so that it doesn't get wiped out, but 0x2F allows the program to read from it.

In my case, both lock bit settings should have worked, as both are valid.
I will go back to 0x2F and retry, maybe I messed something else up.

Edit (again - sorry): It worked with 0x2f, so it was me.

Sorry for wasting your time.

Update - for the sake of closure, I wanted to explain how I got Optiboot compiled for my 1284p.

RTFM was the key here, but I was unable to upload a sketch until I overrode the baud rate.
I noticed that Arduino writes at 19200 through the programmer, so I used that baud rate as a compile option and it finally took the sketch.

Thank you very much for Optiboot, it is amazing.

Hi,

I thought I should write my own boot loader so that I could boot load through UART1 instead of UART0. I want to flash my hex file via a bluetooth module HC 05. But then I found bootloader called optiboot. Will the 1284 optiboot compiled for UART1 instead of UART0 (EXPERIMENTAL!) present in the Google Code Archive - Long-term storage for Google Code Project Hosting.... suffice my need ?

I was told by AVR clawson to sort it out with westfw :slight_smile:

I want to run at 9600 baud rate. Do I need to make any changes to the source code and if so how ?

Looking forward to hear from you,

Hi,

I've recently managed to install optiboot on an arduino nano with an ATmega328p. It works perfectly except when I power the board with my laptop via a usb cable. When I do so, the arduino flashes the led at pin 13 several times before executing the sketch. It executes the sketch instantly when powered vie the VIN pin though. I've no idea what's causing this.

Video D13 led is the lowest one. The sketch is supposed to turn leds connected to a shift register on and off.

Thanks in advance

EDIT: the sketch loads instantly when powered by the laptop when laptop is in sleep mode. I guess it waits for serial communication before running the sketch.

if there is something on your laptop that actually starts serial communication, it is normal for this to cause a reset and run the bootloader (causing the three flashes) (whereas a clean power-on with no serial involvement SHOULD go direct to the sketch.) This is due to the auto-reset circuitry of the Arduino. (which is somewhat sensitive; it wouldn't surprise me of certain power-up situations result in an "external reset" rather than a "power on" reset. I'm not sure whether USB enumeration (without actually opening the serial port) will do anything. But it's possible.)

Thanks for the quick reply, I've tried turning DTR off and shorting the RST pin to the GND pin with a 10uF capacitor as stated in the serial auto reset disable guide but those didn't help either. What confuses me is that this doesn't happen at all with my uno v3 which also has optiboot installed.

Party_Waffel:
Thanks for the quick reply, I've tried turning DTR off and shorting the RST pin to the GND pin with a 10uF capacitor as stated in the serial auto reset disable guide but those didn't help either. What confuses me is that this doesn't happen at all with my uno v3 which also has optiboot installed.

From my experience using the UNO V3 as an ISP programmer, and from what I've read, the V3 doesn't need the 10uF nor does it seem to be needed with the Pro mini I'm actually using as an ISP programmer. In both cases the DTR was left enabled.
Dave

Hi there,

I'm searching HEX file for the ATmega8-16PU MCU named "optiboot_atmega8-16.hex", can someone please upload it?

I was unable to find on the internet!

I need it for this entry to be able to burn Bootloader to my fresh ATmega8-16PU's!

##############################################################
opti8.name=Arduino Optiboot-Atmega8-16
opti8.upload.protocol=arduino
opti8.upload.maximum_size=7680
opti8.upload.speed=115200
opti8.bootloader.low_fuses=0xbf
opti8.bootloader.high_fuses=0xcc
opti8.bootloader.path=optiboot
opti8.bootloader.file=optiboot_atmega8-16.hex
opti8.bootloader.unlock_bits=0x3F
opti8.bootloader.lock_bits=0x0F
opti8.build.mcu=atmega8
opti8.build.f_cpu=16000000L
opti8.build.core=arduino
opti8.build.variant=standard
##############################################################

Thank you!

Here it is. I'm not sure where you got that boards.txt file from; I'm pretty sure that the atmega8 hex file has never had the -16 suffix (somewhat irrelevant since the currently provided .hex files don't include any atmega8 binaries.)
You'll probably have trouble using the "burn bootloader" command with any modern IDE; atmega8 has been broken for a long time. Using my OptiLoader Or Nick's (enhanced!) Bootloader programmer would be easier...

Edit: it won't let be attach .hex files. Zipped.

optiboot_atmega8-16.hex.zip (822 Bytes)

westfw:
Here it is. I'm not sure where you got that boards.txt file from; I'm pretty sure that the atmega8 hex file has never had the -16 suffix (somewhat irrelevant since the currently provided .hex files don't include any atmega8 binaries.)
You'll probably have trouble using the "burn bootloader" command with any modern IDE; atmega8 has been broken for a long time. Using my OptiLoader Or Nick's (enhanced!) Bootloader programmer would be easier...

Edit: it won't let be attach .hex files. Zipped.

Hi westfw,

I was Googling a few day now to find the easiest and the best solution and I came a cross to this page on Instructables.

And I got that boards.txt entry from that post, but it was strange to me also because of that suffix.

Thank you for your fast reply! 8)

westfw:
Here it is. I'm not sure where you got that boards.txt file from; I'm pretty sure that the atmega8 hex file has never had the -16 suffix (somewhat irrelevant since the currently provided .hex files don't include any atmega8 binaries.)
You'll probably have trouble using the "burn bootloader" command with any modern IDE; atmega8 has been broken for a long time. Using my OptiLoader Or Nick's (enhanced!) Bootloader programmer would be easier...

Edit: it won't let be attach .hex files. Zipped.

Me again and confused a little bit.

In the Arduino's "hardware\arduino\avr\bootloaders\optiboot" there is a HEX file optiboot_atmega8.hex and it's 1.36Kb (CRC32: 6d4bc037), but what I got from your zip file is optiboot_atmega8-16.hex and it's 1.28Kb (CRC32: 1336439d), so what is basically the difference between those two HEX files?

Thank you!

The Optiboot from the IDE is version 4.4; the .hex file I posted is version 6.2 ...
There are probably not any changes that are particularly relevant to the m8 (ie no reason to use the newer one)
Most of the edits have added other chips, corrected for new compiler behavior, or enhanced the build system.
(You can view the edits at GitHub - Optiboot/optiboot: Small and Fast Bootloader for Arduino and other Atmel AVR chips