Errors building Optiboot 5.0a for Arduino Pro 3.3

I'd like to run optiboot on an Arduino Pro 3.3V however I'm unable to upload sketches after burning the bootloader. I did some searching and it seems that 115.2K is too fast for 8Mhz Arduinos. I was able to build optiboot 4.4 at 56K and upload sketches but I get errors when building 5.0a.

On Linux I added the Arduino avr-gcc to my path

export PATH=/home/andrew/Downloads/arduino-1.0.5/hardware/tools/avr/bin:$PATH

and modified the Makefile to specify the lower speed:

atmega328_pro8: CFLAGS += ‘-DLED_START_FLASHES=3’ ‘-DBAUD_RATE=57600’

but when I build I get:

andrew@ubuntu:~/Downloads/arduino-1.0.5/hardware/arduino/bootloaders/optiboot$ make atmega328_pro8
make atmega328 AVR_FREQ=8000000L LED_START_FLASHES=3
make[1]: Entering directory `/home/andrew/Downloads/arduino-1.0.5/hardware/arduino/bootloaders/optiboot’
baudcheck.tmp.sh: 8: baudcheck.tmp.sh: Bad substitution
make[1]: [baudcheck] Error 2 (ignored)
avr-gcc -g -Wall -Os -fno-inline-small-functions -fno-split-wide-types -mshort-calls -mmcu=atmega328p -DF_CPU=p�Q -DBAUD_RATE=115200 -DLED_START_FLASHES=3 -c -o optiboot.o optiboot.c
optiboot.c:249:5: error: token “�” is not valid in preprocessor expressions
...

-DF_CPU=p�Q is the problem - that should be -DF_CPU=8000000L

Check that F_CPU is being set correctly in the makefile - it looks like it's being set to gibberish. It should be 8000000L for an 8mhz chip.

That said, I'm surprised 115.2kbaud isn't working for you at 8 - I've got optiboot working fine at 115.2 on 8mhz attiny841/1634.

That's set by a variable. I did find some non ascii chars in baudrate.tmp.sh "fcpux=àf¦" so looks like the files got corrupted somehow.

The latest and previous Arduino IDEs seem to come with optiboot 4.4 so I think I'll just go with that.

What are you using to upload? Do you have auto-reset enabled? I tried many times and never worked. I tried two different FTDI boards

rappa:
What are you using to upload? Do you have auto-reset enabled? I tried many times and never worked. I tried two different FTDI boards

I'm curious too. I've had no success with 328p's at 8MHz with 115.2k, whether it was for uploading or for chip-to-chip communication, running off pretty solid 8MHz clocks (not the internal). I'd love to be able to if so though.

rappa, you should be able to load the 16MHz bootloader and then just upload at 1/2 the baud rate the bootlaoder was compiled for (normally 115.2k, so in boards.txt set the upload for 8MHz board to 57.6k). This is how I do it on some 8MHz 640's I built recently, versus compiling a new bootloader.

115.2k on 8MHz clock has a potential error of 8.5%, which is well past the recommended by Atmel (helpful reference). I've had no issues uploading to 8MHz 328p's and 640's at 57.6k.

rappa:
That's set by a variable. I did find some non ascii chars in baudrate.tmp.sh "fcpux=àf¦" so looks like the files got corrupted somehow.

The latest and previous Arduino IDEs seem to come with optiboot 4.4 so I think I'll just go with that.

What are you using to upload? Do you have auto-reset enabled? I tried many times and never worked. I tried two different FTDI boards

Eew.

I'm using optiboot as of like febuary sometime (so not quite latest version) - I haven't updated since westfw moved to github.

Do make sure you're bootloading successfully by reading out flash contents and fuse after bootload, if it's not working.

I do use autoreset (not using it kinda makes life suck!). It works over FTDI or CH340G-based adapters (yes, the CH340G does have a DTR pin, most boards just don't break it out, but SOIC pins are big enough that you can get a wire on the pin, and get a USB serial adapter for programming for under $2)

8.5%? I get 7.9 (1-(11520016(UBBRL+1)/8000000) with U2X=0, 3.7% with U2X=1. I am using U2X=1, which optiboot already did when I was using it.

I wonder if the internal oscillator is calibrated better on the '841 and '1634 than on the '328...?

DrAzzy:
8.5%? I get 7.9 (1-(11520016(UBBRL+1)/8000000) with U2X=0, 3.7% with U2X=1. I am using U2X=1, which optiboot already did when I was using it.

I wonder if the internal oscillator is calibrated better on the '841 and '1634 than on the '328...?

Well my experience is all with external 8MHz crystals+caps and not the internal oscillator so I can't weigh in on that thought. I don't think I've been using Optiboot on the 8MHz parts though, which I ought to remedy since the boards.txt is the only change I ought to need. As for the error I referenced, I got it from the link in my last post, perhaps there is an error.

madmattd:
I'm curious too. I've had no success with 328p's at 8MHz with 115.2k, whether it was for uploading or for chip-to-chip communication, running off pretty solid 8MHz clocks (not the internal). I'd love to be able to if so though.

rappa, you should be able to load the 16MHz bootloader and then just upload at 1/2 the baud rate the bootlaoder was compiled for (normally 115.2k, so in boards.txt set the upload for 8MHz board to 57.6k). This is how I do it on some 8MHz 640's I built recently, versus compiling a new bootloader.

115.2k on 8MHz clock has a potential error of 8.5%, which is well past the recommended by Atmel (helpful reference). I've had no issues uploading to 8MHz 328p's and 640's at 57.6k.

That worked however the delays in my sketch are have doubled

DrAzzy:
Eew.

I'm using optiboot as of like febuary sometime (so not quite latest version) - I haven't updated since westfw moved to github.

Do make sure you're bootloading successfully by reading out flash contents and fuse after bootload, if it's not working.

I do use autoreset (not using it kinda makes life suck!). It works over FTDI or CH340G-based adapters (yes, the CH340G does have a DTR pin, most boards just don't break it out, but SOIC pins are big enough that you can get a wire on the pin, and get a USB serial adapter for programming for under $2)

8.5%? I get 7.9 (1-(11520016(UBBRL+1)/8000000) with U2X=0, 3.7% with U2X=1. I am using U2X=1, which optiboot already did when I was using it.

I wonder if the internal oscillator is calibrated better on the '841 and '1634 than on the '328...?

oh, auto-reset would be nice. How do you configure that? I did some searching but didn't find much except for a mention of connecting the DTR pin to reset with a cap.

rappa:
oh, auto-reset would be nice. How do you configure that? I did some searching but didn't find much except for a mention of connecting the DTR pin to reset with a cap.

Yup - it's that simple.

0.1uf cap between reset and the DTR pin of the serial adapter.

DTR is brought low to signify serial connection established (Data Terminal Ready), by capacitative coupling, that brings RESET low - but then the cap gets charged back up, so reset is only held low briefly - that capacitor and resistor convert the DTR signal, which goes low and stays low, into the pulse needed to reset the chip and then let the bootloader run

Of course, you also need the 10k resistor between reset and Vcc, but you ought to have that anyway.

rappa:
That worked however the delays in my sketch are have doubled

You need to change the CPU frequency in the boards.txt too.

optiboot.c:249:5: error: token "�" is not valid in preprocessor expressions
...

This is/was apparently a bug in make, though I don't know that it was ever fully understood (it "goes away" with more recent versions of make.)
See Content of AVR_FREQ gets messed up --> F_CPU set to invalid characters (Make bug!) · Issue #106 · Optiboot/optiboot · GitHub