Hello, I just wanted some help with the step 10c of the nerdkits guide, I just got the kit today and started building it everything went fine, and I even got the "Congratulations" screen right off the bat. Now I am trying the nest step which is loading a new program ( the initialload ). when I turn on the switch so that I can program the chip I get in the lcd screen black marks across 1st and 3rd row, which I already looked up on the forums and its apparently normal when the switch is on. USB cable is conected and my macbook seems to recognize it (since I already downloaded the driver), I opened "makefile" in "text edit" and changed the "AVRDUDEFLAGS" to the port as instructed. then from "terminal" being in the "instalload" folder typed "make" and got this:

DAVID-ALVAREZs-MacBook:initialload davidsantiagoalvarez$ make
make -C ../libnerdkits
make[1]: Entering directory `/Users/davidsantiagoalvarez/Documents/Nerdkits/Code/libnerdkits'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/Users/davidsantiagoalvarez/Documents/Nerdkits/Code/libnerdkits'
avr-gcc -g -Os -Wall -mmcu=atmega168  -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm -o initialload.o initialload.c 
/var/folders/yw/ywGH9oVnGNuRDIlaNKVWm++++TI/-Tmp-//cclO7kVC.o: In function `main':
/Users/davidsantiagoalvarez/documents/nerdkits/code/initialload/initialload.c:29: undefined reference to `lcd_init'
/Users/davidsantiagoalvarez/documents/nerdkits/code/initialload/initialload.c:30: undefined reference to `lcd_home'
/Users/davidsantiagoalvarez/documents/nerdkits/code/initialload/initialload.c:35: undefined reference to `lcd_line_one'
/Users/davidsantiagoalvarez/documents/nerdkits/code/initialload/initialload.c:36: undefined reference to `lcd_write_string'
/Users/davidsantiagoalvarez/documents/nerdkits/code/initialload/initialload.c:37: undefined reference to `lcd_line_two'
/Users/davidsantiagoalvarez/documents/nerdkits/code/initialload/initialload.c:38: undefined reference to `lcd_write_string'
/Users/davidsantiagoalvarez/documents/nerdkits/code/initialload/initialload.c:39: undefined reference to `lcd_line_three'
/Users/davidsantiagoalvarez/documents/nerdkits/code/initialload/initialload.c:40: undefined reference to `lcd_write_string'
/Users/davidsantiagoalvarez/documents/nerdkits/code/initialload/initialload.c:41: undefined reference to `lcd_line_four'
/Users/davidsantiagoalvarez/documents/nerdkits/code/initialload/initialload.c:42: undefined reference to `lcd_write_string'
make: *** [initialload.hex] Error 1

Can someone walk me thorough this problem.

Note that when I unplug the USB, turn "programing switch" off and re-boot the circuit in the breadboard, I get the initial congratulations message saying that my hardware is ok.

It sounds like that your include command is not right.

Do you have the following line in your code?

#include "../libnerdkits/lcd.h"

I'm not sure what is causing your problem. There seems to be an issue with avr-gcc creating the object file from the initialload.c source. I've seen similar errors when includes weren't in the program file but the original initiallod file should compile fine if the computer and toolchain are configured correctly.

It appears you maintianed the original code download folder structure which is good. However, I don't know if there is a special place the files have to be for a Mac to compile them (I'm a Windows guy), or if there is something else going on. We have a few Mac users here, one I know is quite regular (Ralph), I'm sure one of them will pop in to help out.

Rick

Hi Nerd_notyet, I am (once again) working on that exact same problem at the moment.

Next to the "not a butterfly" "undefined reference to `lcd_init'" must be the second most asked question.

In fact you can just Google "lcd_init" and spend a year reading the responses.

I say once again because I have had this problem in the past, but I cannot remember the solution.

This is not a Mac thing. I think Humberto usually jumps in and gives the answer.

Would't it be nice to have a FAQ?

Ralph

