Hi. Just starting out with my first nerdkit and came to the section in the guide where I compile and download the initialload.c program. I was wondering if there was anything telling about this particular makefile output, which might point me in the right direction as I start looking into the problem:

# make
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.00s

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: reading input file "initialload.hex"
avrdude: input file initialload.hex auto detected as Intel Hex
avrdude: writing flash (7886 bytes):

Writing |                                                    | 0% 0.00savrdude: butterfly_recv(): programmer is not responding
make: *** [initialload-upload] Error 1

Host system is Gentoo amd64, kernel 3.1.6. /dev/ttyUSB0 is showing up correctly. avrdude version 5.11.1 from Gentoo portage. Using gcc 4.5.3 (avr target), avr-libc-1.6.0, and binutils-2.22 (avr target) which I built myself following the avr-libc user manual (since Gentoo crossdev is currently broken). The makefile I downloaded was:

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/ttyUSB0
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

Hi infraRed,

Whenever I see a flash fail just at the beginning of the write cycle, I always suspect a dead or dying battery. Writing to flash takes way more current than reading from it, so a weak batteries voltage will go way down causing the chip to reset.

If you have multimeter, check the voltage at the battery terminals, and at the 7805.

Humberto

I bought two fresh 9v batteries, hooked up one, and then performed the 'make' procedure again. The process appeared to have completed successfully. However, after flipping the programming switch back and cycling power, the LCD screen only displayed the words "is alive!", in the first line of the LCD.

Imagining that the write had somehow failed, I switched out to my second fresh battery, and then went through the upload procedure again. This time the "programmer is not responding" error occured again, as I described in the original post. Since then I have tried the whole procedure again multiple times with multiple batteries but only the "programmer is not responding" error appears.

I recently got hold of a multimeter and checked the batteries. All three that I have are registering at about 9.4 volts. Across the output side of the 7805 I am reading 4.94 volts.

Hi infraRed,

Well that is quite strange. Could you post a couple of good close up pictures of your setup. Perhaps there is something else we are missing here.

Humberto

Before creating any pictures, I went ahead and did a triple check on the wiring. Everything appears to be in order, although I reseated a few wires. After attempting to upload the program a few more times, I discovered the interesting fact that the upload always completes the first time I try after I reboot the PC. (Subsequent attempts fail until I reboot.) Perhaps some unread bytes stuck on the line...?

Even when it suceeds, though, I am still getting the incorrect LCD display:

https://frigidcode.com/paste/nerdkit-pics-20110306-not-working/IMAG0175.jpg

Following are links to the wiring close ups, at various angles:

https://frigidcode.com/paste/nerdkit-pics-20110306-not-working/IMAG0169.jpg

https://frigidcode.com/paste/nerdkit-pics-20110306-not-working/IMAG0170.jpg

https://frigidcode.com/paste/nerdkit-pics-20110306-not-working/IMAG0171.jpg

https://frigidcode.com/paste/nerdkit-pics-20110306-not-working/IMAG0172.jpg

https://frigidcode.com/paste/nerdkit-pics-20110306-not-working/IMAG0173.jpg

https://frigidcode.com/paste/nerdkit-pics-20110306-not-working/IMAG0174.jpg

The images are very large (>=1.5M) because I wanted to give the best resolution possible. You'll note I made one custom change which was to insert a switch between battery red wire and regulator positive, for my own convenience. (To avoid having to unplug the battery each time.) If I bypass the switch it doesn't seem to affect results at all.

Hi infraRed,

I believe that we might be seeing two separate issues here. The first is an over-zelous compiler. We have seen the newest versions of avr-gcc on linux optimize away a bunch of the no-ops that are used to time the LCD code. Try changing the -Os in the Makefile to -O0 (thats dash capital letter O, then the number 0). Remove all .hex and .o files from libnerdkits and from initialload, and then recompile. I believe that will fix the LCD display issue.

The second is the restart required, which is stranger. Have you tried unplugging the USB-ser cable completely from your computer, resetting power to the chip, and then plugging it back in. There is a weird bug where the chip can be kept in a strange zombie on state through the UART data lines, which could be causing this issue.

Humberto

-O0 seems to have fixed the problem with the program, as the display is showing the full message now. Though, just to make a note of it, I had to change the GCCFLAGS for both libnerdkits/Makefile and initialload/Makefile. Thanks!

As regarding the restart issue, I have tried that already several times without effect, though admittedly I have not yet tried it again since I got the initload program downloaded correctly.

Hey Guys,

I can confirm the problem with the -O0 on the optimizer. The symptom is the last line being written ends up on the first line removing all other lines and the first character is missing. The remaining three lines of the display show nothing.

I'm running an Xubuntu system which has avr-libc 1.7.1-2 at the time of this writing (NerdKits only has 1.6.2-1). This translates in to the AVR Libraries 4.5.3 (and I'm sure it's corresponding compiler) which has this problem. On my Windows box (installed using versions from NerdKits) only has AVR Libraries 4.3.2 (and whichever compiler it uses). I hope these version numbers and the symptom description help someone in the future as I was just about to post the problem in this forum after scratching my head for several hours.

Cheers, Dan

Hey guys,

Have you figured out a fix for the restart issue? I have had the same problem word for word as infraRED had. I got the initload, tempsensor, and led_blink to all load using the -O0 trick but I had to restart my computer each time.

Hi,

I have the same two issues. Any suggestions for the restart problem?

Using Mac 10.9.5

Thanks