USB device not recognized and AVRDude puts out "Yikes!" :-(

[unebonnevie]

Hi,

I built one 4NES4SNES board. Have a working ATMEGA8. I was able to flash the firmware in this github repository.

Here is the command I used to program my brand ATMEGA8.

avrdude -c usbtiny -p m8 -U lfuse:w:0x9F:m -U hfuse:w:0xC9:m -U flash:w:4nes4snes-m8.hex

When I plugged in the 4NES4SNES adapter to my WINDOWS 10 laptop, I keep getting USB Device not recognized. Please see attached images.

Then I went to your web site https://www.raphnet.net/electronique/4nes4snes/index_en.php and saw that you now have v1.5 firmware for the ATMEGA8. Ok, so I thought I would progam the new firmware. However, now my ATMEGA8 is bricked/dead, as I keep getting the below. Any tip is appreciated. Thanks!

avrdude -F -c usbtiny -p m8 -U flash:w:4nes4snes-m8-1.5.hex

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0xffffff (probably .xmega) (retrying)
avrdude: device signature = 0xffffff (probably .xmega) (retrying)
avrdude: device signature = 0xffffff (probably .xmega)
avrdude error: Yikes! Invalid device signature.
avrdude warning: expected signature for ATmega8 is 1E 93 07
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 done. Thank you.

[raphnet]

All I can provide is generic pointers to possible problems. Did you make changes to the design when building the circuit? Omitted or replaced components?

When you are attempting to reprogram the AVR, is the circuit receiving power? The AVR programmers I am familiar with do not supply power, so you would typically need to also connect your USB cable. Attempting to program an unpowered AVR typically shows errors. The incorrect device signature also happens if one or more of the wires to between the AVR and programmer are broken. I actually see this "yikes" error message often with one of my programmers where the flat cable has become intermittent.

Reasons for the USB errors are: Inverted D+ and D- lines or other incorrect wiring, circuit built with a crystal other than 12 MHz, etc. While some USB ports might be forgiving about it, errors can also happen if you omitted the zener diodes, or used different resistor values.

Another possibility: Incorrectly programmed device. Are you absolutely sure the first time you programmed the circuit there was no error? For instance, the programming command you used sets two fuses and then programs the flash right? If that crystal is missing, or the circuit does not oscillate (due to wrong capacitors for instance) then the third step (programming the flash) will fail.
When in doubt I check for a waveform at the crystal pins using an oscilloscope.

[unebonnevie]

Hi, thanks for the prompt response.

Did you make changes to the design when building the circuit? Omitted or replaced components?

Not at all. I get the gerber file to order some pieces of the board at https://github.com/gzip/eagle-usb-gamepad.

When you are attempting to reprogram the AVR, is the circuit receiving power?

Yes, absolutely. I checked to make sure VCC is ~5V with multimeter, and that the first programming was successful, when my ATMEGA8 was first programmed.

My USBTiny programmer does provide the VCC from the laptop to the board via USB's 5V VCC. I checked with the multimeter as well.

I went as well an plugged another USB cable to the adapter with also my programmer has its own cable. Same thing happens.

Reasons for the USB errors are: Inverted D+ and D- lines or other incorrect wiring, circuit built with a crystal other than 12 MHz, etc. >While some USB ports might be forgiving about it, errors can also happen if you omitted the zener diodes, or used different resistor >values.

I did continuity tests to verify that D+/D- are not crossed. 12Mhz crystal is used for the USB speed.

Another possibility: Incorrectly programmed device. Are you absolutely sure the first time you programmed the circuit there was no error? For instance, the programming command you used sets two fuses and then programs the flash right? If that crystal is missing, or the circuit does not oscillate (due to wrong capacitors for instance) then the third step (programming the flash) will fail.

It programmed successfully the first time; in fact, before programming I did a fuse read, and the ATMEGA8 that I have was already setup to use a 16Mhz external crystal previously, and the fuses were read correctly even with the 12Mhz crystal used from the adapter.

Ah...I scroll up the DOS window and the initial program output is still there.

avrdude -c usbtiny -p m8 -U lfuse:w:0x9F:m -U hfuse:w:0xC9:m -U flash:w:4nes4snes-m8.hex

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9307 (probably m8)
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 0x9F for lfuse
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lfuse ...
avrdude: 1 byte of lfuse written
avrdude: verifying lfuse memory against 0x9F
avrdude: 1 byte of lfuse verified
avrdude: reading input file 0xC9 for hfuse
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte hfuse ...
avrdude: 1 byte of hfuse written
avrdude: verifying hfuse memory against 0xC9
avrdude: 1 byte of hfuse verified
avrdude: reading input file 4nes4snes-m8.hex for flash
with 3784 bytes in 1 section within [0, 0xec7]
using 60 pages and 56 pad bytes
avrdude: writing 3784 bytes flash ...

Writing | ################################################## | 100% 6.85 s

avrdude: 3784 bytes of flash written
avrdude: verifying flash memory against 4nes4snes-m8.hex

Reading | ################################################## | 100% 6.09 s

avrdude: 3784 bytes of flash verified

avrdude done. Thank you.

When in doubt I check for a waveform at the crystal pins using an oscilloscope.

I will that a try. Thanks for the response. No problem. I'll pop in another new ATMEGA8 and see.

[unebonnevie]

Hi,

One question: I've noticed that all you projects use objdev to provide low-speed USB functionality. That is not the same as making USB functionality as a HID device, because I don't see the 4nes4snes device pops up as HID device.

[raphnet]

I used Objective Development's "v-usb" to provide low speed USB functionality. Making a HID device is just a matter of presenting the correct descriptors to the host, which I believe I do. V-USB also has examples for this.

"4nes4snes" does not pop up as a HID device? Ok, what is it poping up as then?

So far, with the information you have provided, all I see is the error "Device Descriptor Request Failed". The device descriptor is the most basic information a USB device needs to provide to the host, and the error is saying that it cannot be read. In other words: Basic communication through the USB bus is not working.

You have opened an issue in my 4nes4snes github project, which corresponds to https://www.raphnet.net/electronique/4nes4snes/index_en.php so I assumed you were using my project as-is. But you are apparently using the circuit board from:
https://github.com/gzip/eagle-usb-gamepad.

Perhaps there are differences between my original 4nes4snes project and this eagle-usb-gamepad wiring. It does say this in the firmware/ folder:

The software here is provided by raphnet.net and has been modified minimally to change the data pin(s), remove any code related to jumper settings, and change the VID/PID as requested by the original author.

So my suggestion would be: For now, try to stick with the modified eagle-usb-gamepad firmware. Get this working first. Then you might want to dig into what changes were made, by comparing schematics.

[unebonnevie]

Hi,

"4nes4snes" does not pop up as a HID device? Ok, what is it poping up as then?

Please see the 2nd image of my post #3 (comment). The 4nes4snes is seen as a serial controller category rather than a HID device category.

In other words: Basic communication through the USB bus is not working.

The device is not recognized. May it's a WINDOWS 10 thing. Maybe I can try on an Ubuntu machine.

I assumed you were using my project as-is. But you are apparently using the circuit board from:
https://github.com/gzip/eagle-usb-gamepad.

Yes, the maker of this project created his board based on your design, per his pointing to your web site.

So my suggestion would be: For now, try to stick with the modified eagle-usb-gamepad firmware. Get this working first. Then you might want to dig into what changes were made, by comparing schematics.

Yes, that is the case. I flashed his software instead first. His software is basically derived off your 1.4 release. As mentioned, this the version I flashed first. Then I saw on your web site v1.5 and wanted to flash it, but it fails flashing.

One question: In your schematic, thus his, you have the ATMEGA8's TXD (PD1) pin connected to its RXD (PD0) pin. And use the INT0 (PD2) pin to connect to the USB's D+ pin. Any particular reason not directly connect the TXD pin to the USB's D+ pin?

Thanks for the responses. I'll take a look more at yours and his schematics and firmware releases.

[raphnet]

Yes, the device is in the "Universal Serial BUS controllers" category. That's the generic place for USB devices. In particular in this case, since Windows can't even read the device descriptor, Windows does not even know the Vendor ID and Product ID, let alone the device class. So this is why it appears there.

Please try it (a board with microcontroller flashed with the derived software) on Ubuntu. If you could share the output of dmesg after connecting it I can have a look.

For your question regarding PD1 and PD0 being connected together, I do not remember. I can see it was already like this on the board I designed in 2007. I can't remember the reason at this point. It could be a design error that just stuck afterwards.

[unebonnevie]

For your question regarding PD1 and PD0 being connected together, I do not remember. I can see it was already like this on the board I designed in 2007. I can't remember the reason at this point. It could be a design error that just stuck afterwards.

I think the D+ is mostly used handshaking/notification via interrupt, the INT0 pin is used. The low speed USB implementation/design is widely used by many retro-computing with the AVR microcontrollers without the need of a USB-serial chip, thus, cost effective.

Attached is an open source project for the C64 using low speed USB. The microcontroller's TXD pin is used to control the LED instead, and INT0 pin is connected to the D+ pin on the USB, just like what you have.

Please try it (a board with microcontroller flashed with the derived software) on Ubuntu. If you could share the output of dmesg after connecting it I can have a look.

Will do as soon as I have a chance.

[unebonnevie]

Please try it (a board with microcontroller flashed with the derived software) on Ubuntu. If you could share the output of dmesg after connecting it I can have a look.

Attached are two images with sudo dmesg -W outputs for the 4nes4snes device when plugging into my Linux MInt laptop and output when plugging in my USBTiny programmer, which gets recgonized upon emeration. The 4nes4snes device does not get recognized via failed enumerations, whose address keep increasing every time I unplugged and plugged back in.