Optiboot does not work on 5V Pro Minis

[GoogleCodeExporter]

Board: 5V Pro Mini, ATMega328P @ 16MHz
Bootloader: optiboot_atmega328.hex from the zip file from this site

The bootloader installs fine, but completely fails to communicate with avrdude. 
 I've tried the baud rates from the replacement boards.txt (115200) and a few 
others beside, but the bootloader is completely unresponsive.  I've tried 
connecting to the bootloader with a serial terminal, and I get nothing back, 
not even line noise.

The Pro Mini uses a not-particularly-accurate resonator instead of a crystal, 
and from looking through the optiboot code it appears that the serial comms is 
clocked in software - is it perhaps possible that serial clock skew is causing 
the problems?

Original issue reported on code.google.com by Alan.Bur...@gmail.com on 8 Jan 2011 at 11:21

[GoogleCodeExporter]

Some additional details: if I reset the board LED13 flashes (I think) 3 times 
in quick succession.  If I connect with a serial terminal it also flashes a 
couple of times - difficult to tell as it's so fast.  It therefore appears that 
at least the reset part of the bootloader is doing something.

Original comment by Alan.Bur...@gmail.com on 8 Jan 2011 at 11:26

[GoogleCodeExporter]

I think I've figured out what the issue is.  Pro Minis need to be programmed 
with a FTDI board (http://www.sparkfun.com/products/9115), and I'm using the 
'arduino' programmer type.  The avrdude upload baud rate in the Optiboot 
Makefile is 115200 (-DBAUD_RATE=115200) and that that speed it appears the 
auto-reset logic on the FTDI board can't quite keep up.  If I get it just 
right, I can press the reset on the board and get the bootloader to upload a 
sketch at 115200 baud but it's *very* hit and miss.  If I recompile Optiboot 
with -DBAUD_RATE=57600 (the standard for that board) then it works fine.

I don't think hiking the optiboot upload baud rate up to the max is a good idea 
- the values in the default boards.txt are presumably there for a reason, based 
on experience on a large number of boards.  Inevitably there will be production 
variations, and just because a particular baud rate works on one particular 
board in testing, it doesn't mean it's going to work everywhere.  I'd strongly 
recommend using the values from the default boards.txt, both for familiarity - 
if you don't know which bootloader is on the board, which baud rate do you use 
- and to prevent mysterious problems such as this.  I suspect several of the 
other issues reported against optiboot are because of this problem.  Saving 
5-10 seconds on an upload is the wrong tradeoff if it causes random upload 
failures.

Original comment by Alan.Bur...@gmail.com on 19 Jan 2011 at 12:45

[GoogleCodeExporter]

FWIW, I've put optiboot on several FTDI-cable connected Arduinos (my Single 
Sided Serial Board with a mega8 and an Adafruit BoArduino w/m168, at least) and 
not had any similar problems.  I am using the "real" FTDI cable, though.

Original comment by wes...@gmail.com on 22 Jan 2011 at 3:32

[GoogleCodeExporter]

I'm using the SparkFun FTDI breakout board and that has an auto-reset feature.  
It's the reset that's the problem, if I manually reset the board and get it 
just right it will upload, but as I said it's very hit and miss.

Original comment by Alan.Bur...@gmail.com on 22 Jan 2011 at 9:03

[GoogleCodeExporter]

More info: I've tried five different Pro Minis, setting the baud rate to 57600 
instead of 115200 and whilst four of them upload fine with Optiboot, one of 
them doesn't.  I can get it to work by manually resetting the board, and it 
works fine with the standard Arduino bootloader.  Clearly there's some sort of 
timing issue related to resets, I'll have to tinker some more.

Original comment by Alan.Bur...@gmail.com on 23 Jan 2011 at 6:23

[GoogleCodeExporter]

We were burning some Optiboot bootloaders at Modern Device. We have always used 
our BUB's which are similar to the Sparkfun board listed above (I've never 
checked the schematic but how many ways can you hook up an FTDI chip?), without 
ever bothering to program the logic select line - connected to pin 4. 

When we connected the pin 4 programming to Either 5V or 3.3V - voila - optiboot 
upload. So check your Sparkfun board with a meter and see if pin 4 is connected 
to anything.

The weird thing is that upload always works fine (with pin 4 floating)  with 
the Deicimila / Duemilanove bootloader, but as the discussion above indicates - 
it's probably just a timing issue with the higher voltage logic drive, leading 
to faster rise time.

