Hi all,

Recently bought the latest USB Nerd Kit and have been having a great time with it. I worked my way through the initial builds and wasn't having any trouble with the Mac version of the AVR Pack or the OSX PL2303 driver. Now that I'm starting to tinker with some of my own code and projects I've noticed something quirky.

If I plug in the USB and run my 'make' ... the code will compile and flash up to the kit. If I then wait a bit (perhaps I'm making some code changes and/or testing my latest tweak) I'll find that I cannot upload again but will instead get a ...

butterfly_recv(): programmer is not responding

... if I then unplug the USB and give the Mac a reboot and start the process over it will work for my next compile/flash.

It's almost as if the Mac (not blaming the Nerd Kit) has a timeout on the USB device and if there isn't usage there it loses the connection. The /dev/cu.pl2303.... device will still be there but it effectively isn't responding.

I was just curious if there were other Mac/Nerd Kit users who have seen this behavior.

Thanks!

I should add that I'm running 10.5.6 Leopard.

I'm guessing the driver made available through the Nerd Kits download area is the BJA Electronics driver? Has anybody tried the Prolific driver?

I use a Mac and have intermittent problems with the programmer.

This usually works;

1. unplug the USB

2. disconnect power from NerdKit

3. power up NerdKit

4. plug in the USB

I find I have to do this almost every time.

Even when it works the verification fails about 75% of the time but the code always loads.

Hey, you're absolutely right! Following your steps appears to solve the problem temporarily, although this is very annoying. May I ask what kind of Mac you're using? I have a 15" MacBook Pro from late 2006.

BTW - Almost every time the read/verify fails with "programmer is not responding."

Sorry for the double-post (there's no edit or delete button), but one thing I noticed is that /dev/cu.PL is spewing tons of garbage (actually, it appears to be contents of my system's RAM, somehow) if I try to use "screen /dev/cu.PL 115200" to connect to it after getting the "not responding" error. Do you get this too?

Here's a screenshot of the strange garbage I get:

I have a 15" MacBook Pro I got last summer.

I have been using iTerm for watching the serial connection. Occasionally I get garbage on it but it usually works fine.

I tried the Prolific driver ( http://www.prolific.com.tw/eng/Products.asp?ID=59 ) ... the most noticeable difference being that the device it creates is called "cu.usbserial" rather than "cu.pl2303.xx" etc

This other driver exhibits the same behavior though ... if it sits idle for too long it effectively loses it's connection. So either the drivers share the same flaw or it is something OSX related.

digitalpenguin-- answering your original question, I do the same thing as DonNYC, but if that doesn't work, I make sure all the cables are connected properly, and if that still doesn't work, make sure the microcontroller is in the programming mode. Often times, I forget to plug the programmer in altogether, or forget to put it in programming mode.

Ethanal

Just to make a note for future users, it is my experience that on some Macs the USB cable needs to be plugged directly into the computer and not through a USB hub to work consistently.

Add one more user getting the same error. I get it at different points, but in no case have I gotten all the way through the programming. That is to say the longest it has gone without error was to load the program, but fail with that error while doing the confirming read. The program does run in these cases, but it might take several attempts to get it that far. I am running a MacBook Pro with Leopard 10.5.7. And I am connecting with the supplied cable to the USB to RS232 attached to the butterfly...attached via spaghetti to the breadboard. So it sounds like I am in about the same boat as several of you. I really love these things, but this is FRUSTRATING. Please advise soonest...

John

I was helping another user with a different issue and it turned out that his PL2303 driver was buggy. It wasn't the same issue as you guys are having, though (his was more along the lines of the driver ignoring ioctl() requests), I would recommend you check if you have the latest driver from Apple (0.3.1 dated February 4th, 2008) or perhaps try a different driver, if such a thing exists.

Just my 2¢.

Zoran

I just ran into the same problem (butterfly_recv(): programmer is not responding) with the USB plugged into the keyboard (iMac 2.66 Intel Core 2 Duo, OSX 10.6.1). Plugging directly into the machine, rather than the keyboard port fixed the problem.

I just got my USB NerdKit, and I'm seeing a similar problem. I find that that about 1/5th of the time, avrdude cannot connect to the NerdKit at all. 3/5ths of the time, it is able to connect and erase the flash memory, but then it times out when trying to write data. The final fifth of the time, it completes successfully. Also, I have to power-cycle the nerd kit between every attempt. This makes programming the NerdKit rather annoying.

I should note that I think I actually have both of the drivers for this USB Serial adapter. I have /dev/cu.usbserial and /dev/cu.PL... Perhaps I should try removing one driver. I'm running OS 10.6.1.

When I use "make" I start with only c code. If i have run make before then I first erase the .o and the .hex files with rm.

I have had similar problems with OSX 10.6, and the USB ports on my display & various hubs, in each case suffering similar failures as to everyone else.

However, plugging the USB cable directly into a USB port on my Mac Mini solved the problem 100%. Note, the enlarged head on the plug essentially requires two slots the way the usb slots are setup on the Mini, so not exactly ideal, but I have been able to use the programmer without any further problems.

I just got my Nerdkit and I also have this issue on a 15" Macbook Pro running 10.6.2 with the USB cable plugged directly into the USB port on the power-adapter side (with the power adapter plugged in to the wall).

The odd thing is that I can often get through the "Writing" phase, but the "Reading" phase will frequently fail at some arbitrary percentage of reading. One would think that if this were a problem of putting the USB port to sleep or something after a period of inactivity, then the Writing phase would suffer since it comes first.

Going through the various combinations noted above of unplugging the USB cable and the battery on the nerdkit usually fixes the problem eventually, until the next time I go to reprogram.

It has been a while since a post was made here. I am having the same issues, wondering if a solution was found.

Hi Jessiewbailey,

Can you let us know the full error you are getting on the command line, and if possible post a clear close up picture of your set-up. Sometimes an error in wiring can masquerade as this type of communications error.

Also, are you on a 64 bit system, or 32?

Humberto

I am on 64 bit system (iMac Core i5 OSX 10.6.3). I actually got it to write to the chip once, but the result most other times is:

10-0-1-281:initialload Jessie$ make avrdude -c avr109 -p m168 -b 115200 -P /dev/cu.PL2303-000013FA -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 (7838 bytes):

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

Sometimes it fails before and I get the following:

10-0-1-281:initialload Jessie$ make avrdude -c avr109 -p m168 -b 115200 -P /dev/cu.PL2303-000013FA -U flash:w:initialload.hex:a

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding make: *** [initialload-upload] Error 1

This sounds like the inconsistent problems described by other users here...

Update - I can upload the code, but I have to restart my computer each time, then it no longer works. I am happy that it works, but hope I can resolve this so I don't have to restart my computer 50 times to get a program right...

I am experiencing the same problem. Works great with my Windows machine. Usually fails on verification read on Mac Book Pro running 10.6.3. The writing has always succeeded so far.

I am running the Prolific driver. I forgot that I already had it installed since I already have a USB to Serial 9 pin for some stuff at work.

I did notice that the USB to Serial that I got for work has a serial number and the one from the NerdKit does not.

Would slowing down the baud rate help? Can I just change speed in the Makefile or does the loader FW also have to change?

Regards, Dean

I tried 57600 baud and that did not work at all. So much for that idea.

For some unknown reason, this seems to work for me. I switched from the USB port on the right side of the keyboard to the USB connector near the power connector on the left. VOILA! It worked 5 times in a row.

Previously, it only worked 1 time out of 10.

It does move the USB to serial to a different location on the USB tree in System Profiler. Maybe that is important for some reason.

Hi pulsifer,

I'm glad it worked! That is a great tip to have for future customers who are experiencing problems with Macs. I look forward to seeing awesome projects from you in the future.

Humberto

On my MAC Mini with OSX 10.6.3 I have to unplug the USB every time I upload a program.

If i do not unplug the USB I get the loaded program even with the programing switch in programming mode.

Luckily my mini sits on a shelf below my monitor so the USB plugs are readily available.

Ralph

Another contributor to the problem might be that the USB is suppling 2.26 volts across the rails so essentially the MCU never turns off even though battery power is removed. There is not enough power to light the LCD. Could this be a factor?

I tried using a reset to ground button on pin one but that (or something in conjunction with trying the reset button) killed a MCU so I have not try that again.

Ralph

Hi Ralph,

That is quite strange. There is no reason why the USB Port should be able to provide power to your rails at all if the battery power is connected (and the red wire from USB cable is not connected to the rail). Only the ground wire should be connected to your rails.

Humberto

The Yellow USB wire has 3.482 volts on it.

The Green wire has 149 milivolts.

The Red wire has 4.97 volts

The Red wire is isolated, the battery is removed.

There are 2.286 volts on the rails.

I have to pull the USB every time inorder to get into programming mode.

Is 3.482 volts on the yellow wire normal/expected?

Ralph

Hi Ralph,

The yellow wire is one of the data wires, its not very surprising it is held high. Have you tried perhaps checking if removing just the yellow wire will successfully reset your chip and allow you to program? If so you can probably just setup a little switch you toggle which will be enough to let you program.

Humberto

Putting a switch on the yellow wire interrupts the USB power as expected.

Having to set three switches is a pain, but livable, is this only the MAC mini that has this problem?

Ralph

I'm having a similar problem. Kit passed the pre-programmed test perfectly, but won't respond to programming.

I'm using a Mac (Snow Leopard), plugging into USB on the computer itself -- I tried two different USB ports. Looking in the /dev directory the port right now is /dev/cu.PL2303-000014FD and that's what I have in the Makefile:

AVRDUDEFLAGS=-c avr109 -p m168 -b 115200 -P /dev/cu.PL2303-000014FD

When I do make I get

$ make
avrdude -c avr109 -p m168 -b 115200 -P /dev/cu.PL2303-000014FD -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 (8104 bytes):

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

It says it's erasing the chip and that appears to be the case; the pre-installed test program no longer runs. So it seems to be talking to the chip to that degree.

I get two bars across the LCD when I attach the battery. Switch is "up" (slid toward MCU/away from voltage regulator).

I used the battery supplied and also tried another (somewhat used) 9V battery (unfortunately I have no other new batteries here). I read 8.67V across the battery when connected and 4.97V across the rails.

The USB cable wires seem to be solidly in place.

I've tried the suggestion of unplugging USB / disconnecting battery / reconnecting battery / plugging USB but no luck with that.

Picture:

Hi doctroid,

Give powering off the USB port a try. Disconnect your battery, and carefully connect the red wire of the USB programming cable to the red rail on your breadboard. This will put the 5V of your USB port across you power rails and power the chip up. This will at least make sure your chip is running with enough power.

Are you sure the USB cable is connected directly to your computer and not a USB Hub or keyboard USB port? Have you tried plugging into a different USB port?

Humberto

Hi Humberto,

I tried the USB power suggestion. Same result.

I am using a new iMac; I've tried all three USB ports on the back of the iMac.

Oh, also, I tried the echo test mentioned in another thread. If green and yellow wires are connected I get the characters I type echoed back; if they aren't, I don't.

Not sure if it'll help, but I found with mine, once I powered the chip on in programming mode, I had to give it about 3 seconds, before I could run avrdude, otherwise it would erase, but not upload the new program. I'm not sure if it's my utilities, chip, cable, or whatever, but it always seems I have to wait a bit after powering for it to take the program.

Try varying the time between when you power the chip (using the other switch provided helps with this), and when you actually run the avrdude to program the chip.

I've pulled the avrdude line out of my Makefiles (well, commented it out), this way I can compile the code, then upload it separately, which seems to work better for me. Other then this, it functions perfectly fine.

No, I've waited much longer than 3 seconds and still no luck.

Hi doctroid,

Couple of things to try. Uninstall the version of AVRMacPack and install the latest version form their website (now called CrossPack).

If that doesn't work, try this different version of the driver from the prolific website, we link to the open source driver, but you might have more luck with that version. Let us know if you get anything.

Humberto

Hi Humberto,

Installing the newest version of CrossPack didn't change anything.

Installing the Prolific driver did! It's now working. I haven't tried switching back to the open source driver to confirm, but it's working with the Prolific driver.

Thanks!

... or rather, it worked ONCE.

OK... so far it looks like it works once, and then fails until I reboot the Mac, then it'll work once more.

Progress of a sort.

Hi doctroid,

That is indeed very odd. Do you happen to have access to another computer that you can try the hardware out on. Perhaps we are just dealing with a flaky cable here and we are blaming it on Mac unnecessarily.

Humberto

Hi Humberto,

There are a couple of other Macs in the household, no Windows or Linux machines. I haven't tried using either of them -- it'd be difficult and I want to exhaust other possibilities first.

I have tried a couple of dozen times on this Mac, sometimes restarting the Mac in between and sometimes not, sometimes unplugging the USB cable (both ends) in between and not. After a restart it doesn't always work; looks like about 50% of the time it does. However, after a restart is the only time it DOES work. If it works once and I try it again immediately (with or without manipulating the USB cable, but always cycling the battery power) it never does work the second time. I've done that about a dozen times with zero success. So restarting the Mac appears to be necessary (but not sufficient) to make it work. Plugging and unplugging the cable between tries, on the other hand, doesn't seem to affect anything.

I tried again to get some idea what is going wrong. This time I decided to focus on just the non cable issues, so I didn't touch the USB cable between tries. I rebooted the Mac 7 times, each time trying to write initialload to the MPU twice. The first 4 times I rebooted, the first write was successful and the second was unsuccessful. The following 3 times, both writes were unsuccessful.

So again the only times it works is the first time after a reboot, and it never works the second time; but again it sometimes doesn't work the first time either.

What now?

Hm, a couple hours later now and I tried loading again, without rebooting first, and it worked. Possibly it's a matter of how long it's been since the last attempt, not whether there's been a reboot?

So I waited about 20 minutes and tried again without rebooting... didn't work.

So much for that idea.

Hi

I seem to have similar connection problems on a Win Vista machine. After successfully getting the ATMEGA328p chip to work with the temperature sensor configuration earlier this year, now it won't connect.

The makefile scripts have all been configured anew [yesterday] according to the instructions in the 328p nano guide. There were some error messages for the lcd.c script [PD6 and PD7 not declared] so I changed that script to include io_328p.h

Previous .o and .hex files have been deleted in my tempsensor and libnerdkit folders.

In DOS after issuing the make command:

avrdude -c avr910 -p m328p -b 115200 -P COM2 -U flash:w:tempsensor.hex:a

Found programmer: ID =""; type =0 software version = . ; hardware version = .

device code: 0x06 = (unknown)

device code: 0xfffff86 = (unknown) also shows up

nerdkit is powered by new battery

Your help would be much appreciated

Cheers

Dirk

So have you folks given up on my case? No responses to my last couple of messages.

I just tried starting over, taking everything off the breadboard except the MPU. I re-wired the MPU connections but to keep it simple used USB power and did not connect the LCD. I checked the connections with a multimeter. It behaves exactly as before: First attempt to load initialload succeeded, then I unplugged/plugged the USB cable (thereby also cycling power) and tried loading again and it failed.

So any further ideas, or am I going to have to request a refund since something is faulty?

I'm seeing the same behavior on my Mac OS X machine. In trying to track it down today, I added a 5 second sleep to avrdude in between erasing and writing. With the sleep(5), writes seem to succeed every time, implying a timing issue between the flash erase and write.

I'll poke around with it a bit more, but I figured it was worth mentioning in case it sparked an obvious answer for anyone.

landonf, a timing issue would make sense.

Please post your MakeFile.

Thanks,

Ralph

I finally had some spare time to look into this --

I dropped my 168p into an stk500, and then verified that I could still reliably reproduce the bug reported above: Directly after erasing, writing with avrdude would timeout with a 'butterfly_recv(): programmer is not responding' error as described by the original posters above.

To verify that that merely updating the bootloader did not resolve the issue, I rebuilt and uploaded the 168 bootloader provided with the nerdkit sample code; the issue remained reproducible.

Assuming that my initial guess about a race condition was correct, I then modified the bootloader to wait for the SELFPRGEN bit to clear:

landonf@epsilon:Desktop/nerdkit-code/bootloader168> diff -u foodloader.c.orig foodloader.c
--- foodloader.c.orig   2011-01-23 12:58:23.000000000 -0500
+++ foodloader.c    2011-01-23 12:50:42.000000000 -0500
@@ -235,6 +235,11 @@
                             boot_page_erase_safe(flash_address);
                         }

+                        /* landonf:
+                         * boot_page_erase_safe() waits before erasing the page, but not after, resulting in a potential
+                         * race condition between completion of the last write and execution of the next loader command. */
+                        boot_spm_busy_wait();
+
                         uart_putc('\r');
                         break;

With this change, avrdude works reliably and I was unable to reproduce the bug.

Hi landonf,

Very interesting indeed! As-is, your patch suggests that if the computer is very quick to respond to the bootloader's premature acknowledgement that the final block erase is complete, it might be possible for it to start sending flash write commands too early.

Your sleep(5) added to avrdude between erasing and writing also suggests a Makefile-based workaround, which is to edit the Makefile and replace

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

with

avrdude ${AVRDUDEFLAGS} -e
sleep 0.1
avrdude ${AVRDUDEFLAGS} -D -U flash:w:initialload.hex:a

This separates the chip erase from the flash programming on the command line. (The "-D" flag stops avrdude from erasing again on its second run.) (The 0.1 period should be adjustable, although I'm not sure whether the OS X "sleep" implementation supports fractions of a second.)

Can anyone with this issue test out this Makefile-based workaround?

Mike

Mike I tried modifying a makefile and I get a "missing separator" error.

Here is the makefile:

# tempsensor 168
GCCFLAGS=-g -Os -Wall -mmcu=atmega168 
LINKFLAGS=-Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm
AVRDUDEFLAGS=-c avr109 -p m168 -F -b 115200 -P /dev/cu.PL2303-0000101D
//AVRDUDEFLAGS=-c avr109 -p m168 -F -b 115200 -P /dev/cu.PL2303-0000205D

ProjectName = tempsensor

LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

all:    $(ProjectName)-upload

$(ProjectName).hex: $(ProjectName).c
    make -C ../libnerdkits
    avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o $(ProjectName).o $(ProjectName).c ${LINKOBJECTS}
    avr-objcopy -j .text -O ihex $(ProjectName).o $(ProjectName).hex

$(ProjectName).ass: $(ProjectName).hex
    avr-objdump -S -d $(ProjectName).o > $(ProjectName).ass

$(ProjectName)-upload:  $(ProjectName).hex

avrdude ${AVRDUDEFLAGS} -e
sleep   0.1
avrdude ${AVRDUDEFLAGS} -D  -U  flash:w:$(ProjectName).hex:a

Ralph

Adding tabs should fix it, ie:

$(ProjectName)-upload:  $(ProjectName).hex
   avrdude ${AVRDUDEFLAGS} -e
   sleep   0.1
   avrdude ${AVRDUDEFLAGS} -D  -U  flash:w:$(ProjectName).hex:a

Thanks for replying.

Here's my dev listing:

imac01:initialload kvjohnso$ ls -la /dev | grep -i pl2303 crw-rw-rw- 1 root wheel 11, 15 Jan 28 08:12 cu.PL2303-000013FD crw-rw-rw- 1 root wheel 11, 14 Jan 28 08:12 tty.PL2303-000013FD

Here's my Makefile changes (and I added the "sleep" changes and preserved the tabs).

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/cu.PL2303-000013FD 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} -e sleep 0.1 avrdude ${AVRDUDEFLAGS} -D -U flash:w:initialload.hex:a

Here is a picture of my board. I redid all the connection again but unfortunately the initial load was erased so I can't verify my connections. I'm plugging in the USB red wire into the 5+.

Thanks,

Ken

Hey Ken --

Does it not work with the sleep 0.1? If you adjust that timeout upwards (say, sleep 1.0, or 5.0), do you have any better luck?

I had a similar problem. It seems to work reliably with the sleep change.

I have a similar problem, I must restart my laptop (Macbook Pro OS 10.6.7) everytime I want to upload new code to my controller. I tried the sleep change but no avail. This is my Makefile:

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/cu.PL2303-000013FD LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

all: led_blink-upload

led_blink.hex: led_blink.c make -C ../libnerdkits avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o led_blink.o led_blink.c ${LINKOBJECTS} avr-objcopy -j .text -O ihex led_blink.o led_blink.hex

led_blink.ass: led_blink.hex avr-objdump -S -d led_blink.o > led_blink.ass

led_blink-upload: led_blink.hex avrdude ${AVRDUDEFLAGS} -e sleep 0.1 avrdude ${AVRDUDEFLAGS} -D -U flash:w:led_blink.hex:a

(sorry it's all jumbled, it is copied word for word from your post)

This is interesting, after my last two black bars in run mode I made up a new breadboard it is running perfectly (so far).

I do not need the delay in the make file and can load and run all of the Nerdkits projects over and over. I do have a switch on

the yellow USB wire, that is necessary.

The one thing I did differently is to use 18ga solid copper wire. Using 18ga wire is not recommended for the breadboard except that the wires are inserted once and not repeatedly extracted they are dedicated to there spots.

Ralph

I have read all the comments and I get a similar result. I am running OS 10.6 (snow leopard I think). The only reliable way I can get it to work is to reboot computer each time I load the code using "Makefile". I can modify code and download it as long as I reboot after each download.

Hi Michael,

Did you try changing the makefile in the way suggested by Mike above, as well as putting the switch on the yellow wire that Ralph suggested? This issue has come up on macs before and most people that implement these fixes are able to reliably program their chips without rebooting the computer.

Humberto

I am trying the switch and the sleep delay (1s). I'm running the led_blink makefile (modified), using the Prolific driver from a couple weeks ago, on a 2009 Mac Book Pro, Lion (latest), AVR Dude.

Repeated "makes" bat about 0.600, the rest failing the problem indicated:

'=========================================================

Serenity:led_blink house$ make avrdude -c avr109 -p m168 -b 115200 -P /dev/tty.usbserial -e

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: erasing chip

avrdude done. Thank you.

sleep 1 avrdude -c avr109 -p m168 -b 115200 -P /dev/tty.usbserial -D -U flash:w:led_blink.hex:a

Connecting to programmer: . avrdude: butterfly_recv(): programmer is not responding make: *** [led_blink-upload] Error 1 Serenity:led_blink house$ '====================================================

I did find my own "reliable" solution: Go back and "make" the "temp_sensor" project (which almost always works), then "make" the "led_blink" project. The first upload always works, then it's hit or miss, usually failing/succeeding every other attempt (though sometimes I get two in a row: fail, fail or succeed, succeed). Could this be a clock/sync issue?

It sounds like you're overrunning the buffer. Slow your serial communications on your mac down on the serial port. Whatever baud rate you have (probably default at 115.2Kbps if you haven't changed it) could be simply overrunning the serial buffer of the NerdKit.

Just a thought.

BM

Thanks. I did some digging - I think my baud rate is 9600:

'========================

Serenity:dev house$ stty -f /dev/tty.usbserial

speed 9600 baud;

lflags: -icanon -isig -iexten -echo iflags: -icrnl -ixon -ixany -imaxbel -brkint oflags: -opost -onlcr -oxtabs cflags: cs8 -parenb

Serenity:dev house$ stty -f /dev/cu.usbserial

speed 9600 baud;

lflags: -icanon -isig -iexten -echo iflags: -icrnl -ixon -ixany -imaxbel -brkint oflags: -opost -onlcr -oxtabs cflags: cs8 -parenb

'==============================================

Now this is with the cable NOT hooked up to the breadboard, just the USB plugged in with bare wires on the other end. Is 9600 still too fast?

Just writing in to say that adding the sleep() call to the make file worked for me.

I am on a brand-new macbook pro 64bit running Lion. Had the initial problem with the programmer not responding.

A note to the owners of this site: There is an update to the Prolific drivers. The ones on your site did not work for me. After some research I found the 64bit version that runs on Lion:

More info/download here: http://www.prolific.com.tw/eng/downloads.asp?ID=31

Hi mouse,

Thanks for the heads up about the drivers. With the release of lion the drivers have been in flux so we hesitate to link to something that isn't totally stable yet (for some people on Lion the old drivers still work reliably). Thanks for letting us know which driver worked for you though, it will help us point people to the ones that work best.

Humberto

So is this definitely a driver issue? USB interface?

I have the latest driver from Prolific and am still having the problem (albeit intermittently).

I might get a cable/driver from FTDI - I heard they have better Mac support.

Hi jeffspc88mx,

Intermittent problem is quite odd. If you have the sleep in place and it fails on a regular basis, I'm willing to say it might just be a faulty cable. Send us an email at support <at> nerdkits and I'll have a new cable sent out to you.

Humberto

Thanks H, I have already ordered a Tripplite adapter to replace the Prolific. I did see some reviews claiming the PL-2303 was unstable, and that this was true for many brands of USB-serial adapters in general (I myself have no clue - just repeating what I read). Many such folks recommended either the Tripplite or the FTDI. I'll let you know how it works.

Naturally, after ordering the Tripplite, my Prolific cable functioned flawlessly for a whole afternoon ;(

I have an 2011 Imac running Lion. I didn't have any success with the included drivers (device wasn't showing up in /dev folder). I was able to find it with the Prolific drivers but would get the avrdude butterfly programmer error when the computer tries to write to the chip after the erase cycle.

I've since been relying on my Asus EEE Pc which works like a charm. However, since I have recently assembled my LED Array and would like it to display live data from the Imac at some point I will need to get my Nerdkits to play nicely with the Mac. I'll keep everyone posted if I find something that works.

For two weeks I have not been able to load the initial program yet. I am running OS 10.6.3 on a 2.6g Macbook. I have loaded AVRMacpac and terminal is running the compiler. I see the 2303 USB/Serial addressed in the "About this Mac" listing and am having trouble changing the address that is listed in dev listing in the Make file. Each time I open it using Text Edit or Text Wrangler it changes the file from Linux exec to a Text file. I have all permissions unlocked and have the file set to open via Terminal. I have not seen what or how the program loads to even know what I am doing is correct. I still do not understand how the initial program loads with out transferring to the compiler. Am I missing a step? None of the solutions have worked this far. As well as the suggestions from other sites. I have double checked the kit itself and every thing is working perfect. I discarded the 9v battery and use a 8.4v Hobby LiPo pack now for more time and it will run the LCD back light as well.

corvair,

I see the 2303 USB/Serial addressed in the "About this Mac" listing and am having trouble changing the address that is listed in dev listing in the Make file.

Pay no attention to "About this Mac" or Network Preferences!!

Just use ls /dev or ls /d/cu*.

I am afraid you are complicating things by believing your Mac was there to help you get things done.

Believe me if it isn't a Appple application the Mac OS is not very "friendly".

Your MakeFile should look like this:

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
AVRDUDEFLAGS=-c avr109 -p m168 -F -b 115200 -P /dev/cu.PL2303-0000101D
#AVRDUDEFLAGS=-c avr109 -p m168 -F -b 115200 -P com6
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

Ralph

Sorry Ralph,

Yes, I completed this and entered dev/cu.PL2303-00002006 in the address as described in the manual. I don't see any way of changing the address with out opening the file. As explained, the file is missing this information.

corvair,

This is a "quote":

Yes, I completed this and entered dev/cu.PL2303-00002006 in the address as described in the manual. I don't see any way of changing the address with out opening the file. As explained, the file is missing this information.

What file are you trying to open? I am confused you completed what?

But most importantly where are you at now, are things working?

Ralph

Just wanted to add that I had this problem and after upgrading to the latest drivers and Crosspack setting sleep to 1 in the Makefile did the trick for me, works every time without a problem now.

Good stuff! Please keep this thread going. It applies to a lot of AVR programming issues, espeially when in terra incognita. Here we depart from comfy (say Led blink) NerdKit newbie apps. Now, when programming in the real world, undecipherable and unexpected compiler errors inevitably pop up, difffering from what you thought you wrote in the C source file. There are a lot of ephemeral housekeeping and other issues that we never anticipated; e.g.; decaying battery supply voltage, leakage USB current to prevent complete flash memory erase, directory and makefile syntax sublities, etc. Case in point: now, I can't reprogram any "virgin" Nerdkit starters, even using exactly the same computer, download software, AVR or MS compiling, etc. Very frustrating! Arduino IDE anyone?

But did you rip everything out and re-wire your breadboard?

Ralph

Ralph, Thanks for your quick comment. The answer is yes. The problems I have now are primarily programming the lcd in the tempsensor project. Compiling the source file (with command, Notepad, or WinAVR), what I get on the lcd is "emperature F" on line 0, with a phoney (but properly-formatted and placed) temperature displayed. This is the output of a voltage divider pot to PC0. The lcd lines 1,2,3 are blank. Therefore, the ADC is cooking, but I am missing the step count output that I need for calibrating my app. Another frustrating problem is I keep getting an "invalid directory" message on paths that clearly shows the directory present from the DOS dir command. The error comes up with all compiler methods. This is not specifically a NerdKits program problem, but probably something in my XP PC. I vaguely recall from my pre-Windows DOS days that this may be some sort of System filing problem, and I think this was also mentioned somewhere in the Forum. I'm searching for that post. For example, if I rename the directory with 8-or-less characters, the invalid directory error sometimes goes away in command line DOS navigation; but,usually, it still pops up in compiler result messages. Ralph, I've followed some of your Forum programming-related posts. Good stuff! I was helped several times with your insights. Any ideas on my stuff? raildoc

I would also start over with the initialload program. Does that run correctly?

I often will go back to the initialload program to help me sort out exactly what is going wrong (as often does).

I have a XP box but I have never seen a problem like you are describing.

Well you have to use 8 or less characters on the command line I think there was a tilde (~) abbreviation that you could use.

Never use Notepad!! You will get strange errors with what Notepad does to the EOL (end of line).

Use Programmers Notepad from the AVR download or other programming editors like NotePad++.

And thank you, I really enjoy the forum in fact it was because of the forum that I made the decision to go with the Nerdkit.

Ralph

Ralph, Thanks again. I'll do what you suggest and follow-through with some other "square one" ideas. I'll let you know what happens. Yes, the NerdKits Forum is great. Nevertheless, the focus on C language gets trying. The Arduino environment is kind of a step-up to C++ which is just a step below "real" Windows programming. Either way, it still boils down to getting the hex code. Regards, raildoc

Good stuff on the makefile sleep delay! Another mystery solved. Thanks y'all.

FYI, on OSX Lion (10.7.4) this is the USB cable driver that worked for me:

http://changux.co/osx-installer-to-pl2303-serial-usb-on-osx-lio

nrotstan Tnx much! I've lost 2 NK cables already (once TX-in and once TX-out). It wasn't immediately obvious that the cable was the root problem-thus wasting precious time in diagnostics and $. As a more-robust NK replacement, I'll try your suggestion for ISP/compiler compatability.

Raildoc,

Sounds like you are having the same issue on OSX with the LCD code that I recently ran into, check out my solution in this thread and see if that works for you:

http://www.nerdkits.com/forum/thread/2118/#post18932