Undefined reference is a linker error message. It means the linker can't find the missing functions in any of the object files supplied. Either you are not telling the linker where LCD.o is or LCD.o is not there. I don't see a LCD.o on your avr-gcc command line. Usually it is passed via the LINKOBJECTS variable in the make file:

LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

is used on the avr-gcc command line:

avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o initialload.o initialload.c ${LINKOBJECTS}

and then LCD.o must exist in ../libnerdkits/

Hello again, I just fixed this problem and dont know exactly how, all I did was download the sample code again from the nerdkits website. I do not know why but there were 2 files missing in the "initialload" folder that I initially downloaded (initialload.hex and initialload.o) I dont know how they were not in the initiall download. Thanks everyone for the quick response.

hello again! I just went on to set up my temperature sensor and did everything (installed temp sensor to breadboard, changed /dev/ file), but when I go to execute the program this is what I get: (btw can you guys break down the steps to write the code a little more, I am not sure if indentation is critical while you write the code, and if it is can I get some pointers?)

DAVID-ALVAREZs-MacBook:tempsensor davidsantiagoalvarez$ make
avrdude -c avr109 -p m168 -b 115200 -P /dev/cu.PL2303-00004006   LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o -U flash:w:tempsensor.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 done.  Thank you.

DAVID-ALVAREZs-MacBook:tempsensor davidsantiagoalvarez$

For what it looks, it seems like the computer is comunicating with the chip ok, but after this when I unplug USB and 9V battery and reboot, all it happens is that I get the initial message from my previous program. Am I missing a step? Note: I am able to go back and change message in "instalload" and upload it to chip without any problem.

Why do you have "-U flash:w:tempsensor.hex:a" in LINKOBJECTS and LINKOBJECTS on the avrdude command line?

Here is what your makefile should look like:

GCCFLAGS=-g -Os -Wall -mmcu=atmega168 
LINKFLAGS=-Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm
AVRDUDEFLAGS=-c avr109 -p m168 -b 115200 -P COM2
LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

all:    tempsensor-upload

tempsensor.hex: tempsensor.c
    make -C ../libnerdkits
    avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o tempsensor.o tempsensor.c ${LINKOBJECTS}
    avr-objcopy -j .text -O ihex tempsensor.o tempsensor.hex

tempsensor.ass: tempsensor.hex
    avr-objdump -S -d tempsensor.o > tempsensor.ass

tempsensor-upload:  tempsensor.hex
    avrdude ${AVRDUDEFLAGS} -U flash:w:tempsensor.hex:a

I am simply, looking up the "tempsensor" file and executing it. The file is the one I downloaded from theNerdkits site and I have not touched it.

Noter, that is the exact same code that I have. I just erased all files containing the code that I dowloaded from the site, and downloaded it again, and guess what, the initialload file is missing the .hex and .o files. I tried executing it again and it gave me the initial problem that I was having. also in the "tempsensor" file both the .hex and .o are missing. is this whats causing all my problems? and why is this happening?

The hex and the .o files are created when the c source is compiled and linked so they should be created when you run the makefile. So, it's ok if they are missing from the download.

If you have the correct makefile then I wonder why the line in your output looks like

avrdude -c avr109 -p m168 -b 115200 -P /dev/cu.PL2303-00004006   LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o -U flash:w:tempsensor.hex:a

because that looks like things are mixed up.

Maybe a mac thing? I don't know, I've never had a mac.

Here's what I get from running the makefile. You can see the "-U flash:w:tempsensor.hex:a" is on the avrdude command line but without the LINKOBJECTS stuff. The "-U flash:w:tempsensor.hex:a" is what tells avrdude to upload the program to the chip.

> "make.exe" all
make -C ../libnerdkits
make[1]: Entering directory `C:/Documents and Settings/Administrator/My Documents/NerdKits/Sample Source Code/Code/libnerdkits'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `C:/Documents and Settings/Administrator/My Documents/NerdKits/Sample Source Code/Code/libnerdkits'
avr-gcc -g -Os -Wall -mmcu=atmega328p -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm -o tempsensor.o tempsensor.c ../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o
avr-objcopy -j .text -O ihex tempsensor.o tempsensor.hex
avrdude -c avr109 -p m328p -b 115200 -P COM2 -U flash:w:tempsensor.hex:a

