Hey! New guy here, and I'm having a blast getting into microcontrollers for the first time. As a long time business programmer, it's really fun to get closer to the metal and start to understand how all this technology works at the silicon level.

Anyway, I breezed through the initial build, got the pre-loaded happy message just fine. Installed the USB-to-Serial driver just fine, identified the COM port (COM5). Wired up the programming header, got the LEDs lit up (both on and non-blinking when the switch is in programming mode).

Now here's where my trouble starts. First off, I'm not sure what I -should- be seeing when I turn the kit on in programming mode, but what I GET is two black bars, one each on the first and third lines of the LCD display. Is that right? If so, then all good.

Ok, but here's where the real problem is. I modified my makefile to point to COM5, just as explained in the directions. I go to do a make, get some lines showing that it's doing something, but then it just gets stuck at the "avrdude" line. (I've waited up to 10 minutes for it to do something, but nada.)

This is what I'm seeing when I go to do my MAKE command:

C:NerdKit_Projectsinitialload>make make -C ../libnerdkits make[1]: Entering directory C:/NerdKit_Projects/libnerdkits' make[1]: Nothing to be done forall'. make[1]: Leaving directory `C:/NerdKit_Projects/libnerdkits' avr-gcc -g -Os -Wall -mmcu=atmega168 -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscan f -lscanf_flt -lm -o initialload.o initialload.c ../libnerdkits/delay.o ../libne rdkits/lcd.o ../libnerdkits/uart.o avr-objcopy -j .text -O ihex initialload.o initialload.hex avrdude -c avr109 -p m168 -b 115200 -P COM5 -U flash:w:initialload.hex:a

And then it just sits there. Forever. The system I'm running it on is my work laptop, WinXP SP2, Centrino, 2GB RAM. I've got Mcafee AV & HIP installed, although just for kicks, I tried disabling HIP, although it doesn't seem to have made a difference.

Thinking that maybe I knocked a wire lose, I turned everything off and put it back into RUN mode, and was still getting the pre-loaded happy message.

One thing I did try was to disconnect power from the kit while the MAKE was stuck at the avrdude command. When I do that, the "Connecting to programmer:." message comes up, but when I power the kit back up, I get the "buffered memory access not supported error (see below):

avrdude -c avr109 -p m168 -b 115200 -P COM5 -U flash:w:initialload.hex:a

Connecting to programmer: . Found programmer: Id = "bpY"; type = L Software Version = ?.?; Hardware Version = F.D avrdude: error: buffered memory access not supported. Maybe it isn't a butterfly/AVR109 but a AVR910 device? make: *** [initialload-upload] Error 1

Anyone have any tips?

Thanks in advance!

Matt

UPDATE: Ok, now I get the black bars regardless of whether I'm in programming mode or not, and I can't get the happy message any more. Does that mean I did a partial flash?

Dang... Now I'm worried that I somehow blew up my MCU. :(

Oh, and just to pre-emptively respond to this question--I check my battery's voltage while under load, and it's still holding at 8.5v, so I don't think that's the issue.

Hi gzsfrk,

Your problem is a bit puzzling, I think your best bet is to email us if you can include a close up picture of your setup I'm sure we can get to the bottom of the bottom of it quickly.

Humberto

Thanks for the reply, Humberto! I think what I'm going to do is disassemble everything and then try reassembling it, making sure that all connections are indeed solid.

But can you verify for me one thing--when the MCU is in programming mode (pin 14 is grounded), should the LCD screen show the two black bars? Or should it look differently (blank, etc.)?

Thanks again for the quick response!

Matt

Still stuck--email sent with photos. <sigh> I hope it's not something completely stupid on my part. (Although if I have to choose between "stupid and easy to fix" or "not stupid but unsure how to fix", I guess I'll go with stupid and fixable. :)

Hi gzsfrk, the exact same problem is happening to me. I think the reason we get black bars is because the LCD is powered on but nothing is being sent to it because the flash on the MCU is erased. I don't think anything is wrong with the MCU because it has a fuse set to prevent overwriting of the bootloader. Hopefully we can get this straightened out. Please let me know if you arrive at a solution.

Below is the output from the terminal just before it stopped working:

prometeus:initialload brian$ make
avrdude -c avr109 -p m168 -b 115200 -P /dev/cu.PL2303-000033FD -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.00s
avrdude: butterfly_recv(): programmer is not responding

Hey Brian! Sorry to hear you're having a similiar problem.

I do have a small update. Still not good news, but at least something different is happening now.

I completely disassembled everything in my kit (including removing the MCU from the breadboard), made sure I didn't have any small bits of wire shorting across any connectors, then rebuilt it very carefully.

Hooked up the power without it being in programming mode, and still get the black bars (which wasn't really a surprise). But this time, when I hooked it up to the programming header and went to do a MAKE, it actually started trying the "Connecting to programmer" step, although it would just keep trying and trying for awhile before finally giving me the "buffered memory access not supported" error. But on the bright side, it was pulling back the proper Programmer Id ("FDL v02"). So SOMETHING is working now where it wasn't before.

Hopefully one of the NerdKits guys can give some guidance on where to go from here.

Humberto sent me an email; he suspects a problem with my USB-Serial setup. I still get "programmer is not responding." A friend of mine has an older nerdkit, and I might be able to try out his serial adapter with another computer this weekend to see if it makes a difference. Here's to getting this thing up and running!

Have you tried a lower COM port? I was using COM17 (I think it was 17) & after I moved it to COM2, everything worked great.

I've used COM5 on my XP laptop and COM4 on my Vista laptop, and neither of them seems to be working. I read that there's a bug in the Windows driver that won't let you use a COM port higher than COM5. But since mine wasn't allocated that high, I don't imagine that was the problem.

Hey, if I run the make command as root I seem to get a sort-of response!

prometeus:initialload brian$ sudo make
avrdude -c avr109 -p m168 -b 115200 -P /dev/cu.PL2303-0000101D -U flash:w:initialload.hex:a

Connecting to programmer: .
Found programmer: Id = ""; type = 
    Software Version = .; Hardware Version = .
avrdude: error: buffered memory access not supported. Maybe it isn't
a butterfly/AVR109 but a AVR910 device?
make: *** [initialload-upload] Error 1

Interesting...

Update: Getting a new USB-Ser adapter. Will give it a try as soon as I receive it and report back.

Still no luck... Tried pulling out all the wires and components and following all the steps in the PDF very carefully.

Anyone have any ideas?

Just got it working on another computer (24" iMac) and was able to flash the chip twice! Not sure what I did, though.

Glad to hear you got yours working, Brian. Mine is likewise working now, but in my case, there was a small solder bridge connecting pins 12 & 13 of the serial board's MCU that was not supposed to be there. I heated up my soldering iron and removed it, and lo and behold! It worked perfectly, flashing the chip without hesitation the first time I tried to run it.

To anyone else having this problem, be sure to take very clear and close pictures of both the front and back of the serial port adapter and send it to the NerdKits support email. They are very responsive and provided me with excellent help.

I had a similar issue.. changing the USB adapter to another one solved the problem.

Best wishes Sascha

Same Here was getting the error BAD Found programmer: Id = "ï??????"; type = ? Software Version = ?.?; No Hardware Version given.

it was different pins but they where slightly touching each other.

now it works!

are these adapters manually done?

Would someone answer the question as to whether or not you get black bars on the LED? I just got my header installed and powered it on, got black bars, and turned it off?

THIS IS IMPORTANT FOR WE WHO ARE NOOBs :P

If I flip the switch back so it's no longer in programming mode, it gives me the happy original greeting. I haven't even tried to flash it yet. I just came here looking for answers.

One suggestion for flashing is this: Your serial-usb device might default to 9600 baud. This is irregardless of whether you set 115.2Kbps elsewhere-- that just throws data out the computer at 115.2Kbps while the serial/usb device is set at 9600-- the MCU won't get hardling anything valid after the first few characters.

I'm running XP, and saw the 9600bps setting in the Device Manager when checking to see what COM port (I'm on COM 4) it was installed on.

I'm checking the traces of the header device now...

@BobaMoset. When the device is in programming mode you are supposed to see black bars on the LCD. Since the bootloader doesn't send any data to the LCD, it has no idea what to display. Go ahead and try to flash it see if it works!

Humberto

@hevans. Thank you. I realized that after I posted-- sorry to bother :P I got interrupted by work, so I'm in process of trying to flash it now :P

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.

Same problem as Brian. Somehow all the handshaking works right up until sending the flash image. Here's the verbose debug output:

...
avrdude: erasing chip
avrdude: Send: e [65] 
avrdude: Recv: . [0d] 
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: Send: A [41] . [00] . [00] 
avrdude: Recv: . [0d] 
avrdude: Send: B [42] . [00] . [80] F [46] . [0c] . [94] . [06] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] . [0c] . [94] # [23] . [01] n [6e] a [61] n [6e] . [00] i [69] n [6e] f [66] . [00] c [63] d [64] i [69] n [6e] o [6f] p [70] s [73] u [75] x [78] X [58] [ [5b] e [65] f [66] g [67] E [45] F [46] 
avrdude: ser_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding 
make: *** [initialload-upload] Error 1

It looks to me as if the first block of 128 is sent, and that either the return message (should be [0d]) is dropped or never sent.

Boot loader bug? Seems odd.

Paul

I managed to get it to flash once - just came back to it after a couple of hours and it just worked. But the next attempts were all as failed as all the first :-(

Paul

I "had" just received the serial adapter you guy's got, and i tried all the fixes on linux AND windows I knew when i connected it straight to the serial on the back of the linux machine and it came back with the same error your talking about, i knew it was had. So the staff sent me the "new" NK003USB which i got today and this "thing" is pure JUNK! Nothing compiles on either machine. Man are these guy's going to get a smashing. This one is obviously faulty too, i'm in Alberta and when i have to order these "things" from Texas! is bad enough, I think i might as well just drop these guy's, this "thing" and it's directions/pictures is completely unprofessional.

Farmerjoe,

We are working with you solve these problems you are having with the USB-Ser adapter. If you send pictures of yoursetup to support <at> nerdkits, we will gladly help you figure out what is going on.

Humberto

Hi,

I am having a similar problem on my Mac using OS 10.6. I COULD burn it once, but from then on (minutes later) I always get "programmer is not responding".

I have tried unplugging the usb & battery in different combinations, however the result is the same.

Any suggestions?

Thanks!

Weird; just unplugging and replugging the usb/ser's connection to the computer works for me

Anyone else have any advice?

I don't run OSX but I get that error when I forget to flip the switch to put the chip in programming mode. Maybe you have a loose connection between pin 14 and your switch (or the switch and ground)?

Hi dak,

If you have tried all these suggestions there might be something damaged in your kit. Send us some pictures of your setup, along with screenshots of the errors you are getting to support <at> nerdkits, we will try to isolate the faulty piece, and see if we can get you up and running.

Humberto

Humerto,

So, I left the NK for a day & went back connected it up & it burned successfully... again, only the first time. This would suggest to me that the Mac or butterfly gets into some state that clears only after a period of time (though I'll try it again tomorrow & see if I get the same results). The last time I tried 'make' it never came back.

[Btw, when I first plugged in the NK via USB, the OS asked if I wanted to configure it as a modem port... you might want to update your manual to mention this. I cancelled out of this & it shows up in the network config panel as an unconfigured usb-serial controller. <Mac OS 10.6>]

Is this possible, or do you have another suggestion?

How should the lights on the serial card be configured when it's plugged in? When trying to write to the PRAM? I see one light on solid (on the NK side), the other one lights up periodically.

Thanks!

Dak

Hi Dak,

Are you getting this error consistently after the first time you flash after a reboot of your computer?

I'm no Mac expert, but perhaps you can try unloading and reloading the driver. I think the command is something like the following:

sudo kextunload /System/Library/Extensions/ProlificUsbSerial.kext

to unload, and

sudo kextload -v /System/Library/Extensions/ProlificUsbSerial.kext

to reload. See if that gives it the right kick it needs.

Humberto

Same error here:

"make.exe" all avrdude -c avr109 -p m168 -b 115200 -P COM4 -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 (7808 bytes):

Writing | avrdude: error: programmer did not respond to command: write block make.exe: *** [initialload-upload] Error 1

Process Exit Code: 2 Time Taken: 00:12

Hi Pikoro,

The most common cause of this problem on windows is a low battery, or a loose wire. Make sure all your wires are nice and snug in the breadboard. If you have a multimeter around, check the voltage at your battery, make sure it is very close to 9V. Check the voltage between the +5 and GND rails, make sure that is very close to 5V. If you do not have a multimeter, just try a fresh battery.

If it is still failing, go ahead and send us an email to support <at> nerdkits, if you can include pictures of your setup, as well as which OS you are running, it would be helpful. We will try to narrow down what part is the one giving you problems and figure out how to fix it.

Humberto

Well, turns out that running make from the programmer's notepad was the problem. Running make from the command line worked like a charm.

Thanks :)

That's interesting, I use programmers notepad almost exclusively and have not seen that problem using the programming interfaces that came with my kit (2 piece setup - USB > serial converter through the inverter IC adapter). Do you have the 2Pc "programmer" setup (USB > Serial adapter with a small inverter circuit with 2 LEDs) or the current 1Pc (USB > Serial cable that goes out to the wires w/o an external board) ?

The reason I ask, is I did (and still do on occasion) get errors programming when using the serial port on my pc straight to the external inverter board without the use of the USB > Serial adapter.

The External dongle board while inverting the TTL signal from the uC does not raise the voltage to standard RS-232C levels which typically if I'm not mistaken are in the +/-10 to +/-15 volt range. The USB > Serial adapter doesn't care about the lower voltage however, some PC serial ports may especially if your cabling is long or not shielded well. This can lead to odd errors where sometimes communications work and others they don't.

I get 100% communications when using the USB > Serial dongle thru the board.

Now if you have the current adapter, you can ignore all the above as that most likely is expecting the TTL input of the chip and will work well with the 5v logic serial communications.

Rick

I just received my NerdKit today and put it together this evening. Programming it from my Mac did not work, with avrdude not communicating at all and then saying that butterfly_recv failed, and I found this thread.

I plugged the USB cable into the front port of my Mac instead of my desktop USB hub, updated the /dev name in the Makefile, and it worked like a charm. Hope that helps anyone else having a similar trouble.

THANK YOU! I was having the same problem!

REVIEW ON OLDER: Actually it didn't work.

avrdude: error: programmer did not respond to command: write block make.exe:

this can also come when the avrdude tries to write a total of 15-16kb (which is near the limit)

(Background: Engineer... but a Noobie to PICs) So I too got an Error 1.... then after several re-attempts... I removed and re-inserted the USB cable to the computer... Got a 'ding - dong' sound ... and it worked...

Hope this helps..

JF (Foxegg)

I found this thread after having the same problem too. I'm on a mac (10.4). Flashing worked the first couple of times. One of the replies mentioned unplugging the usb cable and plugging it back in. That did it for me :)

I'm on a mac and had the same problem. I overcame it by pushing down on every wire and, perhaps most importantly, by trying every available usb connection. The last one available did the trick.

my name is sergio .is there any one who can help me .i am new to all this i got my nerdkits not to long ago i need help from step 9b though 11 i have ledarray kit

Hi Sergio,

There are plenty of people here willing to help. Your best bet is to start a new thread, and describe the problem you are having in as much detail as possible. Pointing us to which steps are giving you problems is a start, but it is much better if we know why they are giving you problems, what about the step is confusing you?

If you post pictures of your current setup, and screenshots of the problem it would also help us help you.

Humberto

1)begins with AVRDUDEFLAGS. At the end you need to change “/dev/ttyUSB0” to “COM5” or whatever you saw in the previous steps. the above step is done what do i do after making the change to com5 ?

Compile and Install your first program i am confuse about it this part what file do i compile and how do you compile the program ?

Open up the command line and navigate to the folder with the code in it. where is the command line ? you mean the one on the python 2.6 ?

Now that you have seen the code, we need to use the command line to program the chip. 2. Open up the command line and navigate to the folder with the code in it. 3. List the files in the directory and make sure there is a file called Makefile. 4. Type “make” and press enter to run the “make” command. This command will look for the Makefile and use it to compile all the code, and will then program the chip using the binary files. (If you want to learn more about Makefiles, go to http://www.eng.hawaii.edu/Tutor/Make/ .) 5. You should see an output on the command line telling you what the program is doing. 6. If all goes well, one of the last lines should read “avrdude: --- bytes of flash verified” where --- is some number. This means that avrdude has successfully written the program onto the chip, and read it

all these are a little confusing is there away you can give me step by step instruction

Hi Sergio,

I just sent you an email with a document that should help you a little. The most important thing is to take a step back and slow down. Figure out one step before you move on to the next, and remember all this is really hard! Learn form the process and you will have lots of fun putting it all together.

Humberto

hi which communacation port do i select if com2 com3 com4 com5 and com6 are in use

is the gcc the same thing as the gnu

Sergio, simple unplug one (or more ) of the devices using your Com ports!

As you are just starting you only "should" be doing one thing at a time so get rid of the distractions (other com devices).

You will not be using/needing all of them while you learn microprocessor programing and electronics.

gcc I believe is "Gnu C Compiler" the gcc compiler is made by the GNU open source group.

Once you are finished working with the Nerdkit simple plug back in your other Serial devices!

Ralph

thanks ralph very helpful

hi my next question is the follow 1 i want you to take me from which code do i download because there 2 of them ? 2 what path name do i save it into ? 3 why because any time i go "C:>cd code" it tells me that the system cannot find the path specified

i am trying to load my first program and i need help thanks

HOME KITS TUTORIALS PROJECTS ABOUT STORE FORUMS MEMBERS
You are logged in as igondjo32. [log out] Available Downloads

USB NerdKit (NK003USB)

This is for our new USB NerdKit with a 20x4 LCD and single-piece USB programming cable.

•The NerdKits Guide -- kit 5317n2rx7v8cxt5rn8f6 (color, BW) •NerdKits *Sample Source Code* •Datasheets: ◦7805 (Voltage Regulator) ◦Atmel ATmega168 (Microcontroller) ◦Atmel ATmega328P (Microcontroller) ◦HD44780 (LCD Controller) ◦LM34 (Temperature Sensor) •Drivers: ◦PL2303 USB-serial drivers: Windows / Mac OS X / Linux •Programming Environments: ◦WinAVR for Windows ◦AVRMacPack for Mac OS X ◦avr-libc package for Ubuntu Linux (only necessary if you have an older version) •Extra Content: ◦ATmega328P Upgrade Nano-Guide -- kit 5317n2rx7v8cxt5rn8f6 ◦Schematics for "The NerdKits Guide" Projects -- kit 5317n2rx7v8cxt5rn8f6 * This is for the controller chip on the LCD module, so the pins won't match the 16-pin LCD module itself. The "Interfacing to the MPU" section is most relevant for talking to the LCD.

LED Array Kit (NKLEDARRAY001)

T which source code

his is for our LED Array Kit, featuring a 5x24 pixel LED array.

•NerdKits LED Array Guide -- kit 5059n9b934496u9p7u4c (color, BW) •*Source Code**** •Python Scripting Environment: ◦Windows: Python, python-serial, pygame (optional) ◦Mac OS X: python-serial ◦Linux: (Use your package manager to install python-serial) Also see our original LED Array video tutorial.

it is hard i have tried hard to program my board but it said now congratulation your usb nerdkits is alive what is that suppose to mean some one ?

is anyone there

It means it's working! The wiring is right, the USB/COM configuration is right, the program compiled and uploaded to the chip, and it ran correctly.

Sergio, start a new thread you hijacked this thread and totally changed the subject I think if you want a answer you need to start a new thread.

Ralph

hi you guys will benefit from me because i am a bigginer and i am learning as i go verry fast i am highly determine guy. here what i just found for the next beginner if he or she face this probleme you code once you download it it needs to be extracted then when you open it in the it should be C:commdocuments and settings>cd.. C:>cd code C:codecd code C:codecode than C:codecodecd initialload C:codecodeinitialload>ls cd code has to be twice because when i downloaded it i had to extract the file which made it code code. i hope i make some sence out of it

hi is any one knows how to erease the previous program i had on my chip so i can rewrite another one

Hi igondjo32,

As it was noted in another thread that you posted this question in. The old program gets overridden when you write a new program to your chip.

Humberto

HEVANS RALPH GUYS YOU ARE GREAT EVEN WHEN I WAS LOST YOU CAME THROUGHT THANKS AGAIN MY PROJECT IS DONE MY LEDARRAY WORKS

i am trying to have my diplay running none stop until i decide to how do i create such a loop

I struggled with the same error and failure to write. For me it turned out be my wire from +5 to pin 1. I noticed when I was re-re-rechecking my usb hookup on the board that there was no wire from +5 to pin 1. I remembered doing it and wondered how it could have fallen out. Then I noticed a wire from +5 to pin 15. I corrected the wiring and the problem was solved.

Hi everybody, I tried to unplugged everything and then replugged,but I still get the same result. The following is the error i got when i load the first program to the chip:

Found programmer: Id = "Huh? Go"; type = ' .S Software Version = t. ; Hardware Version = ' .S avrdude: error: buffered memory access not supported. Maybe it isn't a butterfly/AVR109 but a AVR910 device? make: *** [initialload-upload] Error 1

I found a post on May 04, 2009 by gzsfrk earlier on this discussion, but it seems like he found the solution. Any suggestions would be great.

Tou

Hi Tou,

This error definitely means that your MCU is not in programming mode. Make sure your programming switch is installed correctly, and in the right position, then reset power to the chip. You should see two black bars on the LCD when the chip is in programming mode.

Humberto

Hey guys, I just got the same problem, but I've fixed after struggling for about 30 minutes. I made 2 mistakes: 1, I forgot to GROUND breadboard 25 ! I'd like to comment to the next version of Nerdkits manual that this part needs to be highlighted! 2, the COM port actually keeps changing once you unplug then plug it back into the PC. make sure that you get the correct COM port# !

A great hint is that, once your kit is in programmable mode, you should see 2 dark blocks just in front of the "Congratulations!".

Hope it helps.

Having exact same problem as Pikoro (Dec 11, 2009). Using Programmer's Notepad on Windows 7, and COM5. Everything configured fine on breadboard, initial happy program worked, and the first time that I downloaded the new code to the MCU all worked great. Code downloaded, and new text came up on LCD just fine. Since then, it will not do it again, and my message is exactly the same one that Pikoro described (except I'm on COM5). AVRDude reading great, but then AVRDude writing error that programmer did not respond to write block make.exe, with initialload-upload error 1. Process Exit Code: 2 Time Taken: 00:12

Haven't tried configuring things to run Make from the command line, which he said fixed his problem. But then why shouldn't the existing code that worked the first time work a second time? Hmmm.

Messed with it for last hour with no success, and calling it a night. But it's definitely a repeatable problem.

Figured it out. To test that I was getting new code uploaded to the MCU, I had changed the text being written on the LCD. One line was 21 chars instead of 20. As soon as I fixed it to only 20 chars, everything works fine. Doh! Have downloaded different text a handful of times now without any issues.

I seem to be having the same problem some others are having. Unfortunately none of the responses I saw worked for me. I have a laptop with win7 I have made different changes to the location of the make and initialload file to see if it made a difference. I have the make file in the same folder as the program which seems to be what the error message is saying is wrong. But nothing seems to be working. I've even tried changing the COM port number but that didn't make any difference either. Any help will be greatly appreciated

Well I managed to figure something out but still don't think it's right. I was able to upload the initialload. I had extracted the download from nerdkits to one loactiona nd then moved it. I did move it all so I thought that should not have any problems but after much anguish I decided to delete what I had moved and re extract the zip file to where I wanted it. But I still don;t think something is right. I changed the text output to the LCD in the code but the LCD still says the same thing. And I got an error 1 at the end of the make.

Last post my imbed forced my text into one long line so this time I will post my imbed image in the next post. Thanks Steve

Well even my last post got strung out into a long line.

Maybe have to use Shift-Enter to force readable text.

Hi Steve35897,

If you are still having problems here is how to use the -F override:

AVRDUDEFLAGS=-c avr109 -p m168 -F -b 115200 -P /dev/cu.PL2303-0000105D #USB3

Try that.

Ralph

What does the -F override do?

I think I figured out my problems. I originally unzipped the nerdkits download to one folder but quickly realized

that was alot of typing in the command prompt window when trying to "make" it so I cut and pasted the whole

"nerdkits" folder so I thought it should be OK. Somewhere in this forum I read a suggestion to delete the

download and re-extract. After I did that my original problem is gone. Then I had some other learning to do

such as the .c at the end of the program name. Somehow I thought that when I edited and saved the program in the

Programmer's Notepad that was automatcally done for me.

What does the -F override do?

Hi Steve, look at your screen shot from 4 days ago.

Notice the forth and third line from the bottom:

avrdude:   Device signature = 0x1E9406 
avrdude:   Expected signature for ATMEGA328p is 1E 95 0F
           double check the chip, or use -F to override the check.

So the -F is just an override of the signature check.

Un zipping the download often causes problems (to much thinking).

Hope you get it running, if not let us know :-)

Ralph

Dak's solution resolved the issue I was seeing on my Mac, latest AVR, OSX 10.7.5.

sudo kextunload /System/Library/Extensions/ProlificUsbSerial.kext
sudo kextload -v /System/Library/Extensions/ProlificUsbSerial.kext
run make <!--- fails first time
run make <!--- works

make change to program and repeat.

Crazy that you have to unload and reload serial driver every time but at least it works now.