Objective Development Forums

The logical conclusion would be that there is something in your interrupt handler which affects AVR-USB. You DID declare your interrupt handler with __attribute__ ((interrupt)), right? And there is no cli() in the interrupt handler or any other code which runs only if the interrupt occurs? To analyz...

The macro USB_INTR_CFG_CLR is probably never needed. If some bits must be cleared in the interrupt configuration register in order to configure the interrupt correctly, set these bits in this mask. If you create your own usbconfig.h, please start from usbdrv/usbconfig-prototype.h, not from an exampl...

In Libusb, you use the same function for all endpoints (regardless of the number), just set the endpoint number parameter differently.

You only need different functions for interrupt- or bulk transfers. Please note that bulk transfers are not allowed on low speed devices.

Sorry, but I currently have the time to add more documentation to the project...

The Tiny84 SHOULD work, but I have not yet tested it myself. Since there is no PLL clock, you need an external crystal. This makes pin assignment a bit tricky, as you already noticed. You have the following options: (1) Use Port A for D+ and D- and connect INT0 to D+, too. You lose one I/O pin with ...

The newest version is always available in the PowerSwitch example. We currently have a thread in this forum where somebody reports problem with using other interrupts than INT0, but many others had success. Please note that only INT0 has the highest priority. If you use a different interrupt, it wou...

OK, then this MUST be a problem with the interrupt routine. There are two possible causes: Either you enable an interrupt and define a service routine for another interrupt so that it jumps into nirvana when the interrupt occurs, or the interrupt rate is way too high and uses up all CPU time.

It's not sufficient to put your own sei() into the interrupt handler, you must declare it with __attribute__ ((interrupt)) so that gcc emits an sei() as the first instruction. Other than that: Did you make sure that D+ triggers an interrupt and that the interrupt line is an input with internal pull-...

This is an NPN transistor. The voltage at the base should never exceed ~ 0.7 V. If you measure 4.5 to 5 V, the transistor is not connected correctly or it's broken.

Does the interrupt handler routine set the global interrupt enable flag as its first instruction? If not and the interrupt rate is high, this could interfere with the USB interrupt.

The main() code looks OK since you use the constants from usbconfig.h. USB RESET is the condition while in the delay loop. BTW: I would recommend to increase the RESET time to 500 ms. That's not related to the interrupt problem, though. I'm afraid I'm out of ideas here, other than the general hints ...

You mentioned that you updated usbconfig.h. That's all there is to change for the driver itself. But did you also update the hardware initialization in main()? Note that the USB pins must be configured as inputs without pull-up resistor. If you do a USB RESET in main, you must also update this code.

People usually only watch the forum while they work on a project. I know that andy from thread m uses an ATMega32 where hardware interrupt 2 is used for USB. His usbconfig.h contains the following changes from the default: #define USB_CFG_DMINUS_BIT 4 #define USB_CFG_DPLUS_BIT 2 #define USB_INTR_CFG...

Other users had success with interrupts other than INT0. In fact, the code for making the interrupt vector configurable was contributed by a user who used a different interrupt. I'm therefore 100% sure that this CAN work. If you analyze a bug for days, you can be reasonably sure that it is NOT in th...

OK. But then I don't see any asymmetry in the treatment of interrupts. No matter which interrupt you use, it should be treated in the same way... The problem is very likely caused by something simple, e.g. a code portion which configures the interrupt as an output or enables the pull-up resistor or ...