NEWER New Optiboot bootloader

Using Arduino Microcontrollers
#43

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 [color=blue]Contents of section .sec1:[/color] 7e00 1f92cdb7 deb71124 84b714be 982f9d70  .......$...../.p   : 7fc0 f1cf282e 80e0e8df e0e0ff27 0994      ..(........'..  [color=blue]Contents of section .sec2:[/color] 7ffe [color=red]0206[/color]                                .. ```

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

#44

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.

#45

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.")

#46

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.

#47

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 https://github.com/Optiboot/optiboot/issues/174

#48

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.

#49

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.

#50

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 https://code.google.com/archive/... suffice my need ?

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

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,

#51

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.

#52

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.)

#53

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.

#54

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

#55

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!

#56

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)

#57

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)

#58

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!

#59

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 https://github.com/Optiboot/optiboot

#60

Hello,

I just saw You made support for the 328PB Chip.

I asked this some time ago, but did NOT got definitive answer.

Can be those boatloader used in commercial Products like Arduino UNO "clones"? Which kind of bootloader those boards from China are using as bootloadeR?

Regards, Maverick

#61

I asked this some time ago, but did NOT got definitive answer. Can be those boatloader used in commercial Products like Arduino UNO "clones"?

Yes. The original author licensed Optiboot under GPL2, and it would certainly be painful to change the license since he disappeared. I'm not sure that it's clearly defined what GPL2 means WRT bootloaders, but I'd put them in the same class as Desktop Operating Systems - of course you can write commercial products that run on open source operating systems! If you make changes to optiboot itself as part of your commercial product, you should be prepared to release those changes as open source as well. Personally, I lean toward less viral licenses (MIT or BSD.)

Which kind of bootloader those boards from China are using as bootloadeR?

How could anyone possibly know that? Reports have ranged from Optiboot (but I don't know what version) (especially for Uno clones), Atmegaboot (especially on Nano clones), Adaboot (on Pro Mini clones, as per Sparkfun?), and "doesn't seem to have any bootloader at all".

#62

Thanks,

I would not going to change anything on the software. But without the software the hardware is useless.

I want to use 328PB under the IDE, but have got some problems here. I have changed the board file and placed the hex file to the correct directory. I also changed the pins_arduino.h file.

optibootxmini328pb.name=Optiboot Xplained Mini 328pb

optibootxmini328pb.upload.tool=arduino:avrdude
optibootxmini328pb.upload.protocol=arduino
optibootxmini328pb.upload.speed=57600

optibootxmini328pb.bootloader.tool=arduino:avrdude
optibootxmini328pb.bootloader.unlock_bits=0x3F
optibootxmini328pb.bootloader.lock_bits=0x2F

optibootxmini328pb.build.f_cpu=16000000L

optibootxmini328pb.build.board=AVR_UNO
optibootxmini328pb.build.core=arduino:arduino
optibootxmini328pb.build.variant=arduino:standard

optibootxmini328pb.upload.maximum_size=32128
optibootxmini328pb.upload.maximum_data_size=1024

optibootxmini328pb.bootloader.low_fuses=0xBF
optibootxmini328pb.bootloader.high_fuses=0xCE
optibootxmini328pb.bootloader.extended_fuses=0xFF
optibootxmini328pb.bootloader.file=optiboot/optiboot_xplained328pb.hex

optibootxmini328pb.build.mcu=atmega328p

I'm still not able to upload anything over IDE.

Any Ideas why?

Regards, Maverick