Connecting to programmer: .
Found programmer: Id = "AVR ISP"; type = S
    Software Version = 3.0; Hardware Version = 0.1
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x03

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e950f
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 "tempsensor.hex"
avrdude: input file tempsensor.hex auto detected as Intel Hex
avrdude: writing flash (10306 bytes):

Writing | ################################################## | 100% 2.78s

avrdude: 10306 bytes of flash written
avrdude: verifying flash memory against tempsensor.hex:
avrdude: load data flash data from input file tempsensor.hex:
avrdude: input file tempsensor.hex auto detected as Intel Hex
avrdude: input file tempsensor.hex contains 10306 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.47s

avrdude: verifying ...
avrdude: 10306 bytes of flash verified

avrdude done.  Thank you.

> Process Exit Code: 0
> Time Taken: 00:07

ok for some reason, I just executed "tempsensor" and it ran like you showed in the last post, then in my LCD I got "ADCR 178 of 1024" first row, and just the letter "F" in the second row of my LCD. The 178 number changes apparently with temperature (but is this how is supposed to be displayed in the screen?). Also, I just tried to program the previous "initialload" again just to get a hand on doing it, and it gave me this:

DAVID-ALVAREZs-MacBook:initialload davidsantiagoalvarez$ make
make -C ../libnerdkits
make[1]: Nothing to be done for `all'.
avr-gcc -g -Os -Wall -mmcu=atmega168  -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm -o initialload.o initialload.c 
/var/folders/yw/ywGH9oVnGNuRDIlaNKVWm++++TI/-Tmp-//ccUa0QaO.o: In function `main':
/Users/davidsantiagoalvarez/desktop/code/initialload/initialload.c:29: undefined reference to `lcd_init'
/Users/davidsantiagoalvarez/desktop/code/initialload/initialload.c:30: undefined reference to `lcd_home'
/Users/davidsantiagoalvarez/desktop/code/initialload/initialload.c:35: undefined reference to `lcd_line_one'
/Users/davidsantiagoalvarez/desktop/code/initialload/initialload.c:36: undefined reference to `lcd_write_string'
/Users/davidsantiagoalvarez/desktop/code/initialload/initialload.c:37: undefined reference to `lcd_line_two'
/Users/davidsantiagoalvarez/desktop/code/initialload/initialload.c:38: undefined reference to `lcd_write_string'
/Users/davidsantiagoalvarez/desktop/code/initialload/initialload.c:39: undefined reference to `lcd_line_three'
/Users/davidsantiagoalvarez/desktop/code/initialload/initialload.c:40: undefined reference to `lcd_write_string'
/Users/davidsantiagoalvarez/desktop/code/initialload/initialload.c:41: undefined reference to `lcd_line_four'
/Users/davidsantiagoalvarez/desktop/code/initialload/initialload.c:42: undefined reference to `lcd_write_string'
make: *** [initialload.hex] Error 1

What can be causing all this? and how do I fix it? Thank you.

deja vu, same as the first time. Re-read the answer I gave above and fix the makefile. The only difference between make files for these projects would be the program name.

Hi Nerd_notyet,

Lets take a step back here and make sure everything looks good in your Makefile before digging deeper to find the issue. Please post your Makefile for the tempsensor program you are trying to upload (and go ahead and post your initialload Makefile too while you are at it).

Like Noter spotted earlier, it seems that your LINKEDOBJECTS line is either showing up in weird places, or not showing up at all. That is strange, and leads me to believe you either have a currupted Makefile (unlikely since you downloaded twice) or you are altering it when you edit the Makefile. Which text editor are you using to edit your Makefile?

Humberto

This is the makefile for initialload:

