Objective Development Forums

You're right, that would not explain why it does not enumerate without the jumper. That's really strange, because the firmware has no mode where USB is not operational. I would therefore suspect that this is a hardware problem, e.g. not connected supply or GND for the 74HC126 or the AVR or something...

For a keyboard, you can ignore USBRQ_HID_GET_REPORT.

The boot loader is a firmware resident in the AVR, together with your application. Not a separate device. The boot loader is in the upper most 2k of flash memory, the rest is available for your application.

You want a boot loader. See http://www.obdev.at/products/avrusb/prjprog.html for examples.

Is it possible that you used a 74LS instead of the HC type? HID mode is detected by using the AVR's internal pull-up and see whether we get high or low level. This works only if the load (the 74HC chip) has a high input impedance.

There's no particular reason for these values. This are the values I have on stock. Since I never had a problem with a wide range of capacitor values, I just use these.

Try defining USB_INITIAL_DATATOKEN to USBPID_DATA1 in usbconfig.h. I have to verify this yet, but some people say that this is the correct start condition.

And no, there's no other way to send a key twice, as far as I know. I do the same in EasyLogger.

What zener diodes did you use? Low power 3.6 V types should give enough voltage with the pull-up resistor on D- so that the device is detected. If you go below the threshold of I think 1.7 V, the host may not detect the device or see a disconnect every now and then. Another possibility is the capaci...

If you use interrupts in your main code, enclose the call to calibrateOscillator() in cli() and sei(). Since timing is measured by counting CPU cycles, no interrupts may occur.

If your firmware restarts at main(), you must have some kind of reset. This can be a brownout-reset, a watchdog reset or a spike on the supply line or RESET line which causes a hardware reset. If the device goes through a reset, it starts with USB address 0. The host must start an enumeration in ord...

Some of the AVRs have a diagram in the datasheet: supply voltage vs. maximum clock frequency. This shows a linear dependency of max clock vs. supply voltage.

The original was compiled with avr-gcc 3.4.6 on a Mac. Gcc 3 produces more efficient code in most cases.

You can turn off options in the configuration to shrink it down so that it fits into 2048 bytes. EEPROM access is usually not required.

The debug log shows that the driver sees one (or multiple) USB RESET(s), but no data received. This probably means that the interrupt routine is not called, otherwise we would at least see a received packet. If you got it working on one PC but not on the other, it's very likely a voltage level probl...

Brownout means that the supply voltage is close to the minimum operating voltage of the device. I doubt this. The long delay at the beginning of main() has nothing to do with brownout, it is there to ensure that the host sees a device reconnect at every reset so that enumeration is started. This aff...

If you get a timeout, this probably means that USB communication is unreliable (too many retries). This may happen if the USB interrupt is serviced too late, e.g. because you have another interrupt which has to finish before the USB interrupt routine can run. Please make sure that all other interrup...