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?

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.

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.

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.

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.

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.

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

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?

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.

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

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

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=12d0c32cc84457603b4c496fe621f22b90c96db7http://code.google.com/p/optiboot/source/detail?r=12d0c32cc84457603b4c496fe621f22b90c96db7

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

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=12d0c32cc84457603b4c496fe621f22b90c96db7