Hey everyone! I haven't been here in a long time. How are you, developers of NerdKits?

Anyway, I'm starting to work on my projects again and I want to try program avrs using my new AvrISP MKII programmer. I've built and wiered the ATmega168 that came with the nerdkit, however, when I run avrdude, it gives me this error:

    avrdude: stk500v2_command(): command failed
    avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

However, i've checked all the connections, and everything is correct. Microcontroller is powered, and 14.7 MHz clock is present. Since NerdKit's microcontroller comes with a boot loader, can I still use MKII to program it (I want to remove the bootloader and run the program directly)

Here is what avrdude -v tells: link

hm... well I fixed it... but I don't know how... maybe connections were weak :)

However, I still can't write any fuse bytes. I found out that lock can be erased to "1" only with chip erase command. I say avrdude -p m168 -euv, it completes it successfully, read flash returns a bunch of 0xff, however read lock, efuse, lfuse and hfuse return 0x3f, 0x07, 0xf7, and 0xd5 respectively... and "write efuse 0 0xff" says:

>>> write efuse 0 0xff 
avrdude (write): error writing 0xff at 0x00000, rc=-6
avrdude (write): error writing 0xff at 0x00000 cell=0x07

I keep rereading the datasheet, and I see the line saying "Both the Flash and EEPROM memory arrays can be programmed using the serial SPI bus while RESET is pulled to GND" So... Does it mean I can NOT program fuses with SPI?

Fuses and lock bits can be programmed via an ISP type programmer (which is what you have).

Do you have a photo of your setup for programming the chip?

Remember, the stock NK setup will NOT allow for programming via ISP. You have to make one change.

In order for the programmer to toggle the reset line as needed, you have to replace the jumper wire that would normally go from pin 1 to VCC with a resistor (10K should work fine). That way when your programmer needs to pull the reset to ground it can otherwise the resistor will pull it up.

Hope that helps,

Rick

I cant upload the picture at the moment, but i did modify setup from the original - removed the program enable switch (pin 14 is now open), and connected RST from avrisp2 to reset pin. Pins 7 and 8 are vcc and gnd, crystal clock is also there. On the other side of the chip - gnd, AREF, and AVCC are connected. RESET is without any resistors, because, i believe my programmer already has one in its circuit. (take a look) Anyway, adding a pullup resistor didnt change a thing.

oh look, i just realized that lock fuse changed to 0x3f (01111111) after chip erase, while it was 0x2f (01011111) before. However I still can't write to efuse, lfuse, and hfuse.

picture would be nice. I had similar problems when I was using avrisp mkII clone. I had 2 issues: 1) RST was pulled high 2) Had jumpers connected in the wrong place on my clone avrisp that made it act funky.

That's the exact programmer I have! Got it on ebay in kit form. The only difference is I reprogrammed the firmware as a USBASP.

Rick

Well I feel stupid... So, I went to the bootloader dir on my computer (foodloader), and decided just to try and type make... IT WORKED!!! Turns out, since in lock byte, only first 6 bits are used, I couldn't write 0xff in it, but I could write 0x2f, 0x3f, or any other thing. same goes for the rest of the lock bits - I could write only the amount of bits that were actually used.

Had to do a little ritual dance around the fire to fix my avr-gcc, now it compiles and uploads. Everything works... Almost... I tried uploading led_blink... all it does is

int main()
{
    DDRC |= (1<<PC5);

    while(1)
    {
        PINC |= (1<<PC5);
        delay_ms(1000);
        PINC &= ~(1<<PC5);
        delay_ms(1000);

    }

    return 0;
}

However, instead of blinking every second, it blinks every 7 seconds! so i susoect it runs on internal clock or something, but my lfuse = 0xf7!!! (0b 11110111) just like in fuses_mike.txt in the bootloader. Also tacking clock out makes the blinking stop completely. Any ideas why?

Do you have

#define F_CPU 14745600

(or whatever the correct value is) in your source code, or -DF_CPU on the avr-gcc command-line in the makefile?

First i just had #define F_CPU 147... then i tried adding -DF_CPU=147... and it didn't help

I had the same problem, it was something fairly simple (IIRC), I'm just looking through my notes to see if I documented what I did to fix it. If I find it, I'll give you a shout.

-S

Does the Makefile in the bootloader read as below (just thinking if I altered something in there)

AVRDUDEFLAGS=-c avrispmkII -P usb -p m168

