I've quintuple checked everything. lost....

pin 14 is grounded pin 1 is +5v

chip IS communicating over serial because my previous program is working. both input and output over serial are working. I send it a number it sends me a response.

ADC +5v on pin 19 and 20 grounded pin 21

pin 2 serial yellow pin 3 serial green, serial black to gnd

i've actually used the multimeter and touched the leads to the pins to confirm at least that the proper voltage is going on to the pin, and it is.

one curious thing is that when I measure the voltage across the rails, I'm getting about 2.4v when my power supply is OFF, and it's leaking through the usb cable, is that proper? If I disconnect the usb, the voltage measures less than .25v which I assume is just the lousy meter giving incorrect info.

but back to the original issue. Is my chip toast?

btw, I'm very much interested in the topic of loading the bootloader on the MCU. I have an old laptop with a parallel port and have proceeded to lop of the printer end of a centronics cable but haven't found any solid info yet on how to wire up the MCU or upload foodloader. I would like to try to reprogram foodloader onto the chip to see if that fixes my issue.

From what i've read I believe that I don't really need an ISP programmer is this true?

That 2.4V might be keeping you from completely resetting. Unplug the USB cable and then turn on the power. Then plug the USB back in.

Just a guess...

No joy, the chip just won't boot into program mode, it runs the last program I uploaded to it, and that's it. I'm really bummed. I was having a grand old time taking things apart and yanking various components out and hooking them up to the MCU.

Just to be thorough, although I changed nothing in the required makefile, so it shouldn't change things.....

make avrdude -c avr109 -p m168 -b 115200 -P /dev/ttyUSB0 -U flash:w:initialload.hex:a

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding make: *** [initialload-upload] Error 1

Do you have the LCD screen. If so hook it up, then you will have a lot better way of testing.

I also notice you do not have +5v connected to col 3 (red wire) from the programmer.

Jim

I get my power from a 5v cell phone wall wart, actually about 5.3ish volts. the wires come in on the left and are connected to a computer power supply switch I salvaged from a dead computer (also on the left.) The red wire from the usb to serial converter is not connected because I don't use power from USB.

Just a thought...

Some times, the contacts in these little breadboard blocks don't make contact. Can you verify continuity to the pins and their respective columns? I was thinking that maybe pin 14 isn't really grounded when all appearances say otherwise. Once in a while, the wire might miss the contact in the hole and it would not look like it.

Mine was humming along and all of a sudden it quit like yours, I just changed to a different port, fixed it that time.

I've actually switched between 2 computers with no success. Tearing down and rebuilding the circuit at least 3 times.

The very odd thing is, that the chip does load the last known program, and it runs just as intended. It just does not acknowledge that pin 14 is grounded! I just now rechecked that pin 14 is indeed grounded, touching my multimeter to +5v and the actual pin on the MCU and not just the bus, and the meter reads 5.04v, so......

it's so very strange. The wiring looks ok right?

Hi treymd,

That is a strange problem you are having. One thing I would try is powering the NerdKit off the USB Port. The voltage coming out of your wall wart without being regulated might be off enough to cause communication troubles. Remember to reset power to the chip to boot into programming mode.

Humberto

I rewired everything from scratch, just to eliminate bad wires.

tried running off USB power to eliminate that as a variable, although I was using a cell phone wall wart, which I believe is regulated. Unplugged USB, hard wired ground to pin 14. Still nothing, but again, my program is running instead of the bootloader's re-flash routine.

anyhow, is it physically possible to change something in the MCU to undo what it was programmed to do? By this I mean, is there some sort of fuse that could have been unset when I did something bad like connect a reed relay up without a flyback diode?

Why would the chip boot fine and run my program but not go into into the re-program routine of the bootloader? It all does not make logical sense to me... if the bootloader boots to the point where it can run my code, it should be functional enough to go into the reprogram routine. UNLESS there is some sort of fuse that can be accidentally unset, then that makes sense.

Hi Treymd,

