I know this topic has been covered before, but I have not been able to find a solution to my particular situation. I am using an AVR ISP MKII programmer with a custom board. The board is essentially just a pro mini 3.3V with a few other components added to it. when I hook the board up I get a green light on my programmer, but when I try to program the board, I get the following error.

avrdude: usbdev_open(): did not find any USB device "usb"

I manually installed what I thought was the correct driver for the ISP.

When I look at the driver details it tells me the following list of driver files:

C:\Windows\system32\drivers\libusb0.sys " "\libusb0.dll C:\Windows\system64\libusb0.dll

That's all the relevant info I can think of at the moment. I'm at a loss. Oh, I should also add that at the bottom of the IDE window it says the following: Arduino Pro or Pro Mini (3.3V, 8MHz) w/ Atmega168 on COM4.

I was happy when I saw that thinking it meant it recognized it...but still the same error. Thanks!

do you have a bootloader on it?

Did you provide power to the board? The MKii will not power the board, it only monitors what is present and adjust its levels accordingly.

When you connect the Mkii to the PC without connecting it to the board, does it show up in Device Manager: Lib-USB Win32 Devices: AVRISP MKii

No it is not bootloaded. It's a new board.

Yes I have supplied power to the board. Yes it shows up in device manager when hooked up without the board. (with a yellow flag cause it says the driver is unsigned)

I have downloaded AVR Studio. I have heard you can compile a sketch in arduino IDE and then upload it using AVR Studio. Can anyone give me a little more direction on that? I was gonna try it to see if it's just a disagreement between arduino IDE and the MKII.

Ok, so I found this: Arduino Diecimila and the Atmega168: AVRISP MKII Frustration and Workaround
Here’s the summary.

"This is the workaround I’ve found:
Attemping to upload your code to the Arduino board does not work, but it does generate the .hex file for your code! The .hex file is saved in the “applet” folder in your sketch folder (the Arduino IDE creates an applet folder the first time you attempt to upload your sketch; each sketch has its own applet folder).

  1. Work on your code in the Arduino interface.
  2. When you are ready to upload, attempt an upload. This generates the .hex file. (You don’t need to connect the Arduino board to attempt the upload).
  3. From AVR Studio, program the Atmega168 (using the connections described above). On the “program” tab, in the “Flash” box, browse to the .hex file you just created. (You only need to do this once. The program tab points at the .hex file, so each time you update the .hex file in the previous step, just click the “Start” button in the Auto tab, or the “Program” button in the Program tab to program the device.)"

I will hopefully try this tonight and see what happens.

Also for reference: http://www.engblaze.com/tutorial-using-avr-studio-5-with-arduino-projects/

Looks like a pretty thorough explaination, though I'm not clear whether it allows using arduino libraries or not.

So I tried. I retrieved the .hex file from the hidden directory. But that’s about as far as I had success. I have never used studio before (studio 6) and was not able to figure out how to flash it to the chip. Non of the instructions I saw seemed applicable. Studio seems to recognize and agree with the MKII, at least as far as I can tell. I tried the “program device” option, and it wanted a bunch of inputs. (baud rate, fuse settings, etc.) Which I didn’t know what to tell it, so I left them in their default settings. But even from there I couldn’t figure out how to upload the file. I may try downloading Studio 4 since it seems that’s what all the instructions are for.

Any advice on how to use studio would be much appreciated. last night was the first time I touched it and I am currently completely lost. Too many buttons!

I downloaded studio 4. I think I'm making progress. I managed to get it to recognize the devise. when i try to program the devise however, i get the following output.

Getting isp parameter.. SD=0x06 .. OKOK Reading FLASH input file.. OK Setting mode and device parameters.. OK! Entering programming mode.. OK! Erasing device.. OK! Programming FLASH .. OK! Reading FLASH .. OK! FLASH contents is equal to file.. OK Leaving programming mode.. OK!

It obviously burns something to the chip cause the backlight on my display turns on. however nothing else works as it should.

My .hex file is named: HPA.cpp.hex. Does that sound right? I am using the doglcd library on this, but i don"t believe that should matter once it's compiled. Is there a way to directly load the c++ file that IDE generates?

I suppose it could be a problem that I'm using a 168A instead of a 168?

The IDE can use the mkii directly for flashing your hex files. However the procedure depends on the specific version of Arduino IDE you are using. Which one do you have installed?