all: fuses install

fuses:
    avrdude ${AVRDUDEFLAGS} -U lock:w:0x2f:m
    avrdude ${AVRDUDEFLAGS} -U efuse:w:0x00:m
    avrdude ${AVRDUDEFLAGS} -U hfuse:w:0xd5:m
    avrdude ${AVRDUDEFLAGS} -U lfuse:w:0xf7:m

install:
    avrdude ${AVRDUDEFLAGS} -U flash:w:foodloader.hex:a

I'm sure this works for me (although I haven't used it for a while so I may be wrong)

I'm sorry for a long post, I'm just really frustrated with this and would appreciate if you checked my math. Alright... My recent findings... I'm loosing exactly 10 times of the frequency somewhere. How I found this out first. In delay.c we see 2 NOPs is perfect for 8 MHz clock. In the datasheed for ATmega168, it tells us that 1 NOP takes 1 clock to execute.

1/8MHz gives us a period of 125ns 125ns * 2 NOPs = 250ns, therefore to perform the "for" cycle it takes 6 more clock pulses. So we can say that the time of delay for delay_us(1) = (1 / Frequency) * (Number_of_NOPs_defined + 6) * 1. In the code I have delay_ms(500); in between I turn LED on/off; therefore the time of the delay for delay_ms(500) = (1 / Frequency) * (Number_of_NOPs_defined + 6) * 1000 * 500;

Solving for frequency gives us: Frequency = (500 * 1000 * (#of_NOPs_defined + 6)) / (Delay time measured)

So, I'll just leave Number of NOPs defined in the function as 2.

Try #1: Setting lfuse to 0xE2 to use internal 8Mhz clock without prescaler. Using a stopwatch I get delay time of exactly 5 seconds. Frequency = (500 * 1000 * (2 + 6)) / (5) = 800kHz = 0.8MHz

Try #2: Setting lfuse to 0xF7 to use external full-swing clock without a prescaler. I use the 14.7MHz clock shipped with the nerdkit. Using same code (2 NOPs) I measure time delay being little less then 3 seconds. Frequency = Frequency = (500 * 1000 * (2 + 6)) / (2.8) = 1.43Mhz (which is very close to 1.47MHz)

So it seems like my frequency is exactly 10 times (!) as slow as it is supposed to be, no matter the source of the clock.

Any ideas where can I loose 10 times the clock?

oh yes, one more thing, installing the foodloader back, and uploading this program through it works exactly the same... so I don't think it's something wrong with the fuses...

hm.. stupid moment... in my code, replaced PINC |= (1<<PC5) on PORTC |= (1<<PC5), and same for turning LED off.... and the blinking speed increased immediately, now I have only about 3.5 timex clock division

Alright, I've found all my missing clock cycles!

I ended up disassembling the program and looking at what's going on there! Turns out, if I compile delay.c with -O0 flag - it will add a lot of op-codes there that will just slow you down! Then I recompiled everything with -O2, which removed many of those op-codes and my LED blinks at what seems exactly half a second :D However, -Os did decrease resultant file size (my executable was down to about 280 bytes), but LED started blinking every 750ms instead of every 500ms.

Not sure if this is gcc version specific, by my avr-gcc is gcc-4.4.4-r2

Wow, I'm glad you got it all figured out... It was kind of rough to follow your posts at times... You were doing a bit of thinking out loud as you typed.. :D

I haven't ever noticed a 10x increase in delays. With that going on, the nerdkit LCD routines probably wouldn't even work. Of course, I haven't tried disassembling any file - wouldn't do me much good since I don't know assembly :)

In case you are wondering, the version of avr-gcc I have came with my WinAVR 20100110 install and reports as 4.3.3 (WinAVR 20100110).

Rick

Yea, I was trying to write my thinking, for someone to catch, in case I was thinking wrong lol

As far as disassembly, if you look in the most nerdkit's Makefiles, there is a command to create an *.ass file, in my case i'd type "make led_blink.ass" is creates pretty much a source file for an assembly manguage. It'll also grab lined from your "c" source code and print them along for you to keep track where exaclty you are. and in the datasheet, on page 347 it tells you how long each of those instuctions lasts. that way, you don't really need much assembler knowledge. But it's a very fun language :D

I've thought of trying to learn it. But I don't really have the time right now. I've some informative stuff online for learning avr assembler but haven't really pursued it.

Rick