Objective Development Forums

I have the latest version of the driver (12 2007) but I have problems with using external interrupt different from INT0. I use ATMEGA128 and I want to use INT7.



Part of My usbconfig.h looks like this


/* ---------------------------- Hardware Config ---------------------------- */

#define USB_CFG_IOPORTNAME D
/* This is the port where the USB bus is connected. When you configure it to
* "B", the registers PORTB, PINB and DDRB will be used.
*/
#define USB_CFG_DMINUS_BIT 1
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
* This may be any bit in the port.
*/
#define USB_CFG_DPLUS_BIT 0
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
* This may be any bit in the port. Please note that D+ must also be connected
* to interrupt pin INT0!




/* ----------------------- Optional MCU Description ------------------------ */



/* The following configurations have working defaults in usbdrv.h. You

* usually don't need to set them explicitly. Only if you want to run

* the driver on a device which is not yet supported or with a compiler

* which is not fully supported (such as IAR C) or if you use a differnt

* interrupt than INT0, you may have to define some of these.

*/



#define USB_INTR_CFG EICRB // MCUCR

#define USB_INTR_CFG_SET ((1 << ISC30) | (1 << ISC31))

//#define USB_INTR_CFG_CLR 0

#define USB_INTR_ENABLE EIMSK //GIMSK

#define USB_INTR_ENABLE_BIT INT7

#define USB_INTR_PENDING EIFR

#define USB_INTR_PENDING_BIT INTF7

#define USB_INTR_VECTOR SIG_INTERRUPT7



BUT USB is not working.



Please help me.



Thank You

Maxim

Sorry:

/* ---------------------------- Hardware Config ---------------------------- */

#define USB_CFG_IOPORTNAME E
/* This is the port where the USB bus is connected. When you configure it to
* "B", the registers PORTB, PINB and DDRB will be used.
*/
#define USB_CFG_DMINUS_BIT 6
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
* This may be any bit in the port.
*/
#define USB_CFG_DPLUS_BIT 7
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
* This may be any bit in the port. Please note that D+ must also be connected
* to interrupt pin INT0!

Maxanarki wrote:Sorry:

/* ---------------------------- Hardware Config ---------------------------- */
....
* This may be any bit in the port. Please note that D+ must also be connected
* to interrupt pin INT0!

a) First of all, since the latest driver (??) / 2007-12-01 You can connect INT0 to D- also.

b) have You seen this?:



Christian, would You, please, accept this "documentation" patch?:

Sorry, problem is still unresolved...

A similar documentation patch will be in the next release. Thanks for the hint!

Regarding the original problem: We really recommend a high priority interrupt because USB processing does not tolerate any delays. INT0 is the highest priority interrupt.

Please solder a wire from INT0 to INT7 and use the default interrupt configuration. If it works with that, the error must either be in the interrupt configuration or a higher priority interrupt disturbs USB timing too much.

Some people think that interrupt priority does not matter on the AVR because every interrupt can interrupt any other interrupt as long as the global IE flag is set. However, if interrupts are disabled and more than one interrupt becomes pending during that time, the higher priority interrupt is serviced first. This is relevant for low latency / high frequency interrupts such as USB.

Ok, Christian, thank You... I understand. But... on ATMEGA128 INT0:1 are used for TWI(I2C) bus and I really need to use both buses USB and TWI. So what should I do ?
At second: now, in my schematic, the INT7 - the only interrupt what is enabled - there are not any other interrupts, so why the problem is here ?

This is just for debugging. Disable the TWI initialization, disconnect TWI SCL and wire INT7 to INT0. If the device enumerates on the USB, then you have a working example to start with. If it does not, we know that the cause is probably something else, not the interrupt.

I assume you have checked the most common pitfalls such as fuse bits, clock divider, zener diodes on D+ and D-, wiring (pull-up resistor) and so on.

I already have done this and found what all is ok. BUT when I use INT7 - no. Tomorrow I will check INT1. So first of all I would ask about tunning the .h file. Please check my first two posts for errors... Especially I am unsure about
#define USB_INTR_VECTOR SIG_INTERRUPT7
When I check the initialization for INT7 in the AVR Studio - CPU registers looks right - like in a similar manner for INT0... TWI and all other things - are turned off.

That's good. If INT0 works, it should be something simple.

Your USB configuration looks OK. Only one slight thing: You use ISC30 and ISC31 instead of ISC70 and ISC71, but that does not matter since both constant sets are defined to the same values.

If you are unsure about USB_INTR_VECTOR, run the resulting code through the disassembler (all our reference projects have a "make disasm" target). You should see whether the interrupt handler is connected to the right ISR table entry.

No way. The driver doesn't work with all interrupts other than INT0...

It's a relatively new feature that you can choose a different interrupt than INT0, older versions of AVR-USB have the interrupt service routine hardcoded to INT0. Which version of the driver do you use? In particular, is the ISR label defined as "USB_INTR_VECTOR:" in usbdrvasm*.S?

I use the latest version - 01.12.2007. U can see what u asked in its source files.

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 something similar.

I understand that and I think the same... But I have done all possible for me tunnings of the .h file and I write here because all of them are not helpful..

I expected what authors of the driver give me exact answer or if they are NOT SURE - study the situation and give exact answer.

I do not have time for learning not my so complicated code.

PEOPLE! DOES ANY BODY TRACK THE SITUATION ?

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 the parts you have analyzed. You must look somewhere else, even if it looks impossible that the bug is there.

Sorry, but without access to your hardware and firmware, I can't do anything else than guessing and giving hints.