Help please.  Verification failing.

Forum 2005-2010 (read only) Hardware Troubleshooting
1

I have a Diecimilia connected to the USB port. It has been working wonderfully for several days and have had no issues that weren't readily resolved by either research or simply figuring things out.

After successfully implementing an 8x8 LED matrix (yes, ample current limitig resistors used on LEDs -- kept it ~10 mA) I decided to tear down the circuit and make a simple POV deal with a handful of LEDs. I turned off the Arduino and disconnected the external power. I probably left the USB plugged in. I wired up the circuit which consisted of 5 red LEDs anodes directly connected to digital pins 2 through 6 and cathodes to ground through 330 Ohm resistors. I wrote some simple test code to drive the LEDs in a POV sort of way, turned on the Arduino, and tried to upload the code.

During the familiar avrdude conversation I see this error that I had not yet encountered:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdude: verification error; content mismatch

I try again and again. I reset the Arduino. I cycle the power to it. I uninstall and reinstall the (windoze) USB driver. I resinstall the 0011 environment. All to no effect.

I also tried avrdude standalone. Exact same results.

The program that was loaded atthe time of this failure still runs correctly, so that tells me the bootloader is doing its thing and the processor is actually working otherwise.

I am beginning to suspect maybe something fried in the MCU maybe but cannot find posts to confirm that.

The avrdude session either from within v0011 or standalone avrdude executes and has what looks to be a legitimate conversation with the bootloader. There is plausible RX/TX LED activity and blinking LED on pin 13.

According to avrdude, all fuses are being read as value 0 (zero).

That's about all I can think of that might be important.

Since it has been working flawlessly on USB or external power in a variety of situations for several days seems to me something is cooked.

Can someone explain what is going on? Is it the ATMega168 or could it be the FTDI chip? I am hoping it is something else from which I can recover. I do not have a stand-alone programmer for the AVR but will come up with one if that will help.

This has put a serious damper on my week or Arduino fun :cry: so I am anxious to get it running again.

Thanks!

2

It does sound like your ATmega is having troubles. There are some fuse settings that prevent the bootloader from writing to the program space, which could conceivably have been toggled under some weird power situation (or so my lack of knowledge of electronics leads me to believe).

Try uploading with nothing connected to the board. It's not sitting on anything conductive, is it?

When you press the reset button, what happens to the L LED? It should blink once (before starting the currently loaded sketch, which of course could blink it more).

Do you have the power jumper on the right pins?

3

Thanks for the response. I have tried that.

The board is...err..."naked", bereft of any of my circuit stuff. I removed everything I had added to ensure it was not anything I was doing circuit-wise. So, it is just plain Arduino.

The power jumper is currently on USB with no external power connector attached. I have been diligent in changing it between EXT and USB when I have applied or removed external power.

The board is mounted on 0.5" non-conductive plastic standoffs using non-conductive plastic fasteners. I have inspected the board for damage to traces, stray flux, or stray solder and found nothing like that. I also did reseat the ATMEga168 to ensure pins were in contact with the socket.

Pressing reset seems to behave as expected. The L LED to flash once then the sketch that was stored before this issue begins to run and it runs correctly.

:-?

Is there some way to recover the fuses or set them to some neutral state? (my lack of knowledge of the AVR showing here).

4

Oh yeah, the IDE seems to be communicating correctly with the board. When I select the serial monitor, the board reacts as expected by resetting and running the (old) sketch BUT still unable to upload new sketches.

Thanks.

5

To reset the fuses, you need a programmer (like a AVRISP mkII or a USBtinyISP or a parallel port programmer). Then you just do "burn bootloader" from the tools menu. Alternatively, you can get a new ATmega168 with Arduino bootloader pre-burned from some of the distributors.

6

Thanks. I will order a spare processor or two to have on hand, and maybe put together or purchase a programmer and see how it goes.

The fact that the processor happily runs the program (boatloader plus my old sketch) leaves me some hope that the device can recover from this issue. Unless, somehow something is wrong with the USB portion of the circuit and avrdude or uisp cannot tell...dunno.

I appreciate the help and will post results as I have them.

Barry

7

It is weird. It does sound like the communication is working though, and it's just that the new program isn't being written.

8

The short version, my old unprogrammable 168 is programmable once again.

Here are the predigested gory details.

Believing that the fuses had somehow been garbled, I ordered one of Adafruit's USBTiny programmer kits (great bang for the buck!) and a spare ATMega168 in case my beliefs proved optimistic.

I decided to first try AVRStudio. This is a very convoluted way to do things and I would suggest it is not the shorest way to get the job done. It involves installing USBTiny500, com0com in addition to AVRStudio. AVRStudio complained (firmware mismatch -- I cancelled out of that) but would read the 168 and otherwise behave as expected. Indeed, the write protect fuse had somehow become set. The other fuses were as expected, the signature was correct and so were all other writable settings. I am not clear on how this could happen, except perhaps by some lucky zap. One would think that fluke discharges would cause other more random things to occur, but everything else is absolutely normal. Such is Murphy and his ilk.

Anyway, AVRStudio went through the motions of programming the old 168 and reported everything was fine. The verifications reported success. I felt very lucky although I was leary of how fast it executed. Sure enough, my suspicions were not to be denied, and I was unable to upload a sketch. Avrdude was complaining about being able to communicate with the Arduino (out of sync errors). I thought my luck had run out.

I plugged the USBTiny back in and used the Arduino environment to burn the bootloader one more time. My thinkning was that if that did not work I would force it into submission using the commond line tools and hand sellected options to ensure everything was right. I did have a quick look at the configuration files to ensurfe all was correct. No problems were reported during the burn, and it took an appropriate length of time. I uploaded the blink sketch just to test and sure enbough it worked no problem.

It is somewhat disturbing that AVRStudio behaved the way it did. I would have been irritated but happy with it complaining and errorong out. But acting as though all was well is unsettling. But, maybe with all the cobbled together solutions it should be no surprise. If I get bored I may try to figure out what is happening there. I now have a spare 168 on hand so I can afford to mess things up if need be. I should order an extra ATTINY2313 just in case th eone in my USBTiny gets scarificed since I intend to get it working such that AVRStudio does not complain about the firmware mismatch.

Had the above not worked I would have tried a high voltage mode burn. Thankfully I did not have to do that because it seems klunky.

So there you go. If you cook your 168, don't give up without trying to burn it the old fashonioned way.

9

Thanks for the the "gory details"!
Is there way to reset the atmega without an prgrrammer? With another arduino for example?