Go Down

Topic: Larger sketch == hosed chip? (Read 345 times) previous topic - next topic


I'm using a Diecimila on Windows XP, using Arduino software 0011.

TLDR version:  When I upload a sketch over about 4K, the chip seems to stop responding and I have to use avrdude directly to re-burn the bootloader or upload a different hex.

Long version:
After playing with the example sketches I started fiddling on my own and have run into a problem: when I upload a program over roughly 4K, everything goes south.

What I mean by that is that the sketch uploads, but then it's as if the chip stops responding, and from that point on nothing works - I can't even upload new sketches (I get the ubiquitous 'not in sync' error).

It first happened a few days ago - I uploaded and nothing happened.  I figured I'd make a programming error, made some changes to the sketch and tried to re-upload - 'not in sync' error.  Some reading on this forum gave me lots of things to try in response to that error, but none seemed to work.

Luckily I had another ATmega168, so I cobbled together a parallel programmer and tried burning the bootloader to it via the Arduino IDE.  I got a verification error, but lo and behold the chip functioned and I was able to upload the Blink example, and it worked.

Back to the first chip: I figured it must be hosed somehow, so I bumbled with avrdude until I figured out how to read the chips' memory and fuses.  I compared the broken and working chip, and the only difference was the extended fuse (0x7 on the broken one).  I changed it to match, but still no luck.

After more bumbling I learned that even though the Arduino IDE gave 'not in sync' errors, I could upload hex files directly to the broken chip using avrdude.  The next step was of course to burn the bootloader via avrdude directly, which worked!  Now the 'broken' chip seemed to be working again!  I hopped back into the Arduino IDE and uploaded Blink, and it worked like a charm.

Armed with a way to 'un-break' the chip I set about experimenting and the conclusion is that once the sketch gets to be a certain size, the chip stops responding.  That 'certain size' doesn't seem to be constant though, so I'm fairly sure the root cause is something else.  The time I actually fiddled long enough to nail it down, it was 4828 bytes.  4826 worked as expected, 4828 equaled a seemingly hosed chip - LED on pin 13 wouldn't light and the IDE could no longer upload to it.

As a test I took the Blink example and added a big integer array (referenced to keep it from being optimized away) and got the same behavior - after roughly 4K the chip goes south.  Oh, and I tried using both ATmega168s, and both had the problem.

So, any ideas on what could be going wrong, or anything I could do to troubleshoot the problem?  I'm still really new to all this, so any help is much appreciated.


The culprit here turned out to be my ignorance.  I was trying to use way more RAM than the ATmega168 provides.

Specifically I was trying to use some relatively large arrays, which I've now learned will get pulled into RAM by default.  The RAM overrun was then causing the chip to basically become unresponsive.

By using the PROGMEM directive to keep some data in program memory only and out of RAM, things are running as they should again.

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131