GCCFLAGS=-g -Os -Wall -mmcu=atmega168 
LINKFLAGS=-Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm
AVRDUDEFLAGS=-c avr109 -p m168 -b 115200 -P /dev/cu.PL2303-00004006
LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

all:    initialload-upload

initialload.hex:    initialload.c
    make -C ../libnerdkits
    avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o initialload.o initialload.c ${LINKOBJECTS}
    avr-objcopy -j .text -O ihex initialload.o initialload.hex

initialload.ass:    initialload.hex
    avr-objdump -S -d initialload.o > initialload.ass

initialload-upload: initialload.hex
    avrdude ${AVRDUDEFLAGS} -U flash:w:initialload.hex:a

and this one for tempsensor:

GCCFLAGS=-g -Os -Wall -mmcu=atmega168 
LINKFLAGS=-Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm
AVRDUDEFLAGS=-c avr109 -p m168 -b 115200 -P /dev/cu.PL2303-00004006
LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

all:    tempsensor-upload

tempsensor.hex: tempsensor.c
    make -C ../libnerdkits
    avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o tempsensor.o tempsensor.c ${LINKOBJECTS}
    avr-objcopy -j .text -O ihex tempsensor.o tempsensor.hex

tempsensor.ass: tempsensor.hex
    avr-objdump -S -d tempsensor.o > tempsensor.ass

tempsensor-upload:  tempsensor.hex
    avrdude ${AVRDUDEFLAGS} -U flash:w:tempsensor.hex:a

the only thing that I am doing after downloading this code from the website is going into it to change /dev/ and nothing more. I am using textedit in my macbook to do the editing. Thank you

Nerd_notyet, what does your libnerdkits folder look like? What files are there?

Reboot!!

You probable should use Xcode instead of "text edit". Xcode is a real IDE so it gives you colored syntax which is nice. It is kinda a pain to get used to but once you do it is nice.

Ralph

I suspect Ralph may be onto something here. TextEdit might be adding rich text format things that are confusing make. You can try Xcode as an editor like Ralph suggested. I'm not a mac person but I have heard plenty of people love TextMate for coding, they have a 30 day free trial.

Humberto

TextEdit will work but it is like NotePad in Windows and defaults to doing stupid things to the end of line.

At least with TextEdit you can override the default behavior.

I compared your Initialload Make file to mine and did not see anything different, so possible it is something TextEdit is doing.

Ralph

When I try to download the Sample Source Code I get a message that says that it cannot be opened because the associated helper application does not exist. It says, "change the associated the association in your preference" How do I do that?

I have an Imac and i use a free program that you can get from the app store called Tex Wrangler, also i am using Xcode and it works just like Ralph says. hope this can help.

Tinkerer-

"When I try to download the Sample Source Code I get a message that says that it cannot be opened because the associated helper application does not exist. It says, "change the associated the association in your preference" How do I do that?"

That sounds like your browser doesn't know what to run to open the file. Instead, right-click and choose save-as or save link as, then save the file to wherever you want (desktop or wherever) and then go double-click on it or open it with the proper application.

BM

Yes. I finally got it to download. Thanks

I am still having problems with initialload. After messing around with the files and with Makefile, I thought that I had it. The DOS routine looked good. It erased the old program, wrote the new flash data, read the flash data, verified it and wrote " avrdude done. Thank you." The problem is that the LCD only displays two lines of black squares. No letters or numbers. The position of the switch doesn't matter. It worked before so there probably is no problem with the wiring or the hardware. I pulled out all the LCD wires and rewired it hoping that there was a loose connection but it still does the same thing. Is there some way that I can diagnose the LCD ?

Hi Tinkerer,

If you got the avrdude done message then the new program definitely made it onto the chip. Did you make sure to reset power to the chip after you flipped the switch out of programming mode? You might want to remove the switch entirely and then reset power to the switch to make absolutely sure you are not booting into programming mode.

Humberto