There are fuses that control the bootloader behaviour of your chip. These do determine whether there is a bootloader there at all. I suppose it is possible, however very unlikely, that a random fuse bit got switched.

There are two things that are much likelier. One is that you damaged that bank of pins with your experimentation, such that the bootloader is running, but not recognizing that the pin is being pulled low. The other is that some form of disturbance caused your bootloader code to become jumbled (not unheard of for a particular section of the flash memory to get erased without affecting the rest). When the chip boots, it executes this random garbage immediately, at which point the program counter would loop around and begin executing your code. Both of these senarios are a stretch, but conceivable.

Sorry I don't have a good solution. Does the program space code appear to start running immediately when the chip is loaded, or is there a bit of a delay?

Humberto

It's getting up reasonably fast, as fast as I can open a terminal and hit a number anyway.

I read in the datasheet that the flash can get corrupted if you enter a low power state, which, because of the way I run the chip at times (with a 5v external PSU) that may be feasible, since the usb to serial still seems to be bleeding 2.4v through, and when I yank the power 2.4 is all it gets.

Or, like you said, the results of my haphazard experiment with the treadmill. (Which I am far from done with) The good news is, the fire went out almost immediatly! (I think the relay I was hooked into was meant to be pulsed, and not on continuously) But you gotta learn somehow.

Now all that's left of the treadmill are the motors and the belt table. I got this neat project in mind about marrying some 3D rendering software with the use of an MCU running the belt drive.elevation, but I have much to learn on the electronics side before that is possible. (the first being a MCU controlled circuit that supplies variable DC voltage to a 70v motor)

Anyhow, I'll be putting in an order for another 168 anyway, hopefully the cable is not damaged as well. But i would still like to try to refresh foodloader on to the chip. I'll shoot you an email requesting the parallel hack pinouts/short snippet if you got it, I read some stuff on the arduino bootloader and parallel, I assume the method is similar.

treymd

Let's back up a little bit and think about this instead of darting all around.

First of all, if the chip runs code previously as intended, then most if not all the chip is operating correctly. That is a given. So, let's look at some other things:

This statement of yours concerns me: "The very odd thing is, that the chip does load the last known program, and it runs just as intended. It just does not acknowledge that pin 14 is grounded! I just now rechecked that pin 14 is indeed grounded, touching my multimeter to +5v and the actual pin on the MCU and not just the bus, and the meter reads 5.04v, so...... "

That isn't how you check the value of the pin. You need to provide your meter with a reference voltage. In this case, that would be the ground rail. Always the ground rail. Connect your (-) lead to the ground rail, and then touch your (+) lead to pin 14 and make sure it makes good contact. It should read 0. If it reads higher than that, you have a problem in wiring, or that pin on the MCU has been damaged, or it isn't actually grounded and is floating high.

