I have had my nerdkit for a while and went through the tutorials with no problem. Recently I started a simple project using PC5 as an input pin, writing to the LCD or serial whenever the status of the pin changes. It was during this that it started to seem that the MCU was not reacting properly to the input.

Since then things have gotten a bit worse, and I cannot load programs onto the MCU, including even the "initialload" program. I noticed a node about disabling the erase cycle, and it seems that I can get the program to load by adding the "-D" flag in the Makefile to the AVRDUDEFLAGS line. Here's the output I get when that flag is NOT set:

ruquay@ruquay-desktop:~/projects/nerdkit/initialload$ make
avrdude -c avr109 -p m168 -b 115200 -P /dev/ttyUSB0 -U flash:w:initialload.hex:a

Connecting to programmer: .
Found programmer: Id = "FDL v02"; type = S
    Software Version = 0.2; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x35

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "initialload.hex"
avrdude: input file initialload.hex auto detected as Intel Hex
avrdude: writing flash (7806 bytes):

Writing |                                                    | 0% 0.00savrdude: butterfly_recv(): programmer is not responding
make: *** [initialload-upload] Error 1

When I do add the "-D" flag, program loading usually works, but not always. Sometimes I get a verification error:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x01ee
         0xe2 != 0xe0
avrdude: verification error; content mismatch

In any case, the MCU seems to still kinda-sorta working when I load, for example, initialload onto it, but just now I noticed after toggling the power to the unit, the output to the LCD started slowly messing up, in that the first character was completely filled, then with subsequent power cycles further characters would "fill up".

There's a picture of my board and the "filled up" characters on the LCD:

I guess maybe I need to replace the MCU, but I thought I'd ask around here first. BTW, I just wanted to thank you guys for putting this kit together, it has been a lot of fun to work with!

Have you tried a fresh battery? Also, I've noticed that sometimes re-seating some of the components can help. I had one breadboard that made intermittent connections with the crystal and as a result I'd get erroneous lockups, and had issues transferring programs.

The micro-controllers are pretty resilient and while they may go bad from time to time, more often than not, my experience has shown other things at fault.

Rick

Hi Rick, thanks for your response.

I went ahead and just re-seated everything onto the original board, and at first it seemed to solve the problem. After the first program upload, however, again the same error came back: after erasing and trying to re-upload without the -D flag, it hangs with an error on butterfly_recv() as above. However, I'm not getting the erroneous characters on the LCD as before.

Also, even with the -D flag the verification is hit and miss. Usually after 3-4 tries it will work.

I meant to mention before that the problem happens on both battery power and also with USB. Should I try replacing some other component first? I suppose I'm a bit at a loss as to how to go about debugging the problem.

Thanks so much for your reply!

Sounds like a lose wire!

Pull all of the wires and start over, you'll be amazed how fast you get at wiring up the Nerdkit after three or four times.

Ralph

I have now rewired the NerdKit a few times, and I'm still getting the same results. At one point one of the wires end (the programming wire) broke off, but after replacing it I'm getting more of the same.

I've determined that I'm getting this kind of verification error:

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

When uploading a new program while specifying the "-D" avrdude flag to disable the erase cycle, which makes sense. If I do specify the erase cycle, the uploading of program fails, but the erasure seems to succeed. If I then add the "-D" flag, the uploading will succeed. When I want to upload the changed program or something new, I have to repeat the process.

I now have the NerdKit on USB power, and I noticed something else which to me seems peculiar, but may be normal.

In my current setup, I want to detect the push of the button on PC5. Due to the trouble I had, I wired the LED that remains on when the button is not pushed, so I could see that the current was running as I expected (the detection delay was driving me nuts!).

It now seems that a current is running even when I have the power switch off, because the LED remains dimly lit. Trial and error revealed that unplugging either the yellow serial wire or the black ground from the USB will cause the LED to go out completely. Also, disconnecting the wire from VCC pin 7 to the source will cause "lights out". From this I can't help but think - perhaps quite incorrectly - that there is a current coming in on the yellow USB wire, through the MCU, and back out on pin 7... which just seems wrong to me.

The yellow wire leakage is a known problem. You will probably find many references to this with a search of the forum. I know one of the more knowlegable members here, Noter, posted a transistor based fix for this to isolate the yellow wire from the micro. I don't know if the yellow wire issue would damage the micro or not but I doubt it would. After all,the micro expects power at times into that pin since it is the serial receive pin. If you are concerned, you could try a different USB-Serial adapter or if your pc has a true serial port, use that through a level converter such as a max-232 IC or similar circuit.

Lastly, if you are truly suspecting your micro of going bad, buy another. Most of us crazies around here have many and it would be a sure fire way to find out if your micro is the source of your headaches.

Rick

Thanks Rick for all the advice and information. I think I will buy another micro, if for no other reason than to be sure to have a replacement on hand as well. Only problem is then having to put the bootloader on the new one, since I'd like to order it locally (Germany) in the interest of shipping speed. I saw that you posted a tutorial on getting the bootloader running, so hopefully I'll be able to get through that.