NerdKits - electronics education for a digital generation

You are not logged in. [log in]

NEW: Learning electronics? Ask your questions on the new Electronics Questions & Answers site hosted by CircuitLab.

Support Forum » MacBook Pro OSX 10.6.8 Programming Failure!!! Any help?

March 03, 2012
by Bamftoy
Bamftoy's Avatar

First things first, I'm loving my nerdkit. I'm new to this and have successfully programmed a few projects on it.

Now to my concern. I am using a MacBook Pro with OSX 10.6.8. and have tried USB drivers from nerdkits and prolific for this concern. I have also tried removing power to the nerdkit, unplug the cable, switch to programming mode, supply power to nerdkit and reconnected the cable, but to no avail.

I'm stumped.

When I run the "make" command in terminal it will flash the nerdkit. If I make changes to the code and try to flash or try to flash another project, programming fails. I cannot flash again until I restart my computer. I'm pretty sure the USB cable is fine, because after the first flash and trying to flash a second time it will erase the programming and leave the MCU cleaned up for the new flash.

Here is what I get in terminal when the flash fails.

=========================================================== Josh:led_blink Home$ make avrdude -c avr109 -p m168 -b 115200 -P /dev/cu.usbserial -U flash:w:led_blink.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 "led_blink.hex" avrdude: input file led_blink.hex auto detected as Intel Hex avrdude: writing flash (7710 bytes):

Writing | | 0% 0.00s avrdude: butterfly_recv(): programmer is not responding make: *** [led_blink-upload] Error 1 Josh:led_blink Home$

===========================================================

Thanks for any help.. Josh

March 03, 2012
by Ralphxyz
Ralphxyz's Avatar

Chances are it is your yellow USB wire holding the mcu in a zombie state.

Unplug your USB and let it set for a while before plugging it back in!

You could also plug it back into a different USB port but then you would have to change your MakeFile.

I use a double pole switch on the yellow and green wire with a momentary contact Normally Open switch with a 10k resistor to ground on Pin 1.

Ralph

March 04, 2012
by Bamftoy
Bamftoy's Avatar

Thanks for the resopnse Ralphxyz.

I have tried unplugging the usb and letting it set for a while before pluggin it back in and this does not change anything. As for the usb port, I can use either one. I've plugged it into both and run the "ls /dev" command and it shows up as "cu.usbserial" on both ports.

I just added in the dip switch for the yellow & green wires, installed the 10k resistor (switched) to pin 1 of the MCU.
After restarting my computer, I flashed a program. Then:

-Disconnected the usb.

-Disabled swtiches for yellow/green wires.

-Disabled programming switch.

-Cycled power.
Programming successful!

Then tried to reflash.

-Enabled programming switch.

-Power up MCU.

-Momentarily connected 10k resistor on pin 1.

-Enabled yellow/green wire switches.

-Plugged in usb.

-Run the "make" command.

Programming fails with the same parameters as noted earlier.

Also tried enabling yellow/green wires and THEN momentarily connecting 10k resistor.

Once I restart the computer and try to flash, it works flawless. I'm almost wondering if there is something hanging up in the OS. Any thoughts?

Josh

March 04, 2012
by Ralphxyz
Ralphxyz's Avatar

I take it you are using Lion.

My Macmini cannot run Lion (Thanks Apple) so I really cannot help here.

Other users have reported problems but I believe they are successful.

You "should not" have to reboot if you use the USB switch plus the reset switch

so sorry this is beyond me you need a Lion user to help.

Ralph

March 04, 2012
by Bamftoy
Bamftoy's Avatar

Actually I am using Snow Leopard.. Lion is 10.7.X.

The chip will erase but no re-flash untill the reboot.

March 04, 2012
by hevans
(NerdKits Staff)

hevans's Avatar

Hi Bamftoy,

I believe you may be running into an issue that some other users have run into with Lion. Have you tried altering your Makefile to put in a sleep between the read and write cycles? Take a look at [this forum post[(http://www.nerdkits.com/forum/thread/68/) where this similar issue is discussed. About half way down on Jaunary 24th Mike suggests a fix to the Makefile you can make that might alleviate this issue.

Humberto

March 04, 2012
by Bamftoy
Bamftoy's Avatar

Excellent Humberto!!! : )

Thank you very much, that fixed it. I'm including the post from mike in hopes that this may help someone else later in the future.

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
    View Original
with

    avrdude ${AVRDUDEFLAGS} -e
    sleep 0.1
    avrdude ${AVRDUDEFLAGS} -D -U flash:w:initialload.hex:a
    View Original
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

Except where sleep is "0.1" I set it to "1.0". A little side note: I have to leave the usb unplugged at the computer end for a little bit before trying to reflash, otherwise it fails. But it now works properly.

Once again thanks for the help and patience guys!! Much appreciation on my end. I'm sure my computer thanks you as well. LOL

Post a Reply

Please log in to post a reply.

Did you know that a motor is harder to turn when its terminals are shorted together? Learn more...