I'm having all kinds of fun, My building blocks are broken, but never fear, help is on the way. Get this, programming switch down apply power it runs. Disconnect the power put switch up (pin14 to gnd) apply power and it STILL RUNS!!! What now! how am i supposed to compile another program? I've been at this for 9mo's now and this one takes the cake for Dec. Oh, and don't worry I know there's no fix, except maybe a new chip.

Hey! How about a forum category for Weird Happenings.

That really depends on what code you've got in the thing, as to whether or not it cares what PIN 14 does. PIN14 for programming, was set that way by the NerdKits bootloader-- but has no bearing on flashing the chip by other means.

If you have an unmodified/un-re-flashed ATMEGA168 from the NerdKits, and it isn't responding to pin14 correctly-- then you have a 'weird happening.'

Happy New Year! BobaMosfet

Thanks Boba, Happy 2010 to you too!

Yes on all of the above. Here's another one for the "Weird Happenings"

This is loading the bootloader via usbasp.

"make.exe" all avrdude -c usbasp -pm168 -U lock:w:0x2f:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406 avrdude: reading input file "0x2f" avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lock written avrdude: verifying lock memory against 0x2f: avrdude: load data lock data from input file 0x2f: avrdude: input file 0x2f contains 1 bytes avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ... avrdude: 1 bytes of lock verified

avrdude done. Thank you.

avrdude -c usbasp -pm168 -U efuse:w:0x00:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406 avrdude: reading input file "0x00" avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of efuse written avrdude: verifying efuse memory against 0x00: avrdude: load data efuse data from input file 0x00: avrdude: input file 0x00 contains 1 bytes avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ... avrdude: 1 bytes of efuse verified

avrdude done. Thank you.

avrdude -c usbasp -pm168 -U hfuse:w:0xd5:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406 avrdude: reading input file "0xd5" avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written avrdude: verifying hfuse memory against 0xd5: avrdude: load data hfuse data from input file 0xd5: avrdude: input file 0xd5 contains 1 bytes avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ... avrdude: 1 bytes of hfuse verified

avrdude done. Thank you.

avrdude -c usbasp -pm168 -U lfuse:w:0xf7:m

avrdude: error: programm enable: target doesn't answer. 1 avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check.

avrdude done. Thank you.

make.exe: *** [fuses] Error 1

Process Exit Code: 2 Time Taken: 00:01

Got any you want to contribute?

I think maybe i should start my own website.

Here's another "Weird Happenings" just to get warmed up.

This is a brand new installation of xp and avrdude with the nerds chips. alt image text

I'm havein a blast. This is it for today's entry's though.

This is the same chip, same software.

alt image text

Don't be shy, give it a try.

Mornin' Farmer, How about a pic of how your ISP programmer is connected to your chip. Also, If you got the chip from the NK guys, why are you messing around with the fuse settings?? An accidental mis-step in programming fuses can render your chip virtually useless without a high voltage programmer to reset it.

Based on the images and errors you are randomly getting, it seems there is a problem in communications between either your pc and ISP programmer OR your ISP programmer and chip.

What is supplying the power to the chip during programming?? External 5v or are you trying to get it from the USB on the programmer??

Rick

By the way, pin14 means absolutely NOTHING to an ISP programmer. When it comes to programming the chip, it is only used for the NK serial bootloader. For ISP programming, you need nothing on the chip except power and the oscillator crystal (assuming the fuses are set the NK way)

Top of the afternoon to ya,

I just got a small clue as to what's "not" going on. When I started from a fresh boot the thing actually flashed the ledarray again. But to apply the power does nothing, the trafficlight still works on another chip, but that's the one that won't shut off. "Weird Happenings" one works one don't. So are you saying these this isp flash is a one time thing? Flash and run, that's it?

So no pic's but the currant flash was through usb power. But the other experiments if it didn't find the chip I'd disconnect only the vcc from usb and apply power. It works/doesn't work both ways.

And I've been lookin at the fuses alot but so far I haven't changed them, When flashing the bootloader.hex the fuses are set already and appear in eXtreme Burner.

ps. Could you post your method for posting pic's, thx

Rick is right-- I think this will help clear a little up. The bootloader from NK is there only if you use THE NK HEADER to program the chip. If you are flashing it directly, with your own programmer, you don't need a bootloader. At all.

