optiboot 5.0a with atmega8@8MHZ does not work but v4.4 does.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. make atmega8 AVR_FREQ=8000000L BAUD_RATE=9600 LED_START_FLASHES=10
2. burn chip with hfuse : 0xca, lfuse : 0xdf via avrstudio
3. add folowing section in arduino IDE 1.0.5:

##############################################################

atmega8l.name= ATmega8 @ 8MHZ Optiboot

atmega8l.upload.protocol=arduino
atmega8l.upload.maximum_size=7680
atmega8l.upload.speed=9600

atmega8l.bootloader.low_fuses=0xdf
atmega8l.bootloader.high_fuses=0xca
atmega8l.bootloader.path=optiboot
atmega8l.bootloader.file=optiboot_atmega8.hex
atmega8l.bootloader.unlock_bits=0x3F
atmega8l.bootloader.lock_bits=0x0F

atmega8l.build.mcu=atmega8

atmega8l.build.f_cpu=8000000L
atmega8l.build.core=arduino
atmega8l.build.variant=standard

##############################################################

Then open arduino and upload user code to atmega8@8MHZ, I will get:
avrdude: stk500_cmd(): programmer is out of sync.
I tried bund rate from 9600, 19200, 38400 to 115200, the same error occured.

What is the expected output? What do you see instead?
avrdude: stk500_cmd(): programmer is out of sync.
It should work as V4.4, but not.

What version of the product are you using? On what operating system?
V5.0a, WinXP, WinAVR-20100110

Please provide any additional information below.
If I compile v4.4 with F_CPU=8000000L & BUND_RATE=9600, upload will always 
succeed.

Thanks for your contribution!

Original issue reported on code.google.com by hebi...@gmail.com on 20 Feb 2014 at 2:29

[GoogleCodeExporter]

The UART initialization code ends up being exactly the same...

Hmm.  Exactly what changes did you make in 4.4 to build a m8 8MHz bootload?  
The obvious makefile change seems to invoke the SW UART, which doesn't compile 
at all.
Did you use the LED_START_FLASHES=10 there as well?  It occurs to me that 10 
flashes at 8MHz may be perilously close to the 1s watchdog timeout used...

Original comment by wes...@gmail.com on 12 Mar 2014 at 1:04

[GoogleCodeExporter]

I will try it again with LED_START_FLASHES=10 & default value for both 
versions. Thanks for your hint.

Original comment by hebi...@gmail.com on 4 Apr 2014 at 4:28

[WestfW]

So it turns out that optiboot seems to be pretty fragile with values of LED_START_FLASHES much bigger than 3, even on ATmega328s running at 16MHz. It looks like this is because AVRDUDE is pretty aggressive sending its initial GET_SYNC messages, sending 3 in quick succession. This ends up overrunning the AVR UART's buffer, causing the command sequence to be out-of-sync thereafter.

A fix is to add code the the LED flashing code to abort if UART data is seen. This seems to improve reliability (and perhaps even response time) quite a bit.

https://github.com/Optiboot/optiboot/commit/b109eb2615b570ce326e2664553f5d7c5ae9af26