New optiboot; beta testers welcome...

Note that the optiboot hex file for 1284 will NOT work in a 644 (or at least is not expected to work), because the bootloader is located at the end of flash memory, and that's in a different place on the two chips. AVR code usually contains at least some absolute address references...

westfw:
Note that the optiboot hex file for 1284 will NOT work in a 644 (or at least is not expected to work), because the bootloader is located at the end of flash memory, and that's in a different place on the two chips. AVR code usually contains at least some absolute address references...

Bill, is this just a linker issue?

No, because it needs to know the internal address of the "Read While Write Flash" area in the source code as well (but the source already knows about 644p, so at least in theory if you can compile/link from source you shouldn't have any problems building a 644 version ("make sanguino")

However, the 644 version predates my involvement and hasn't been tested, so i don't know whether it works.

westfw:
No, because it needs to know the internal address of the "Read While Write Flash" area in the source code as well (but the source already knows about 644p, so at least in theory if you can compile/link from source you shouldn't have any problems building a 644 version ("make sanguino")

However, the 644 version predates my involvement and hasn't been tested, so i don't know whether it works.

Thanks Bill, I did notice the Sanguino option in the list of targets, but I have not tried it, and didn't look to see what changed. If someone wants to try Optiboot with Sanguino, I'll build it and post it.

westfw:
However, the 644 version predates my involvement and hasn't been tested, so i don't know whether it works.

Ditto here. Never tested it. If someone wants to send me a Sanguino, I'll make sure it works :grin:

the 644 version predates my involvement and hasn't been tested

Well, now it's been tested.

It doesn't work.

It has the wrong signature for an ATmega644p (it makes it look like an ATmega644.)
You can tell boards.txt that you have a 644 and upload will work, but then the pins_arduino.c doesn't get correct values.
(and why does it have an incorrect signature byte? Because avr-libc is actually wrong in the version that ships with Arduino. It's not even an optiboot bug. Sigh. AVR C Runtime Library - Bugs: bug #26188, Wrong or missing definition of... [Savannah]

It also has an incorrect efuse value in the Makefile (should be 0xFD, with the "unused" bits set to 1, but the makefile has 0x05)

http://code.google.com/p/optiboot/issues/detail?id=61

westfw:

the 644 version predates my involvement and hasn't been tested

Well, now it's been tested.

It doesn't work.

It has the wrong signature for an ATmega644p (it makes it look like an ATmega644.)
You can tell boards.txt that you have a 644 and upload will work, but then the pins_arduino.c doesn't get correct values.
(and why does it have an incorrect signature byte? Because avr-libc is actually wrong in the version that ships with Arduino. It's not even an optiboot bug. Sigh. AVR C Runtime Library - Bugs: bug #26188, Wrong or missing definition of... [Savannah]

It also has an incorrect efuse value in the Makefile (should be 0xFD, with the "unused" bits set to 1, but the makefile has 0x05)

Google Code Archive - Long-term storage for Google Code Project Hosting.

First thanks for making it an issues, second that brings me some light on the fact that all from me testet bootloaders does't work sometimes about the Signature or that i have to change the build.mcu to the version without the "P" at the end.

The source at Google Code Archive - Long-term storage for Google Code Project Hosting. has been fixed, and I've added a .hex file for 644p to the download area.

It's still tagged as v4.5, since this didn't change any object code of previously supported platforms. And like the 1284p support, the 644p is not an official Arduino team platform, so this won't be committed to the Arduino repository until it's time for some sort of big "upgrade."

Cool! Thanks!

westfw:
The source at Google Code Archive - Long-term storage for Google Code Project Hosting. has been fixed, and I've added a .hex file for 644p to the download area.

It's still tagged as v4.5, since this didn't change any object code of previously supported platforms. And like the 1284p support, the 644p is not an official Arduino team platform, so this won't be committed to the Arduino repository until it's time for some sort of big "upgrade."

Yeah, cool, thanks!

Did you fix the problem with the second UART too?

What problem with the second UART?

You use Serial.begin(speed);
and Serial1.begin(speed);
What problem?

(the bootloader currently only supports uart 0, on devices with more than one uart.)
No, not changed yet. Working on it...

If you were having trouble at the sketch or C level, that might have been due to the differences between 644 (which apparently only has one uart) and 644A/644P (which have two. Even though 644A has the same signature as 644. "Bad Atmel!")

westfw:
(the bootloader currently only supports uart 0, on devices with more than one uart.)
No, not changed yet. Working on it...

If you were having trouble at the sketch or C level, that might have been due to the differences between 644 (which apparently only has one uart) and 644A/644P (which have two. Even thought 644A has the same signature as 644. "Bad Atmel!")

That is rather bizarre when it's the mothership at fault (or partial fault) sometimes. We depend on her for so much. :wink:

westfw,

Back in August of last year, I found your request for beta testers, downloaded the optiboot_atmega328.hex file (June 2011 version). I've been using since then, without problems. I'm getting ready to burn the bootloader on another ATMEGA328 chip, and would like to know what the latest-and-greatest bootloader you recommend, and where I can download it from. I went here: http://code.google.com/p/optiboot/downloads/list

If this is the right place, do I choose Optiboot v4.4? How is this different from the optiboot_atmega328.hex file that comes with Arduino 1.0?

Your help is greatly appreciated. Thanks in advance.

do I choose Optiboot v4.4?

Probably. Unless you need one of the "features" added since then (m1284 and m644 support, and some changes to support newer versions of the compiler.)

How is this different from the optiboot_atmega328.hex file that comes with Arduino 1.0?

The optiboot_atmega328.hex file that comes with Arduino 1.0 is identical to the hex file is identical to the v4.4 download from the optiboot. The mercurial source tree is slightly newer (v4.5) and has the changes I mentioned...

Thanks!

I wanted to try this on some 328p ICs but the sketch doesn't run and I've tried programming the hex file onto the IC with my AVR ISP Mk2 but the IDE refuses to upload the sketch.

Questions

I tried programming the file "optiboot_atmega328.hex" from hardware/arduino/bootloaders/optiboot - Is this the right file?

What sketch space SHOULD be available if optiboot is working?

I'm assuming that maybe it isn't working because the fuses are wrong. - What do I set the fuses to under AVR Studio 5 and the AVR ISP Mk2, I've tried just changing the BOOTSZ to 512W_3E00 but it didn't have an affect and I don't know much about the fuses.

Thanks....

Searches find different answers, tried Ex = FF, hi = DE & lo = D6 but still comes up with 30720 free and doesn't program

Whoops.......

and then set board type to UNO :slight_smile:

It is working after all.

I've added (at least theoretically) support for UARTs otehr than UART0 on m644, m1284, and m1280 cpus. But I don't have hardware that makes it convenient to test such support. Did some of you say that you had HW that wanted to upload sketches over the 2nd uart? If so, I can email you a .hex file to try out...

That's interesting. So if a USB/Serial adapter was on either port sketches could be uploaded?