I tried removing the switch and resetting the power but I still get two lines of squares on the LCD. I tried using a really big 9 volt battery from a toy machine gun to eliminate any possibility of a battery related problem. The potential across the rails is exactly 5 volts. I switched all of the LCD leads to different holes in the breadboard. Page 30 of the Guide tells what the LCD pins do. Would it do any good to check the voltage on some of these pins?

Tinkerer,

Make sure that you turn the programming switch on "run mode", which is when you have the switch not connecting ground on pin 14, and reset the power after you loaded the program on the chip to get the program to display on the LCD and to run on the nerdkit.

Hopes this helps.

-Dan

Dan, The switch is removed so I know that I am in the "run mode". Are you suggesting that I go back to the "program mode" with the switch connecting pin 14 to ground and then reinstall the initialload program and try again to go into the "run mode" ?

Tinkerer

I am still stuck.Let me summarize. 1. The original setup went well and I got the Congratulations Message 2. I got the avrdude done message which means that the new program made it into the chip. 3. When I flipped the switch out of the programming mode and reset the power I got two lines of black squares on the LCD. 4. I replaced the small 9V battery with a much larger one and verified that the potential across the rails is exactly 5 volts. 5. I removed the switch entirely to make sure I was not rebooting into the programming mode. Still no change. 6. I rewired everything and still got the two lines of squares. 7. I replaced the switch, flipped it up and tried to reprogram the chip. Now I get the following message. " make is not recognized as an internal or external command, operable program or batch file". For some reason it wont compile even though it did before.

Any suggestions?

Tinkerer,

1st question - I don't think I saw you state - Are you running Windows or Mac? 2) Can you take a couple of overhead photo's showing your wiring and post them (instructions for adding photo's are below in yellow where it says Supported Markup) Extra eyes can often see something we overlook. You also stated you rewired after your congratulations message so there is a possibility of something there.

Rick

Thanks for the reply. I am using Windows Vista. Lets see if I can send the pictures.

http://i.imgur.com/Z9YjQ.jpg

http://i.imgur.com/3vKHW.jpg

http://i.imgur.com/YY7cD.jpg

http://i.imgur.com/YcOd7.jpg

I noticed some of your wires either aren't pushed in or are not in all the way. Double check the connections. It looks like they are going to the correct places from what I see other than the one (LCD pin 6) that doesn't look connected.

As for your software issue, uninstall WINAVR then right click the install program and select install as administrator. You should see your make issue go away and hopefully it'll work again.

Rick

Rick. Your advice on how to solve the software problem worked. After reinstalling WINAVR, I was able to reprogram the chip. It went through the whole routine and gave the avrude done message. However when I switched back to the run mode I still get only two lines of blanks on the LCD. Its hard to tell if the chip failed to run the program or if it did run the program but the LCD failed to display the result. LCD pin #6 was reconnected and all the wires are pushed all the way in. The same thing happens when the switch is removed. Any ideas? Al

Try building for and uploading the blink program. That way you can verify the program is loading and running. That will at least narrow it down to the LCD and its connections.

Rick

Rick. I followed your recommendations but did not get the blinking light when I switched to the run mode and rebooted. The blink program uploaded with no problem and I got the avrude done message. I am sure that the LED is installed in the correct place with the correct polarity. The LED itself is OK since it lights up when placed across the rails. We have to conclude that the chip won't run for some reason. Its strange since it ran fine when I first ran the welcome message. I guess the LCD is OK.

What's odd is that if it is uploading the program, it is working. The only way AVRDUDE will upload is if the chip is communicating with it.

There has to be something going awry after the program is loaded.

Do me a favor and try to program the switch with the progamming switch in the wrong (run) position. Just to see what happens.

Hi Tinkerer,

The odds of your chip being able to program itself (which we know it can since you get the avrdude done message) and then not succeeding in running its program is extremely unlikely. Follow Rick_S suggestion, and also post one more picture of your current setup, perhaps there is weird now that we missed earlier.

Humberto

Rick: You are onto something. The chip uploads the program for both positions of the switch so we know that it is always in the programming mode. Looking at page 33 of the Guide we see that this should only happen when pin 14 (row 24) is grounded. With the switch removed there is nothing left to ground pin 14 and yet it stays in the programming mode. It is tempting to say that the board itself grounds row 24 because of some flaw or that the chip has some kind of wiring defect but if either one of these flaws existed, the chip would not have been successful in running the welcome message when the setup was first assembled. It worked in the run mode at that time but it doesn’t now. What do you think?

Humberto: I am attaching two more pictures of the current setup which emphasize the area near pin 14. The switch is removed for clarity. I hope that this helps.

Humberto: I am attaching two more pictures of the current setup which emphasize the area near pin 14. The switch is removed for clarity. I hope that this helps.

http://i.imgur.com/LnI0C.jpg

http://i.imgur.com/65Fia.jpg

Tinkerer, strip everything off the breadboard and start over.

That has been my solution for persistant unexplained problems, you'll be amazed how rapidly you can re-assemble the breadboard after your forth or fifth try .

Sorry Rick I couldn't resist using your icon, hope I didn't make a copyright violation :-)

