Pages: [1]   Go Down
Author Topic: UNO vs. Optiboot vs. ArduinoISP - what's the current status?  (Read 3565 times)
0 Members and 1 Guest are viewing this topic.
Boston, MA
Offline Offline
Full Member
***
Karma: 0
Posts: 129
Batteries? We don't need no steenking batteries!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


UPDATED: Here is what I know so far: As of 12/12/2011...

* There is no bug in the Uno bootloader that breaks ArduinoISP, and there never was. The "Currently, you cannot use an Arduino Uno as an ISP programmer..." note on the ArduinoISP page refers to the auto-reset issue (recent Optiboot versions have an explicit hack-around for this), which is not Optiboot-specific, is well known and easily worked around in other versions. The workaround for this is to place a low-value (~120 ohms) resistor between the Arduino's RESET header and 5V to force RESET high, or (if you have a soldering iron) cut the RESET-EN jumper to disable auto-reset outright. Again, if you go the jumper-cutting route, you need a soldering iron to undo this.

* However, there is a (separate) problem that occurs with Arduino 1.0. In the Arduino 1.0 core, the serial buffer size has been reduced from 128 to 64. For reasons unknown (the STK500 protocol + UNO shouldn't ordinarily leave >64 bytes unhandled), this causes the ArduinoISP sketch to break during writing the first Flash page(?).

* THE FIX to use ArduinoISP with UNO (or anything else): Install the previous Arduino (0022) and use that to compile/upload ArduinoISP. It's probably a good idea to keep both around for a while, as it appears 1.0 makes a laundry list of other changes that appear likely to break certain sketches. You could also hack around in the core to re-increase the buffer size, but I don't recommend this generally.

------

Hi,
I seem to be going on a protracted webforum pointer chase trying to find out the current status of using ArduinoISP with an UNO board. The ArduinoISP page (which has not been updated on some time) obliquely mentions a bootloader(???!!!) issue that causes the sketch not to work with an Uno, which "will be fixed soon". Various posts on various other webforums (example) say it works just fine for them, and/or there was no issue to begin with (aside from the well-known issue of having to defeat "auto-reset" before burning the bootloader - e.g. cut the jumper, or wire a 120 ohm pullup resistor to RESET to force it high).

Based on those, I advised my coworker to buy an UNO and use it as a programmer for Arduino+AVR based projects. I've been using it on my home Duemilanove board for some time without incident, unfortunately those are not commonly available for sale anymore. The UNO arrived, and sure enough, it fails consistently with ArduinoISP / avrdude at about 96%, as follows:

Code:
D:\arduino-0022\hardware\tools\avr\bin\avrdude.exe -b 19200 -p atmega644p -C D:\arduino-0022\hardware\tools\avr\etc\avrdude.conf -c stk500v1 -P COM2  -V -V -V -V -U flash:w:ATmegaBOOT_644P.hex:i

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.04s

avrdude.exe: Device signature = 0x1e960a
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be perfo
rmed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "ATmegaBOOT_644P.hex"
avrdude.exe: writing flash (65466 bytes):

Writing | ################################################   | 96% 0.01s
avrdude.exe: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
Writing | ################################################## | 100% 5.17s

avrdude.exe: failed to write flash memory, rc=-4

avrdude.exe: stk500_cmd(): programmer is out of sync

More forum goose-chasing based on this error message has turned up various non-official Optiboot hacks / forks of various ages that are supposed to work around the issue... whatever that undocumented issue happens to be.

I tried the one described here:
http://aeroquad.com/showthread.php?2364-Uno-optiboot-issue ->
http://aeroquad.com/showthread.php?2352-AeroQuad-Flight-Software-v2.4&p=24446&viewfull=1#post24446 ->
http://aeroquad.com/showthread.php?2365-Uno-problems-with-2.4&p=24448&viewfull=1#post24448

(successfully replaced the Uno's bootloader using the Duemilanove +ArduinoISP) ...but no change. Westfw's Optiloader also sounds promising, but sounds like would require a lot of hand-hacking to work in my case (burning a custom bootloader to a custom '644-based board). Keep in mind this is for a coworker (analog guy who is new to microcontrollers), and I would like to send him off with the give-a-man-a-fishing-pole solution rather than handing him a fish (i.e. handing back his Uno with some various not-well-understood hacks pre-applied). To that end I need to understand for myself what the actual issue is.

Soooo....

Can anyone explain what the actual issue is that causes the existence of (???an older???) Optiboot on the Uno board to break the ArduinoISP sketch? Perhaps more importantly, how is it that ANY bootloader issue is affecting the operation of any user sketch to begin with, since the bootloader should be long since out of the picture by then?

Thanks!

« Last Edit: December 12, 2011, 10:27:53 am by Drmn4ea » Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 106
Posts: 6367
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
there was no issue to begin with (aside from the well-known issue of having to defeat "auto-reset" before burning the bootloader
that WAS the initial issue.  With older Arduinos, the bootloader was smart enough to start the ArduinoISP sketch without autoreset being disabled.  (because the bootloader and ArduinoISP ran at different baud rates, causing the AVRDude commands sent to ArduinoISP to look illegal to the bootloader.)  This intelligence was lost in the brain-size reduction for optiboot (it's back in now, but I don't know whether the new bootloader is shipping on Uno's yet.)

Quote
avrdude.exe: writing flash (65466 bytes):
Writing | ################################################   | 96% 0.01s
This looks like a different problem than I've seen described before, perhaps related to being so close to the 16bit addressing limit of the protocol that ArduinoISP uses to communication with the PC.  MOST of the "can't get ArduinoISP working with XXX" problems have been things that prevent programming from starting at all; way at the start of the process...
Logged

Boston, MA
Offline Offline
Full Member
***
Karma: 0
Posts: 129
Batteries? We don't need no steenking batteries!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks for the info! I am curious why the owner of the ArduinoISP page is so coy about this being the issue - the problem is easily worked around, fairly well known, and in my experience (linked above) can affect pre-Uno (at least Duemilanove that I know of) Arduinos too. But I'm glad to know there shouldn't be any separate bootloader-specific issue aside from the auto-reset.

That said, I am still perplexed by the result above. The bootloader I'm trying to install is the Mosquino bootloader (Sanguino's Adaboot with very minor changes) for an ATmega644PA, which I've done (using a Duemilanove/168) dozens of times without incident. With the same target board, the same .hex file and the same version of ArduinoISP, with the Duemilanove and the Uno side by side, the process consistently works flawlessly on the Duemilanove but always fails as above on the Uno.

This leads me to guess it's not an addressing issue - since that should have failed in both cases, right? The only thing I can think of is a timing issue exposed by the differences (latency / serial buffer size?) between the Uno's USB->serial solution and the FT232 used in previous versions (although if this were the case I'd expect more people to have discovered it by now...) Does this seem reasonable?

To test it, are there any known quick & easy ways to slow down the rate at which avrdude (ArduinoISP?) tries to perform flash operations?
Logged

Boston, MA
Offline Offline
Full Member
***
Karma: 0
Posts: 129
Batteries? We don't need no steenking batteries!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Solved!...ish.

Re-googling the "protocol error, expect=0x14, resp=0x64" as of this morning turned up the following:
http://arduino.cc/forum/index.php?topic=82567.0
which points to
http://code.google.com/p/arduino/issues/detail?id=661

Going back to 0022 fixes it. This problem (once auto-reset is ruled out) appears specific to the Arduino 1.0 core.

In short, here is what I know so far:
* In the Arduino 1.0 core, the serial buffer size has been reduced from 128 to 64. For reasons unknown (the STK500 protocol + UNO shouldn't ordinarily leave <64 bytes unhandled), this causes the ArduinoISP sketch to break during writing the first Flash page(?).
* There is no bug in the Uno bootloader that breaks ArduinoISP, and there never was. The "Currently, you cannot use an Arduino Uno as an ISP programmer..." note on the ArduinoISP page is a sham - it refers to the auto-reset issue (recent Optiboot versions have an explicit hack-around for this), which is well known and easily worked around in other versions.
* THE FIX to use ArduinoISP with UNO (or anything else): Install the previous Arduino (0022) and use that to compile/upload ArduinoISP. It's probably a good idea to keep both around for a while, as it appears 1.0 makes a laundry list of other changes that appear likely to break certain sketches. You could also hack around in the core to re-increase the buffer size, but I don't recommend this generally.


I've also added these findings to the top of the thread, since as of this morning it appears to be the top Google hit for this error message.
Users from the future, hope this is helpful :-)
« Last Edit: December 12, 2011, 10:32:43 am by Drmn4ea » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Drmn4ea, thank you so much for this info!!!
I spent the last 6 hours trying to use Arduino as an AVR ISP and only using the 0022 as you said it worked!!
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 176
Posts: 12285
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


I have an update for the ArduinoISP sketch that works correctly with Arduino 1.0.  If you'd like a copy, send me a Personal Message with your email address.
Logged

Offline Offline
Jr. Member
**
Karma: 0
Posts: 58
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thank you Coding Badly, Drmn4ea and DenverCoder9.

Programmed atmega8a-pu with coding badlys working tinyisp.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 3
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Programmed atmega8a-pu with coding badlys working tinyisp.

How did you manage to get the programming done?
Im triying for days to burn a bootloader on an Atmega8, with Arduino Uno as ISP.
Doesn't work with optiloader and the description in this topic as well (always get "avrdude: Expected signature for ATMEGA328P is 1E 95 0F
         Double check chip, or use -F to override this check." - using 100R - resitor)
Logged

Seattle, WA
Offline Offline
God Member
*****
Karma: 7
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I have an update for the ArduinoISP sketch that works correctly with Arduino 1.0.  If you'd like a copy, send me a Personal Message with your email address.

CB, can you just post it publicly?  Did you rewrite it, or just make a few changes to mega-isp?  IF the latter, it seems like you could post the patches to mega-isp for inclusion back into the tree.
Logged


Offline Offline
Jr. Member
**
Karma: 0
Posts: 58
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Programmed atmega8a-pu with coding badlys working tinyisp.

How did you manage to get the programming done?
Im triying for days to burn a bootloader on an Atmega8, with Arduino Uno as ISP.
Doesn't work with optiloader and the description in this topic as well (always get "avrdude: Expected signature for ATMEGA328P is 1E 95 0F
         Double check chip, or use -F to override this check." - using 100R - resitor)

Hmm.. You shouldn't be trying to program it as a 328p, it's a drop in replacement for atmega8 (or m8 if you want)

Code:
Atmega8a
# 18 (MISO)
# 17 (MOSI)
# 19 (SCK)
# 1   (RESET)

avrdude -p m8 -P /dev/tty.usbserial-AH00PD5Z -c arduino  -b 19200 -n -B 8
# no bootloader, internal 8mhz:
avrdude -p m8 -P /dev/tty.usbserial-AH00PD5Z -c arduino  -b 19200 -B 8 -U lfuse:w:0xe4:m -U hfuse:w:0xd9:m

# with bootloader, internal 8mhz
# avrdude -p m8 -P /dev/tty.usbserial-AH00PD5Z -c arduino -b 19200 -B 16 -U lfuse:w:0xe4:m -U hfuse:w:0xd8:m
avrdude -p m8 -P /dev/tty.usbserial-AH00PD5Z -c arduino -b 19200 -B 8 -U flash:w:optiboot_atmega8.hex


I gave up on programming it via the arduino ide and haven't tested it afterwards, but if you are using that you should use "arduino ng or older w/atmega8" and arduino as isp. You might also need coding badlys tinyisp
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 176
Posts: 12285
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

CB, can you just post it publicly?

I can and, assuming a bus does not run over me, I will.  (If a bus does run over me, enough folks have a copy that one of them can publish it.)

Quote
Did you rewrite it

Originally, no.  My goal was to make as few changes as possible while adding a few new features.

Quote
IF the latter, it seems like you could post the patches to mega-isp for inclusion back into the tree.

That was the ultimate goal.  I really do not want to own it.  Unfortunately, there is little to no interest in merging the changes.

I am now bound to my version.  With that change, before publishing, I want to:  1. Document at least some of the added features.  2. Possibly experiment with "overlapped" I/O operations.  3. Add support for a Tiny Debug Serial replacement that's in the works.
Logged

Seattle, WA
Offline Offline
God Member
*****
Karma: 7
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Before publishing, I want to:  1. Document at least some of the added features.  2. Possibly experiment with "overlapped" I/O operations.  3. Add support for a Tiny Debug Serial replacement that's in the works.

That all sounds really good. Can I implore you to take the approach the Arduino team is NOT doing with Due?  That is, put the source up and be open about it even before it's "done" and "ready" to be "published".  That way folks who care can follow along?

Also I'll put in a plug for github, if you haven't decided yet where to put it.  Great site for code collaboration.
Logged


Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 176
Posts: 12285
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Can I implore you to take the approach the Arduino team is NOT doing with Due?  That is, put the source up and be open about it even before it's "done" and "ready" to be "published".  That way folks who care can follow along?

That tends to be a double-edge sword.  On the one hand, there is early feedback and happy users.  On the other hand, there tends to be quite a few, "I downloaded your thingator and it's broken!  Why didn't you test it!  You wasted 1.4 minutes of my life!"

Quote
Also I'll put in a plug for github, if you haven't decided yet where to put it.  Great site for code collaboration.

The problem I have with GitHub is the lack of site statistics.  Google Analytics are trivial to add to a Google Code site.  I can tell the pin change library is not very popular but there is a great deal of interest in the TWI library.  I know to neglect the former and work on the latter.  As far as I can tell, I have to pony-up $6 per month to get site statistics for a GitHub repository.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Many thanks Coding Badly, your sketch worked perfectly.  smiley
Logged

Pages: [1]   Go Up
Jump to: