Objective Development Forums

Yes, please mail me the code through http://www.obdev.at/products/avrusb/feedback.html

I might have a hardware to run it.

Maybe you have the low tech version of a semiconducter: a loose connection.

The "device not recognized" message is generated by the 1.5 k pull-up resistor alone, no processor required. To make it a recognized device, the AVR must respond on the bus.

Since you don't get any debug logs, AVR-USB does not send any data (except the disconnect at boot time, but that would be D+ and D- at 0 V). The static 3 V level must therefore come from the host. But there's no situation where you can see extended periods of high level on D+, not even a pulse seque...

During AVR reset it goes up to 3 V? How can this be?

3 or 4 V on D+ AND D- when connected to USB? You should see ~ 3V on D- and almost 0 V on D+. Both data lines at high level is an illegal state.

Still looks like a hardware problem, most likely some kind of EMI (although not "Brummschleife" in this case). I doubt that you exceed the maximum allowed current of the port with two AVRs, unless you have short-circuited some of the outputs of one of the AVRs. The supply is close to 5 V? ...

Don't know whether I understand this correctly. If it works stand-alone, but not when connected to a target which is also connected to a computer, you may have an EMI problem. This particular one is known as the German term "Brummschleife" in analog electronics. Current which flows through...

Since you don't get any data packets (or only one at most), I suspect an electrical problem. Did you measure voltage levels at D+ and D-? Is it possible that a wire in the cable is broken or that the pull-ups of the AVR are active for the I/O ports? Just guessing... AVR-USB is proven to work on the ...

OK. Then going back to your debug output from above: You see USB RESET (ff:) and one interrupt during reset (50:). You should see many more interrupts, one for each packet sent to the AVR. Since the AVR does not answer, the host should retry the packets several times and retry the entire enumeration...

Umm... These fuse values are for the ATTiny2313, if you started from PowerSwitch. The ATMega8 needs different values. You are lucky that you did not burn a fuse which makes serial programming impossible.

Please copy the fuse values from a project based on the ATMega8, e.g. RemoteSensor.

You can distinguish this log from the USB reset log because it's "ff: xx xx xx xx" (ff with four random bytes). To be sure that it's this log, you can use DBG1(0x50, NULL, 0) instead. You should see a couple of interrupts after connecting USB. When the host gives up after a few seconds, th...

I mean the handler for INT0, this is in the assembler module. Declare your own handler for INT0 and rename the function in usbdrvasm12.inc (or whatever module you use). The name is USB_INTR_VECTOR (a macro defined to the actual name). Temporarily rename it to something else to avoid linker conflicts.

Hmm... Can you verify whether an interrupt occurs at all, e.g. by replacing the interrupt routine with something which prints debug output?

The debug output you see shows that you receive USB reset. No USB data packet is received. Have you wired the interrupt correctly?

I don't think so, since there is no DBG1 or DBG2 in main(). Simply add a

DBG1(0x00, NULL, 0);

to main() so that you get debug output in any case. An always do a "make clean" before building because the Makefile has no dependencies.