Paul Badger & Shawn Wallace
Modern Device

Original comment by flux...@gmail.com on 11 Mar 2011 at 7:24

[GoogleCodeExporter]

I'm not sure what you are referring to when you say 'pin 4', do you mean pin 4 
on the FTDI board, or on the ATMega itself?

Original comment by Alan.Bur...@gmail.com on 11 Mar 2011 at 9:40

[GoogleCodeExporter]

I have just put Optiboot on a Pro-Mini (5V, 16Mhz, atmega328), using Westfw's 
"optifix" sketch running on an Uno as the programmer.  The upload worked very 
nicely and the board now passes the "chaucer32k" test, running a 31868 byte 
binary.

Original comment by tim...@gmail.com on 22 Mar 2011 at 12:00

[GoogleCodeExporter]

Using a method that had previously worked seamlessly (a batch file to set fuse 
bits, program bootloader, set lock bits, upload code via FTDI breakout), I was 
running into a very similar problem while programming a big batch of ATmega328P 
DIP chips. This time, after getting Optiboot on the ATmega, and trying to 
upload the sketch via the FTDI, the RX LED on the FTDI board would blink three 
times, and the resulting, unimaginative "avrdude: stk500_disable(): protocol 
error, expect=0x14, resp=0x51" error would appear.

I tried a large handful of chips, and four FTDI boards, same error every time. 
The FTDI boards are unmodified 3.3V and 5V versions of the SparkFun FTDI Basic 
Breakout. On the breakouts pin 4 of the FT232RL is either tied to 3V3OUT, or 
VCC of the IC, depending on the version. I also wasn't having any luck at 
slower baud rates though, 57600, 19200...didn't matter.

What really had me perplexed though, is that I'm using the same programming jig 
(with 16MHz crystal, vreg, etc.), FTDI board, and batch file as I had when this 
problem never seemed to have existed. The only thing that's changed is the 
batch of ATmega328s.

Further, I replaced the FTDI board with a SparkFun ATmega8U2 Breakout 
(http://www.sparkfun.com/products/10277), which was loaded with the 
USB-to-Serial firmware, and was instantly successful in loading the example 
sketch. So the problem seemed to center around the FTDI board not cooperating 
with this batch of ATmegas.

Because I suggest the FTDI board to all of my customers, I really wanted to get 
it working with them. So, I dug into optiboot.c and ended up modifying line 
237, previously "watchdogConfig(WATCHDOG_500MS);", to 
"watchdogConfig(WATCHDOG_1S);". Slowing down the watchdog timer by 500ms, seems 
to resolve the issue. My guess is the FTDI isn't sending the code across fast 
enough, after setting the DTR pin and resetting the ATmega, but just a guess.

This works for me, but does it seem shortsighted at all to be slowing down the 
watchdog like this? It looks like it's turned off just before the bootloader is 
exited anyway, so I'm hoping it'll only really have a (positive) effect when 
the chip is getting a new sketch loaded on.

-Jim

Original comment by jimlindb...@gmail.com on 16 May 2011 at 5:30

[GoogleCodeExporter]

Can confirm that the watchdog change from 500 ms to 1s fixed it - see a related 
discussion here: http://forum.jeelabs.net/comment/1188#comment-1188

Original comment by jc@wippler.nl on 25 May 2011 at 10:32

[GoogleCodeExporter]

Ahh.  The default watchdog timeout was changed from 500ms to 1s back on 
12-oct-2010 as part of various platform additions.   However, this set of edits 
never made it into a downloadable zip file or onto the Arduino version, until 
the recent major update that is going into "Arduino 1"

http://code.google.com/p/optiboot/source/detail?r=12d0c32cc84457603b4c496fe621f2
2b90c96db7http://code.google.com/p/optiboot/source/detail?r=12d0c32cc84457603b4c
496fe621f22b90c96db7

(pay no attention to the misleading "first line" of the commit message.)

Original comment by wes...@gmail.com on 30 Oct 2011 at 10:31

• Changed state: Fixed

[GoogleCodeExporter]

The link to code.google.com is not working -- the link is kind of double
correct link

http://code.google.com/p/optiboot/source/detail?r=12d0c32cc84457603b4c496fe621f2
2b90c96db7

Original comment by saji...@gmail.com on 13 Dec 2013 at 1:47