Atmel 328 ext. interupts

Apr 23, 2018 11 Replies

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



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

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

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?

C code:

formatting link

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

formatting link

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.

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).

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?)

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

Hul

Johann Klammer wrote:

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

Hul

Johann Klammer wrote:

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

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:

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required