UNO: Troubles uploading large sketches.

Hi everyone.
So today I received my UNO.
I bought it because of the new bootloader (I need more room for my sketch) and I need an extra ATmega328's for my project.
So I opened the nice box, installed the drivers, opened the example 'Blink', uploaded it and result:
Binary sketch size: 1010 bytes (of a 32256 byte maximum) and led on board blinking, as expected! [smiley=thumbsup.gif]
So I tried to upload my project's sketch and....

Binary sketch size: 30700 bytes (of a 32256 byte maximum)
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
avrdude: failed to write flash memory, rc=-4
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
:o :o
Looks like there is a problem with my ATmega328 ?!?!
But is pretty strange that all the examples I tried as well as other sketches of mine (up to 20K) upload without any problem.
I reduced the size of the big sketch to 28K by commenting some parts and...guess what? It compiles and uploads with no problems.

Does anyone already experienced or can think of any possible reason for this behavior?

NB.:The big version of my sketch uploads without problems on my Arduino 2009

Thanks in advance for your help.
A.

Follow-up:
Could it be a bug in the bootloader? I burned the optiboot bootloader on the ATMega328 that I was using on my 2009 and which I could upload without problems: now I'm not able to upload the big sketch on this chip either!

I opened an issue for this: Google Code Archive - Long-term storage for Google Code Project Hosting. and hope Christian will be able to look into it.

No offence meant to the Arduino team or the developer of the optiboot bootloader, but it seems that it wasn't quite ready for prime time to have been included with a new hardware and associated IDE release?

Lefty

I had same issue with latest optiboot v3 in Arduino Duemilanova with atmega 168. Sketch size is 14326b out of 15360b possible.

Thanks Mellis,
I really hope you can help me with this, I'm really at last stage of my project!
In the meantime: is it possible to re-burn the old bootloader using Arduino UNO as ISP on the 328 that I was previously using with the 2009?

Thanks.
A.

I opened a new issue also here:
http://code.google.com/p/optiboot/issues/detail?id=23

I had same issue with latest optiboot v3 in Arduino Duemilanova with atmega 168. Sketch size is 14326b out of 15360b possible.

Stas, any updates from your side?

On the Atmega328, it looks like the size maximum is 28672==0x7000. For the Atmega168 it's then probably 14336==0x3800.

No offence meant to the Arduino team or the developer of the optiboot bootloader, but it seems that it wasn't quite ready for prime time to have been included with a new hardware and associated IDE release?

Well, that's one of the neat things about open source...you can be involved in the identification of bugs and help solve them. With most closed devices in this price range, you'd be lucky to get any bug fixes. Arduino's an organic process, the Arduino team gets as much value out of the community's work as we get out of their work.

However, the same argument works against the Team for keeping all of the Uno details secret until launch. A lot more community testing of the 8u2 solution would have been useful before thousands of them were sold. It remains to be seen whether the 8u2 problems will be simple bugfixes (simple, at least, to anyone with an ISP device).

And that is why I said no offence meant. I am a big fan of open source hardware and software, It's what attracted me to the Arduino project in the first place.

I've just been a little overwhelmed at the vast number of postings of people having problems with the new products. Maybe there was just a corresponding super number of the new products sold in a very short time that accounts for the increase problem postings? There will always be a certain percentage on new comers having problems once they obtain their first Arduino, but I wonder why the percentage seems to have drastically increased, maybe if hasn't as I have no idea of the products shipped volumn before and after the new releases :wink:

Lefty

This appears to happen when the bootloader tries to write the first page that is in the "Non Read While Writing" (NRWW) flash section, which is always as large as the largest possible bootloader for a part, regardless of the size currently selected for the bootloader. When writing the NRWW section, the CPU is supposed to be halted, and the write SHOULD work, so this SHOULD be transparent to the bootloader code. However, this does not appear to be the case. It seems that avrdude never sees the "ok" response from the bootloader, so my current theory is that "cpu halted" means that the uart is also halted. Alternately, the next command from avrdude may overrun the uart during the several milliseconds it takes the flash write to complete (but that doesn't match the logs that show no response, such as:
[62] . [9f] . [f0] . [01] r [72] . [9f] . [bb] ' [27] . [f0] . [0d] . [b1] . [1d] c [63] . [9f] . [aa] ' [27] . [f0] . [0d] . [b1] . [1d] . [aa] . [1f] d [64] . [9f] f [66] ' [27] . [b0] . [0d] . [a1] . [1d] f [66] . [1f] . [82] . [9f] " [22] ' [27] . [b0] . [0d] . [a1] . [1d] b [62] . [1f] s [73] . [9f] . [b0] . [0d] . [a1] . [1d] b [62] . [1f] . [83] . [9f] . [a0] . [0d] a [61] . [1d] " [22] . [1f] t [74] . [9f] 3 [33] ' [27] . [a0] . [0d] a [61] . [1d] # [23] . [1f] . [84] . [9f] ` [60] . [0d] ! [21] . [1d] . [82] / [2f] v [76] / [2f] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
)

I don't have the equipment to debug or even rapidly reload bootloaders, so I'm posting this partially in case someone else is able to jump on the hint and make progress!

Hah! In fact, optiboot got a patch to fix this problem back in May, but it looks like that fix is NOT included in the version of optiboot that is loaded on the the Uno boards, nor is it in the 0021 Arduino distribution...

I did some fiddling, and have successfully put a more recent Optiboot on a 168-based Arduino board, using arduinoISP as the programmer, and downloaded and run a 15832 byte sketch!

Great news!
I'm going to try this and report back, thanks westfw for your precious contribution!

Problem Solved! [smiley=thumbup.gif]
Thanks westfw for your finidng, owe you a beer! [smiley=beer.gif]
I compiled and successfully burned a newer version of the optiboot bootloader (this revision: Google Code Archive - Long-term storage for Google Code Project Hosting.).

Although I had found a workaround by using an ATMEGA328 without bootloader in my project (programmed with Arduino as ISP), the solution of this issue makes me happier: comes convenient and easier in my project to update sketches using a serial connection!

Hopefully this is helpful to the arduino team for their next list of updates!!

Thanks to everyone.

I downloaded the Atmega328 hex file from that link and ISP-ed it. Everything worked OK. So you don't have to build it from source. Just don't get the hex files from the optiboot zip file (at least not for Atmega328); that one isn't up to date.

Hmm, I had the same error on two stickduinos I just built with new atmega328s. I used the hex file linked above and both stickduinos now load and run the blink sketch. The strange thing is that one stickduino would load a new sketch every now and then, while the other would never load a sketch. Either way they both run fine now. Thanks for posting this.

It would be nice if this problem and the solution were easier to find. It took me a while to find this thread through a number of google searches and reading through other threads about bridged solder joints and other random problems. How many more people are going to be stumped with this as they download and load the optiboot bootloader?

@pmason: the "fix" was only posted a couple days ago. I'm not sure where I should put the info, or what keywords I should include that would make it easier to find; in general, posting the same info in multiple groups is discouraged.

This is probably easier to track in the google code repository for Arduino, where it shows up pretty quickly when you do a search for "optiboot."

http://code.google.com/p/arduino/issues/detail?id=380

Or the optiboot page:
http://code.google.com/p/optiboot/issues/detail?id=23

"I tried to put optiboot on my old Ardunio clones and it didn't work" is a pretty open-ended problem to debug. This thread isn't actually about the m168 issue that caused small sketches not to upload, but it has the same fix: get the newest version of optiboot!