westfw:
for chips like the 1284 and 2560, avrdude sends 0x01,0x00 as the page length value
Oh! That's annoying.
https://code.google.com/p/optiboot/issues/detail?id=104
You will also notice that the PAGE_READ operation has the same iffy loop structure as PAGE_WRITE.
As an ADDENDUM to previous comments, I have to say I am totally underwhelmed by the lack of robustness of the avrdude upload protocol. Totally..... If the internet used something that poorly conceived, we'd never get an email or webpage across the net.
I am beginning to understand the protocol now, although trying to understand how avrdude executes it would take me weeks, I think, trying to decode 30+ .h files, plus another 30+ .c files. Having separately-compilable source files in C is nice, but most programs end of looking like a big plate of interlinked sphaghetti strands. Sheesh.
I have to give the avrfreaks guys [I think] and Brian Dean immense credit for building avrdude, as it must have taken weeks if not months of time to code. Unfortunately, at the highest-most conceptual level, the protocol was poorly conceived.
The basic problem is it just blasts off large blocks of data, up to 256 bytes, with no checksums or ability to throttle them, and no ability to check if each block is individually received properly. The only checks come after the ENTIRE program has been uploaded, and by then it's far too late to do anything about transmission errors. All in all, not the most robust transmission scheme.
Besides that, what I have found all along is that the weakest link is the sync attempt at the very beginning of the upload, where avrdude sends the [30], [20] commands. This is exactly where most of my upload failures occur, via hardwire, and before the page-write block-transfers even begin.
avrdude: Version 5.11, compiled on Sep 2 2011 at 19:38:36
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\winapps\ArduinoIDE\arduino-1.0.5-windows\hardware/tools/avr/etc/avrdude.conf"
Using Port : \\.\COM4
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv:
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude done. Thank you.
And which should look as follows, with [14], [10] acks coming back from the bootloader.
avrdude: Version 5.11, compiled on Sep 2 2011 at 19:38:36
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\winapps\ArduinoIDE\arduino-1.0.5-windows\hardware/tools/avr/etc/avrdude.conf"
Using Port : \\.\COM4
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
AVR Part : ATMEGA328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
..............
For some reason, when it fails initially, avrdude can't get the attention of the bootloader, after what appears to be a feeble attempt, and gives up straightaway. If I can get that working better, maybe the rest will be doable.
Anybody got an idea? My guess is avrdude isn't waiting long enough for the acks to come back from the bootloader, possibly because of the time it takes the mega chip to boot up after the reset line is released. Just a guess.
To wit, by controlling the reset pin manually, if I release it at precisely the right time, not too soon and not too late, then the upload will take place, otherwise no dice. There is a very small window there for avrdude to catch hold of things to its own liking. Very finicky operation.