So i tried that. i have ide 1.0 installed. however i get the following error message when i try to upload the sketch with the programmer.

avrdude: Version 5.11, compiled on Sep 2 2011 at 19:38:36 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "C:\Users\Suzanne\Desktop\arduino-1.0\hardware/tools/avr/etc/avrdude.conf"

Using Port : usb Using Programmer : stk500v2 avrdude: usbdev_open(): did not find any USB device "usb"

I'm not sure about the whole "using port: usb" that doesn"t seem like a correct port name to me.

OK, so if I understood it right it works with AVRStudio at least to the point that you can connect to the controller. But it does not work with Arduino 1.0 / AVRDude because it does not find the programmer. This is most likely a driver issues. However since I am working with Linux I can not verify any hints on this.

This may or may not be a solution. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=468532

Well, my daughter spilled water on my computer and now it's dead. sigh I can't look at my program at this point til I recover my hard drive. however I checked the voltage on some of my pins and it would seem that some pins are pulled up which should not be. Is there any chance switching between IDE and Sudio the pin definitions get mixed up? I know it's more likely that I made a mistake in my program, but it was running correctly on a prototype board which was supposed to be identical to my final design. I'll check my program as soon as I can access it.

Also, just to make sure, all the standard pin numbering in IDE still work when I'm programming without the bootloader, correct? Again, I realize it's more likely my mistake...I just want to look at all the possibilities.

No, switching Arduino IDE and Studio may make it impossible to compile. However it has no impact on the binaries. That is: if you compile with IDE and upload with studio the result will be the same. The same holds true for the bootloader. There is a theoretic possibility to detect the presence of a bootloader and thus to get intentionally different results. However it is very unlikely to trigger this unintentionally.

Well crap, I checked and I'm definitely on the same pin from my prototype to the final... I hope I didn't make a mistake on my board layout and connect that pin to 3.3V. Something else to check I suppose.

My layout is good, no crossed wires. I have a second populated board that I have not programmed yet. I'll power it up and make sure that pin isn't high before programming. I'll also check all the other pins and see what's going on.

Again, just to verify: Since I'm compiling in IDE it doesn't matter that I'm using libraries in my code formulated for IDE/arduino. Once it's in .hex, it's all the same... I know maybe these are silly questions, but I'm a mechE, so I'm struggling to understand what the issues are here.

Thanks for the help! my inlaws have an XP computer. I may see if IDE agrees any better with the MKII on that.



Progress! I finally got access to an xp computer. got ide installed and the libusb0.dll driver for the MKII. It did exactly the same thing as with AVR studio. I wrote a simple blink code and wha-do-ya-know...it worked!

At this point I have determined that there is a problem somehow with the lcd screen. I checked that all my pin assignments are correct. It will initialize with no problem and give me a cursor. I can even move that cursor anywhere I want. I can turn the back light on and off. However when I try to print to it, it does essentially nothing. If I tell it to print any single character (that I've tried) it prints a bunch of spaces followed by "45" followed by more spaces. It's late, I have to go to bed. but if anyone has ideas as to what the problem might be, please let me know, thanks! Goodnight world.

Interesting. It prints numbers correctly if I give it the correct base input. So somehow it's just not handling the strings I'm trying to feed it properly...hmmmm.....

It prints numbers correctly if I give it the correct base input.

Specifying the correct base is usually a prerequisite for proper behavior.

So somehow it's just not handling the strings I'm trying to feed it properly.

What isn't? What strings?

At this point I have determined that there is a problem somehow with the lcd screen.

Which LCD is that? How is it connected?

newhaven COG character display. 2x16. I am using the doglcd libraries. print command is supposed to accept a variety of character inputs. strings, char*, etc. without sepecification. I am simply feeding it this:

lcd.print("hello world!");

and it is not dealing with it properly.

I do not know what you mean by "how is it connected". would you like a diagram? It is mounted on a custom pcb which essentially acts like a 3.3v arduino mini with atmega168. it uses pins: (8, 7, 5, 6, A3, A4) as I recall. initializes properly with those pins. If you are wondering if it's a connection issue, it is rather unlikely. possible that I crossed a wire on the board, but the population is professionally done by a lady that does custom boards for the military. Most likely the problem lies elsewhere. I can post schematic and brd layout if anyone is interested in looking at them.