And your right too, I was trying to load the bootloader because I thought I erased it. All the fun I've been havin ya know. But yeah, that part of it wasn't quite clear, knowing it's there is clear and it does dictate to the NK serial but I also thought it was needed to actually run their code, fuse wise.

So I got the ledarray flashed and hook it, power it and nothing. To me that suggests that the bootloader is missing or the array needs the serial to program it too.

Without the bootloader, you may have to put a slight stub on the beginning of the code, to tell the chip to relatively jump to it.

I know that even with assembly (the way I'm doing it), my first instruction (.org) tells it where to put the code) and my second one is a relative jump to the first label where my code really begins.

That sounds good Boba, but i'm still in my rookie year and haven't started seriously leaning a language. I'm getting to be a hacker but to rewrite code doesn't work for me. So what your saying is the code "has" to be altered to run? I haven't got this quite figured, the trafficlight is running, flashed from isp with the bootloader on board. I can't figure why the ledarray code doesn't "just do" the same thing.

Try this angle,@ guy's.com Serial programmer, connects to tx rx ports which is what the bootloader is responsible for. ISProgrammer connects to mosi miso sck pins 16,17,18. Now if i could figure out the difference between the two different paths and how they arrive at the same place, the flash. I would get a clearer pic in my head.

Right now there's bits of data coming in both the front and the back doors and meeting in the middle, the (flash/eeprom) Realizing this doesn't actually happen at the same time, and the mosi miso sck port pins are the standard programming pins and the tx/rx are for serial only, hence the bootloader.

What i'm really digging for is WHY? I mean WHY? one out of 3 now, programs flashed and only one runs, i just flashed the heart and it don't run either.

This is a boarderline "Weird Happenings" more like, time to quit.

Grant,

When programming via the serail port, there has to be a user installed program on the chip. By default, the atmega168's do not self program through the serial port. The user installed program is called a bootloader because its only function is to receive program data through the serial port of the chip and flash that data into program memory. That is why the NK bootloader uses a switch at pin 14. This is the bootloaders way of knowing you want to be in program mode. Otherwise it simply attempts to execute the code above it. Fuses cannot be changed via a serial bootloader.

The fuse settings in the atmega168 chip can create a "safe" space at the beginning of program memory for the bootloader. This prevents accidental overwriting if programming via ISP. I believe they also tell the chip where the new beginning of program memory resides. That is why some of the fuses are set the way they are in a NK chip.

ISP or In System Programming - is a method of programming the chip that is "built in". This programming method requires nothing to be installed on the chip. A factory fresh chip can be programmed using this method with nothing more connected to it than the programmer and power. (With an NK chip you also need an oscillator due to the fact they change the default fuse settings). This is the method used by people to install a bootloader, update fuses, or program the chip.

Those are the main differences I know of between the two programming methods. Hope that cleared it up a bit.

Rick

That's super, Thanks Rick,

I saw the self programming part and couldn't quite get a handle, but that would mean simply put, without a bootloader.

I also saw the fuses were changed from default, it's good to know why finally. This is getting clearer. So the fuse settings tell the program were to sit. Ok, for regular .c code I would need to set the fuses to default then, via isp. Since the code is self programmed. This bootloader guy is a real pain I say we kick the bootloader right out,(boot the bootloader) set the fuses to normal and get on with my life. Wait, I still have to figure a pin14 routine into the code. I still would like to reprogram the chips.

And then, why did they call the bootloader and the firmware two different things? Just sorting out these things can take days. When you say update the fuses, reprogram or add to the program is also what they call a firmware update. Good eh?

Without you I would be had, the nerds have cut me loose. Thx again and keep up the good work!

Grant

Well I think I need some different software or chip's without a bootloader.

The eXtreme i'm trying to use erased the chip no problem, but to program it... either target doesn't answer or is not a atmega168. So I'm done.

Pin 14 is only used when programming via the serial port with the bootloader. It means absolutely nothing when programming via ISP.

As I said before, unless you are 100% sure, do not mess with the fuses in the micro-controllers. Doing so incorrectly can render the chip unprogrammable by ISP or serial.

Have you changed any fuses? If so, this could be the cause of some of your problems.

Again to clarify the two programming methods we've discussed.

bootloader method: Uses software written and stored in flash memory to read the compiled program via the serial connection and burn it into the program section of flash memory on the micro-controller. The NK bootloader is initiated by grounding pin 14 and resetting the mcu.

ISP method: Uses hardware built into the micro-controller to receive the compiled program and burn it into the flash memory of the micro-controller. Does not require anything done with pin 14 to work.

If via the ISP programmer you are getting target doesn't answer or is not an atmega168, you either have a communications issue between the chip and pc, you have something wired wrong, or the chip is not functioning properly.

Is that multiple choice? I'll take a and c.

Yeah, just for the hell of it I installed eXtreme Burner-AVR on my desktop that's the one the gcc doesn't work on and it'll find the programmer but it won't power on. That's with usb or regulated power. So doesn't leave much else, except for this software compiled yesterday and today it wasn't the right chip. Did I mention this is with 3 new chips? All with a flash that don't work and you know the rest. Somehow, sometime hopefully soon this will all work and then i'll be bored. Good exercise at best :D

Oh, and by the way there Rick, Somethings just take longer to sink in. The ole pin14's is a part of the reset! Man that's got that cleared up. Believe it or not I looked at that reset wire to vcc a thousand times puzzled by how it functioned. Well geeze it's like, say what? The ground to pin14 is the circuit to the reset? I want to say, I knew that! But I can't, good goin there, @guys.com (something i borrowed from another post) another mystery explained.

Look for my next post "Escape From Program Space" by JoeBit Vol_1.0

Good Morning Rick,

Instead of starting a new, I figured this will show "part" of my joy ride. Check out the previous pic. ttyl here

Grant,

I apologize for inadvertently misleading you. When I said " The NK bootloader is initiated by grounding pin 14 and resetting the mcu ", I meant those were two separate functions. The 1st being the sliding of the switch at pin 14 to connect it to ground, and the 2nd being the disconnection / reconnection of power to the mcu to reset it. I did not mean that pin 14 is in any way a reset line on the mcu because it is not.

When the atmega168 is 1st powered up the chip will run the code at the beginning of memory. The chip as sent from Nerdkits contains a bootlader program there. This program checks the status of pin 14 and if pin 14 is pulled low (grounded by turning the program switch on), then it enters program mode and waits to receive code through the serial port of the chip. As this code is received, it flashes it to the program space of flash memory. As far as programming the chip is concerned, that is all pin 14 is for. It is simply a method the creators of the bootloader software used to determine whether or not to enter program mode or run mode.

As to your pic, I noticed that you still have a -b 115200 -P COM4 in your makefile line.

With the USBASP programmer, since its not a serial programmer, I beleive you don't need that. Try removing those entries from the AVRDUDEFLAGS line in the makefile.

Do you have a digital camera? Can you take an overhead shot of your circuit with the programmer connected and post it? It could be helpful.

Rick

I made some progress! I got another successful flash this morning and but, it still wouldn't run. Guess what? I got two regulators both work in one board and they don't in the other. Geez man, when things start going wrong they really go wrong. Geez I even moved it over to a different spot and one "board" works the other doesn't.

Not to worry about the pin14 issue, It's not in play anymore. You never answered on if this is a flash and run system. Once flashed that's it, no more flashing? There's no way to tell the program to stop and load another one without pin14 reset?

Let me clear that last part up. Once flashed via isp the chip can be running and reflashed with different code at the same time. The software stops/pauses the initial code, preforms a erase and replace (another assumption.) No pin14 needed. Don't know if that's exactly what happens but, it WORKS!

And one last note, if you ever over juice your system with a mere 19vdc don't just replace the obvious parts. Throw it in the garbage QUICK including the breadboard. Yes, the breadboard!(That way you won't mistakenly try to use something again.) 4mo's of debugging to find the circuit "in" the breadboard was "part" of the problem. Man,when things start to get that dirty, I can see why oscilloscopes are absolutely A MUST. Amen.

Thanks to the guy's at guy's.com FOR ALL YOUR HELP! it's a New Year, Happy nerding everyone.

Because ISP programmers control the reset line on the micro-controller, they will program a chip on the fly. Glad to hear the programmer setup is working. Why the code won't run??? Don't have an answer for that one right now.

Rick

That's OK Rick,

You already answered it.

It was or is the "breadboard" It's connecting not connecting via the voltage regulator. Damdest thing, take out the vr and apply 3v direct power and it works. The same two vr's work 100% in my other board. Good one hey? So you did it, again. Good goin.

Guess what? I put the new xp installation cd on my desktop, and it's magic, the gcc works again!! The software is "finally" doing it's thing, successful flashes on either machine. Now i'm bored until I go out and get somemore parts. Happy Nerding!!