Ralph

Ralph: Ok I'll strip the board. However, there is something I would like to try first. It would be interesting to wire 5 volts onto pin 14 to see if the chip will run. Is this safe or will I blow the chip?

Does it load the program with the switch removed altogether? Maybe you have a bad switch. I would think that more likely than a bad mcu or breadboard. There is definaltely something odd going on there though.

Ralph: All of those smileys I use are either free off the web or came bundled with forum software. It doesn't bother me if you use them. I made up a text file so I can just copy/paste them in when I want.

Rick

Rick: Yes. I knew it would but I tried it again just to be sure. I asked Ralph if it would be safe put 5 volts on pin 14 to see if the chip would run but he hasn't answered yet. I have not tried this yet because I am afraid of blowing the chip.

I wouldn't do that. Try moving the chip up to a different row so that row is no longer used. Or if you can, try a different breadboard.

Rick: I have been busy. First I completely stripped the board and the LCD and reassembled everything. Same result; the chip reprograms initialload with any position of the switch (or with the switch removed) but will not run the program. I then bought a similar board at Radio Shack and reassembled everything for the third time. Same result. It just has to be the chip. I just ordered a replacement chip from your store and look forward to its delivery.

Not my store, I don't work here or receive any compensation. I'm just another hobbiest like you who tends to hang out here way more than my wife likes.

I do think at this point you are correct and that it has to be the mcu. Makes me wonder if the bootloader code somehow glitched or if somehow that leg got electricaly damaged.

Have you sent an e-mail to support at nerd kits dot com to tell them directly about this. I don't know how long you've had your kit, but they are very good about making sure the product is good for you. Thier support is excellent.

Rick

Rick: Wow; all this time I thought I was communicating with a Nerdkits person. Its nice of you to help neophytes like me. My wife doesn't complain about my hobbies. I think she is glad to be rid of me. Anyway, I figured that I have nothing to lose by putting 5 volts on pin 14 since I have already ordered a new chip. Presto. The chip runs the program. I repositioned the switch so that it grounds pin 14 in one position and puts 5 volts on it in the other position. Now I can switch from the program mode to the run mode at will. When the new chip arrives I think I'll just set it aside thinking, "If it aint broke, dont fix". As far as making a claim with Nerdkits, I'll just leave everything alone. Its not worth the trouble. Besides, the chip worked fine when I first assembled the circuit. I might have done some dumb thing that damaged it.

I had a chip that I damaged one of the outputs by accidentally shorting it out to 12V. It did the same as you are describing except I was using it for an output and the internal pullup no longer worked. So I used an external and it worked fine. So while the chips are pretty durable, we can do things that make them malfunction.

I'm glad you figured out a workaround. And thanks for the compliments. I can't think of many things better than being considered one of the NK crew.

Rick