1. Home
  2. Embedded Programming
  3. Strange problem encountered with AVR and interrupts - 1 attachment

Strange problem encountered with AVR and interrupts - 1 attachment

Hi - I was attempting to get the two external interrupts working on an AVR. I have attached the code I wrote. My problem is that it seems it is only detecting when INT0 is pressed - but I'm not sure about this. The way I wrote it I never use the RETI statement - and I don't know if other interrupts can be called when a interrupt handler is running.

But also - another problem - so to try to reset the AVR - I just would unplug the power - then plug power back in. But for some odd reason this didn't work! This has worked just fine for me before - but for some reason after doing this - I would have to write a different piece of code to the AVR - then rewrite the program I was working on - for it to work again. If I simply rewrote the program I was working on to the AVR without first writing in a different program, the LEDs would just remain off, and it wouldn't work at all. I simply can't figure out what is going on here.

Oh - if it matters - my setup right now is that I have an AT90S8515. I am programming it with an Atmel AVR ISP. On Port B I have 8 LEDs connected to vcc. On port C I have 8 normally closed buttons connected to ground. On port D I have two normally open buttons connected to ground and to INT0 and INT1.

Also - to use the external interrupts - I set them as inputs with pull up resistors. Now I'm starting to think that might not be necessary - is it?

Lastly - is it necessary to include both the .device and the .include statements? I feel like I've seen code with just one of them.

Thanks!

-Michael

In case the attachment doesn't work properly - I'll include the code below as well:

.device AT90S8515 .include "8515def.inc"

.ORG $000

RJMP RESET RJMP INTER0 ;int0 RJMP INPUTLOOP ;int1

.ORG $00D

RESET: LDI R24, low(RAMEND) ;stack OUT SPL, R24 LDI R24, high(RAMEND) OUT SPH, R24 CLR R24 ;enable interrupts OUT MCUCR, R24 LDI R24, 0xC0 OUT GIMSK, R24 SEI CLR R24 ;set inputs and outputs and pull up resistors OUT DDRC, R24 OUT DDRD, R24 SER R24 OUT PORTC, R24 OUT PORTD, R24 OUT DDRB, R24

INPUTLOOP: IN R24, PINC ;write pinc to portb OUT PORTB, R24 RJMP INPUTLOOP

INTER0: LDI R24, 0xAA ;write 10101010 to portb OUT PORTB, R24 RJMP INTER0

begin 644 LEDBUTTONS.ASM M+F1E=FEC90E!5#DP4S@U,34*+FEN8VQU9&4@(C@U,35D968N:6YC(@H*+D]2 M1R`D,#`P"@H)4DI-4"!215-%5`T*"5)*35`@24Y415(P#0H)4DI-4"!)3E!5 M5$Q/3U`*#0HN3U)'("0P,$0*"E)%4T54.@T*"4Q$22!2,C0L(&QO=RA204U% M3D0I#0H)3U54(%-03"P@4C(T#0H)3$1)(%(R-"P@:&EG:"A204U%3D0I#0H) M3U54(%-02"P@4C(T#0H)0TQ2(%(R-`T*"4]55"!-0U5#4BP@4C(T#0H)3$1) M(%(R-"P@,'A#,`T*"4]55"!'24U32RP@4C(T#0H)4T5)"@E#3%(@4C(T#0H) M3U54($1$4D,L(%(R-`T*"4]55"!$1%)$+"!2,C0*"5-%4B!2,C0-"@E/550@ M4$]25$,L(%(R-`T*"4]55"!03U)41"P@4C(T"@E/550@1$120BP@4C(T#0H* M24Y0551,3T]0.@H)24X@4C(T+"!024Y#"@E/550@4$]25$(L(%(R-`H)4DI- M4"!)3E!55$Q/3U`-"@T*24Y415(P.@T*"4Q$22!2,C0L(#!X04$-"@E/550@

84$]25$(L(%(R-`T*"5)*35`@24Y415(P ` end
Reply to
Michael
Loading thread data ...

Interrupts are automatically disabled on entry to INTER0 Interrupt Service Routine. Since you are not enabling interrupts in the INTER0 loop, no further interrupts will be serviced. If you used the RETI instruction, flags (including interrupt status) and PC would be restored. A suggested approach would be to have a main loop that executes with interrupts enabled, with Interrupt Service Routines returning to this loop via RETI instructions.

Tanya

Reply to
tanya

"tanya" wrote in news:ccsoog$pks$ snipped-for-privacy@newshost.mot.com:

Instead of using RETI - could I simply set the global interrupt flag by executting SEI? Or is there more to it than that? Thanks,

Michael

Reply to
Michael

You need to restore the entire processor status not just the interrupt enable bit(s) to what it was before the interrupt occurred. That's why there is a separate unique instruction for returning from an interrupt as opposed to returning from a subroutine. If you don't use it then generally "Bad Things Happen".

Robert

Reply to
R Adsett

R Adsett wrote in news:95CIc.160914$ snipped-for-privacy@news01.bloor.is.net.cable.rogers.com:

LOL that's what I expected - but I thought I should check to be sure :)

But does anyone have any idea about what was going on with not being able to reset it? I tested it out today after the AVR had been unpowered for about 12 hours - and it did the same exact thing. I just don't understand. Perhaps does it remember all the states of the registers when it turns on or something?

Thanks,

Michael

Reply to
Michael

Here's just a guess. You may have a sneak path for power back to your board. Unplug *all* cables, wait a minute, and see if it's reset.

Reply to
Jim Stewart

[...]

Well, the subject _is_ the AVR. From Atmel's instruction set manual:

RETI - Return from Interrupt [...] Returns from interrupt. The return address is loaded from the STACK and the global interrupt flag is set. Note that the status register is not automatically stored when entering the interrupt routine. This must be handled by the application program. The stack pointer uses a pre-increment scheme during the RETI.

[...]

Operation: PC(15:0)

Reply to
Dave Hansen

This is a known issue with the STK500. If you have it plugged into a PC that provides a ground return, the power switch is inoperative - both positions are "on".

Reply to
Lewin A.R.W. Edwards

Figures, it would be one of the architectures that don't fit in the 'generally'. I'd still want to use the reti for symmetry, documentation and parsimony but it appears the evil of avoiding it doesn't run very deep.

Robert

Reply to
R Adsett

snipped-for-privacy@larwe.com (Lewin A.R.W. Edwards) wrote in news: snipped-for-privacy@posting.google.com:

I don't have an STK500 - I'm just using a simple 5V power supply and a AVR ISP. I guess maybe it was getting power through the avr isp? It was still connected to the computer...

-Michael

Reply to
Michael

Quite possible that it could have been getting power through the protection diodes on the I/O lines.

Reply to
Lewin A.R.W. Edwards

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.