1. Home
  2. Electronics Design
  3. Atmel 328 ext. interupts

Atmel 328 ext. interupts

sci.electronics.design Atmel 328 external interupts

I'm debugging an Atmel AVR 328 that won't generate an external #0 interupt. At present, the timer1 is generating an overflow interupt as would be expected. The input for the #0 ext. interupt (pin 4, d port #2) has been set to generate a mimic signal on another pin, which worked well. The setup for interupt 0 is: ldi areg, 2 ; external interupt #0 occurrs on fallling edge sts EICRA, areg ldi areg, 1 ; enable interupt #0 sts EIMSK, areg The possibly of a "power management" bit needing attention exists or maybe a variation between the 328 and the 168 device that I've missed.

Anyone have a suggestion?

Hul

Reply to
Hul Tytus
Loading thread data ...

Any chance you have pullups enabled on PORTD? How are you driving the pin externally?

Reply to
DemonicTubes

Pull ups are enabled on the interupt input which is driven by a npn transistor pulling the Atmel's pullup resistor and a 10k resister tied to the positive rail.

Hul

Dem> > sci.electronics.design

Reply to
Hul Tytus

Is your driving circuitry able to overcome this and drive the pin low enough to generate the interrupt? (forgive me if I am misunderstanding)

Although the 328 is more different to the 168 than their part numbers would suggest, I believe the external interrupts and associated registers are identical.

Did you have this same setup working on a 168?

Reply to
DemonicTubes

C code:

formatting link

Generated assembly for ATMega 328 (-Os size optimization):

formatting link

Reply to
bitrex

I think it might be an endianness issue, the special function registers have two address, one in IO-address-space and one in RAM-address-space. "sts" is writing the RAM-address mapping with literal "0x1" and "0x2" but bytes in RAM are organized little-endian with the LSBs on the "left" so maybe that's screwing things up.

I think there are assembler macros that are used for manipulating the special function registers, should probably use something verified-correct instead of trying to write the values directly yourself.

Reply to
bitrex

I am not terribly familiar with this chip, but did you check the USART-0 configuration? The data sheet says it uses the same pin (PD4).

Reply to
mpm

Check the addresses. the io regs are mapped into the ram with an offset of 0x20. The defines might be wrong.. I believe there's a -D flag to turn the offset on/off. and maybe some macro to convert aswell..

for sts they should be:

0x69 EICRA 0x3D EIMSK

And try not to use traditional assembler macros with gas. the local labels don't quite work.

There's other assemblers that are supposedly better (avra?)

Reply to
Johann Klammer

Thanks. A wrong address would fit the symptoms. I'll check it.

Hul

Johann Klammer wrote:

Reply to
Hul Tytus

Bingo. The EICRA address was correct but the EIMSK didn't have the 0x20 adder. Thanks again.

Hul

Johann Klammer wrote:

Reply to
Hul Tytus

Was it a user error or did they break one of their headers?

Reply to
Johann Klammer

I made the neccessary corrections to the #defines several years ago, probably when the external interupt wasn't being used. Missed one.

Hul

Johann Klammer wrote:

Reply to
Hul Tytus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.