Did i just brick my atmega?

So being the stupid newb that I am, I sort of created a minor buffer overflow in my code using strcat. I was doing something similiar to;

int n;
int myBuff[8];
for (int y = 1; y < 2; y++) {
  for(int x = 1; x < 17; x++) {
    n = sprintf(myBuff, "?x%02d?y%02d", x, y);
    SerialDebugger(NOTIFICATION, "loop", strcat("New location: ", myBuff));
  }
}

Which, in retrospect.. is a pretty stupid thing to do. For some reason I was thinking... Well... I dunno WHAT I was thinking. :-[

Anyway, I realized my problem pretty quickly. And so I set about correcting it... I got distracted, put kids to bed, had a beer.. meanwhile, my faithful little Diecmila was executing that bogus code..

About 2 hours go by, and I came back to upload the fixed code, and..

poof!

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

Reset button does nothing.. power cycle.. nothing... :cry:

the RX light does light up if I send chars to the unit via the serial monitor, but..

So.. did I kill it? Did my careless instructions to my faithful little device cause it to commit suicide? Is it dead? Am I going to have to push the bootloader back into the darn thing? will that even work?

It will almost certainly work if the bootloader were reflashed or if you don't have the kit, buying a new 168 or 328 with the bootloader ready installed. They can be had pretty cheap off ebay or from lots of online emporiums.

While I certainly could be wrong, it's my understanding that it is not possible to corrupt any part of the code (including the bootloader) using simple memory writes.

Try using a different USB cable. A bad cable is a suprisingly common problem.

swapped the uSB cable to no avail, and it would appear that I don't own a computer (there are 4 in this house!) that has a parallel port. Nor do I have a USB-ISP programmer.

And I spent all that time wiring up a handful of varying resistors (I didn't have any 470.. I got to 479 though, with a pair of 220's and a 39!) soldering 'em onto little header pins.. figured I'd just stick those in the port.

sigh

Since it's October, and I was feeling halloween-y, I thought I'd use the computer in the dark. I noticed that if I power-cycle the little guy, I can breifly see the L led blink a few times.. I tried to get the timing down to upload a sketch when that was going on, but no luck.

anyone in the chitown area care to re-flash my chip? I'm impatient and don't want to wait for a replacement. :slight_smile:

Most likely a not-auto-reset and upload to blink will help you. Just as an idea that sounds as if i was thinking of you as being stupid, but it happened to me too often myself: Have you checked you compile/upload to the right chip? Checked if you have selected the 168 or 328?

Yeah, I checked the board settings. I even switched it from the 168 to the 368, tried to upload, and switched it back to the 168 and tried again.

No luck.

I found an older motherboard in my pile-o-junk with a parallel port on it. I'll see if I can't find an IDE drive somewhere and get the darn thing booted up and re-flash the bootloader code. With the way things are going though, I might as well go ahead and order another chip or three.

On a totally side topic - Is there any difference (aside from the 168 v.s. 368 chip) with the Diecimila over the Duemilanove? The hardware page isn't real clear (or I'm just not able to interpret what it's trying to tell me). Maybe I'll just pickup another development board too.

Is there a parallel-port programmer software for Linux I wonder? I'd rather nto have to install XP, and just use a LiveCD or something for speed..

My guess is you bricked it. (Sorry) I've blown the bootloader severial times over the last few years doing things very similar to what you did.

Getting some spare 368 chips with the bootlaoder on them is always a good idea.

I had good success using the parallel programmer here . . .

However it doesn't work for everyone - it's kind of a black art. (One tip is to keep the cable short.) Many will suggest buying a real programmer. Personally, there are other goodies I'd rather spend the $25 on. Try the parallel cable. It's about free and it gives you something to do while the 386 chips come in!

[edit] Just saw the Linux part. Was only speaking from experiance with XP, although I believe it's the same - the parallel cable is supported through the IDE via Tools / Burn Bootloader. Good luck. [/edit]

Hi BroHogan,

you wrote

I've blown the bootloader severial times over the last few years doing things very similar to what you did.

I can't imagine how this can happen using the normal Arduino IDE und just downloading a buggy sketch. You cannot write to the bootloader area when the lock bits are set correctly. Even when the lock bits are not set, you explicitly have to write to the bootloader flash area.

@Jeff M:
Are there any wires connected to the pins, especially digital pins 0 and 1, reset and +3,3V / 5V power? => disconnect all wires and all stacked boards
Is the correct device selected?
Is the correct serial port selected?
Do you use the Arduino IDE for the download?
Does your L led blink when your start the download?
Have you updated the firmware?
Is it possible that you overloaded any of the IO pins, especially pin 0 and 1?
Did you connect any LEDs without current limiting resistors?
Have you measured the 3,3 and 5V voltages on the board?

MikeT

@Mike -

Yeah I thought perhpas that it was my connections somewhere, but I did disconnect all of the wires. I wasn't using pins 0 or 1, though I was using pings 3 through 7 for a LCD, shift register, etc.

I disconnected everything, and attempted an upload of the sketch again. No luck.

When I power up the unit, I can see the RX/TX LEDs all light up for a few ms - even the L LED will light but it is very dim and turns off almost immediately.

Attempting to upload a sketch I can see the RX led blink a few times, the L LED will blink 3-4 times (again dimly) rapidly, and then -

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp-0x51

I get the same if I use the command line directly.

I have not tried to reburn the bootloader yet, as I'm still working on getting a darn machine with a parallel port. I'm performing a Windows XP install right now on an old AMD K6 box I found in a closet (it's so SLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOW). I can't believe LPT ports are going the way of the dodo.. Someone needs to come up with a serial-port ISP device...

I haven't measured voltage on the 3.3 and 5v pins. I don't have a meter.. :-[

My "ghetto" DIMM however works (LED, 330ohm resistor wired in series...) on both the 3.3v and 5v pins, with the 5v pin producing a brighter light than the 3.3. Judging by the brightness, I'd say I'm getting anywhere from 3.29 - 3.34v on the 3.3v pin, and 4.99 - 5.02v on the 5v pin. :wink:

I have not updated the firmware in about a year or so.

OK - so finally I managed to burn a bootloader to the thing... Again in true ghetto style, I "made" a parallel programmer by taking apart the 24-pin housing from an old PC power supply for the "pins", some jumper wire soldered onto swiss-machine pin headers one one end, and resistors and/or wire/pin pigtails, and a 10-pin ribbon cable I stole from something.. (don't remember where).

at first, avrdude was complaining about not being able to verify the atmega signature.. dunno why. I jiggled some wires and after a few attempts it seemed to be OK. It's still not really happy, spits out the following:

avrdude: verification error, first mismatch at bye 0x3800
              0x0c != 0xff
avrdude: verification error; content mismatch

I wound up having to run avrdude by hand to get it to work properly.. dunno why. But my little flashing LED is back, and a quick example sketch upload worked like a charm!

I did order a "real" programmer (one of those mini things from SparkFun), and a handful of replacement 368's.. just in case i do this again.. (I probably will...)

thanks for everyone's help!