All,

I received the following error message when trying to compile the initialload.c program.

Any ideas? I noticed the baudrate of the makefile was 115200 and my COM port was set at 9600 but that didn't resolve the issue.

115200 is the correct baud - the 9600 you see in Windows properties is not what software uses, it's just a generic default for Windows. The micro and avrdude by default NK configuration will use 115200. As for the error you are getting, it is the most common error we see around here and help has been given MANY times... However, what that error essentially means is that the PC and micro are not talking to each other. This can be caused by A LOT of different scenarios.

• Check your USB connection to the micro pins 2 & 3, make sure the wires are in the correct position.
• Do not connect the red USB wire to the power rail if you are using a 9V battery.
• Do connect the black USB wire to the Ground rail even if using a battery.
• Double check the COM port settings (I see from your window you selected COM4 make sure that is your USB adapter)
• Make sure your program switch is in the correct position for programming (slid toward the micro.
• Double check all wiring.

There may be some I missed, but those are probably the most common. If you still can't get it, pictures of the setup with your USB cable connected can be helpful.

Rick

The "Huh? Go" in the error message definitely means your chip was not in programming mode when you attempted to program. Make sure the programming switch is in place, flipped to the right position, and reset power to the chip so it boots into programming mode. You should see two black bars on the LCD when you are in programming mode.

Humberto

Thanks to the both of you.

I've recycled power, and unplugged/plugged the MCU back into the board. When I recycled power, I finally got the "programming mode".

Thanks guys. On to the next project - temp sensor!!!!!

Again, Thank you!

I am getting an initial program load error too. It worked the first time but I had changed the output to the display and some of it was too wide to fit on the screen and bled over. I corrected the program and tried to recompile and load but this is what I get...

/ ---------------------------------------------------------------------------------- /

user@user:~/AVR/code samples/Code/initialload$ make make -C ../libnerdkits make[1]: Entering directory /home/user/AVR/code samples/Code/libnerdkits' avr-gcc -g -Os -Wall -mmcu=atmega168 -o delay.o -c delay.c avr-gcc -g -Os -Wall -mmcu=atmega168 -o lcd.o -c lcd.c avr-gcc -g -Os -Wall -mmcu=atmega168 -o uart.o -c uart.c make[1]: Leaving directory/home/user/AVR/code samples/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 ../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o avr-objcopy -j .text -O ihex initialload.o initialload.hex 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.01s

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: error: programmer did not respond to command: chip erase make: *** [initialload-upload] Error 1

I haven't read up much on AVRDUDE but not even sure where the -D option is in the command line or if I added it, it would just write to the MCU and bypass the erase all together.

Hi Ron1957, That could mean a wiring error. Also check to make sure your makefile is correct and your com ports are OK. I do remember experiencing that same problem when I first got my nerdkit.

• missle3944

Hi Ron1957,

In addition to missile3944's suggestion I would also check the battery. The fact that it is getting through the read cycle, but then failing on the write cycle makes me think the battery might be low. It takes way more current to write to flash than it does to read from it.

Humberto

Thank you Humberto and missle3944, I will try a new battery and see if that works. First, I will check the wiring again. I did have some trouble before and put everything back together again and got the original message flashed by the Nerdkit team. I am using tweezers to put everything together. Wished the breadboard were larger.

Ron1957