I am using a nerdkit with osx and have reprogrammed my chip probably 1000 times. avrdude just started hanging just before writing the chip. I am using the 1.4.0 prolific driver. I have a bad habit impatiently trying to flash the chip without setting it to programming mode first, and I wonder if I accidentally overwrote the bootloader?

~/Desktop/Code/initialload> avrdude -c avr109 -p m168 -b 115200 -P /dev/cu.usbserial -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 (7916 bytes):

Writing | | 0% 0.00savrdude: butterfly_recv(): programmer is not responding

Ok, my chip is fine. I can still use the old driver, but I have to unplug my usb cable every time, and it communicates a lot slower.

The new driver works one single time after I reboot, and then it hangs.

I had the new driver working repeatedly without unplugging the usb cable for a week or two, not sure what happened. Is there anyone developing with OSX who has this issue resolved?

"resolved" is a little to broad. Live with yes, I have that part mostly working.

Have you tried putting the delay in the Makefile? I am looking for the reference.

I use a switch (spst) on the yellow wire. I have to make sure and switch every time I go from programming to run mode (off/open).

This is livable but certainly not "resolved".

Ralph

I believe this post is the Makefile fix Ralph is referring to. This could also be a battery issue. But give the Makefile fix a try and let us know what happens.

Humberto

With the delay in the makefile, the new prolific driver is working for me again. I don't have to unplug the usb cable and I get a much faster transfer rate!

I am running my project off of he usb power, so I just have a momentary spst that I can hold down to power off while toggling the programmer pin. Thanks for your help guys.

I am running osx 10.6.4 on a 2.4Gz core 2 duo macbook pro.