Check the voltage drop on your power-supply (usb or otherwise, it doesn't matter) and make sure that is safe. Check the voltage on your ADC pins, to be sure they are correct. Make sure pin 1 is high (again, put your (-) meter lead on the ground rail, and then touch the pin1 with your (+) meter lead) and atleast 1.5V.

Now, an important thing to bear in mind-- the only reason the MCU would care what pin14 does, is because of the bootloader the NerdKits staff already installed. It uses that as an indicator to enter 'programming mode'. If the bootloader is damaged, then it might not care what happens with pin14.

Once you know your voltages are safe, then we will proceed with testing the next thing.

Divide & Conquer

BM

Hey Boba..

Yeah... I'm a software engineer (Well halfway through the degree so Soft Engi till I earn some more letters. (Gonna love that robotics class)

Sometimes the physical tangible side of computing escapes me, but I just realized what I did. If I place a lead of the multimeter on the positive rail, and then another on the pin, then I'm really only reading the rails! (if the ground rail is jumped to the row the pin is in) silly me.

Anyhow the reference voltage you speak of, is this basically the (incorrect) reading given by my meter? It reads ~ 0.5v +/-0.5 all the time. meter+ to 14 meter- to ground reads about that (0.49) It's approximately the value I get off the rails with no power attached.

pin1 4.98 avcc 4.97 aref 4.96

variance due to my fingers I assume

everything on the other side of the USB cable is fine. ports match up in the makefile, (COM5 currently though I have used my fedora box and /dev/ttyUSB0, changing the Makefile as I go) GCC is operating same as it ever was. I'm talking to the chip on the same port avrdude is trying to communicate on, baud speeds are correct (115200) every wire was replaced with new wires at least 4 times, the wiring is shown above, and is exactly the same now as it is in the picture. Voltage is always 5v +/-hundredths.

forgive me if I jump right to the software, but in my experience it usually is the problem. but then again, I'm pretty darn inexperienced with electronics! My assumption at this point is that the bootloader is possibly corrupt, I wanted actually to try that next. To eliminate that as the problem. Failing that I will assume the chip itself or the IC in the cable is damaged, both of which I can confirm by replacing the respective hardware.

I do need to sit down and actually read the datasheet on the 168 though.. I've skimmed it but I CAN be accused of not RTFMing

treymd

I'm a software engineer too-- done it all in about 28 years of coding. So, "Hello" :waves wildly:.

When I talk about 'reference' voltage I mean that you must pick some voltage that you measure everything else against-- You must start with some known and measure against it. Consistently. Usually, this is the ground rail. Your meter measures the difference between its leads.

You might have a problem in software-- but I wouldn't even look there until you know the hardware is set up correctly, atleast well enough to know that you aren't shorting anything or have something backwards, etc.

IF you have voltage showing between your + and - rails, without a power-supply connected, I would look at the battery in your meter. Or the meter itself.

BM

Hey Boba,

28 years? that's impressive. Did you start out on punch cards? =) I suppose my start was way back on the atari 64 in basic in the early 80s. I made a ghetto security system with a torn apart joystick and lots of wire. I've only recently gotten a formal education in computer science though. The classes are a walk in the park, I find myself teaching more than learning.

You like I have probably at some point spent some time searching for that obscure bug only to find out it was really something quite simple. It's debugging 101, eliminate the obvious. I checked, double checked, and quadruple checked (and even after that posted my wiring for others to look at). I measured voltages, unwired the chip over and over again and rebuilt the circuit. I did, what I think is the best that I could to eliminate the "stupid simple" bugs. Please don't assume that everyone is making wild off base assumptions, I don't believe I did.

Turns out the chip was toast. Either that or my USB->Serial Cable, as the MCU is no longer doing anything. Until I procure a chip I know to be working I can't really eliminate the cable as the problem.

Hi trymd,

There actually is a way you can test to see if your cable is working properly. Go to the Servo Squireter tutorial, and go down to the Serial Communications section. Follow the directions to communicate with the NerdKit using Putty, but instead of connecting the yellow and green wires of the serial cable to the MCU connect them to the same empty row of the breadboard. Since the yellow and green, send and receive wires are hooked up together, everything you type on Putty should be echoed back to you on the screen. If your cable is not working properly you will not see an echo. Let us know what you get.

Humberto

You know that never occurred to me!

Yup, cable is fine.. MCU, not so much. Thanks Humberto!

treymd-

Just so you know, looping transmit and receive back on itself is called-- you guessed it: a "loopback" connector. :P

If you get another chip and it still doesn't work.... please post a schematic so we can look at that.

BM

Hi treymd thanks for this thread.

I was just about ready to post the same question but read this tread before posting.

I was having the exact same problem I could not get into the two bars programming mode on the lcd.

Some times I would get one bar or a half but I could not upload a new program.

Then thanks to this thread I have my answer. Remove the USB cable.

I would suggest, me not knowing much, that you remove the USB and try using a battery in stead of the wall wart.

Ralph

an update:

I got an AVRISP MKII and some more 168s. First thing I did was to hook up the "dead" chip and take a look. After refreshing the bootloader the chip works fine!