AVR Silly Interrupt problem

I have timer0 set to overflow and generate an interrupt, but for
whatever reason AVR Studio doesnt seem to be doing what the ISR is
supposed to be doing! I'm attaching the code here, can you find
something that I'm missing!?

Is this a problem with the simulation in AVR Studio or with the code
itself? I haven't tested it on a device yet.

#include <avr/io.h>
#include <avr/interrupt.h>

ISR(TIMER0_COMP_vect) {

	PORTA = 0xAA;
	TCNT0 = 0x00;

}

void init_timer(void) {

	sei();

	TCCR0 = 0x0D; // Force Output Compare Off - CTC mode  - OC0
disconnected
	TCNT0 = 0x00;
	OCR0 = 0xA0;  // Overflow at 0xA0;
	TIMSK = TIMSK | 0x02 ; // Generate interrupt on Overflow

	TIFR&=~(1<<TOV0);
	TIFR&=~(1<<OCF0);

}

int main (void) {

	DDRA = 0xff; // Set Port A as output
	init_timer();
	while(1) {}
	return 0;

}

Thanks,
Jim

I'm using/simulating on an AtMega32, btw.
-Jim

"ja.......@.mail.com" <jasimpson@gmail.com> wrote in message
news:1138954574.648432.201190@z14g2000cwz.googlegroups.com...
> I have timer0 set to overflow and generate an interrupt, but for
> whatever reason AVR Studio doesnt seem to be doing what the ISR is
> supposed to be doing! I'm attaching the code here, can you find
> something that I'm missing!?

You're mixing up overflows and compares.

> Is this a problem with the simulation in AVR Studio or with the code
> itself? I haven't tested it on a device yet.
>
> #include <avr/io.h>
> #include <avr/interrupt.h>
>
> ISR(TIMER0_COMP_vect) {

So this is a handler for the Compare event.

> TIMSK = TIMSK | 0x02 ; // Generate interrupt on Overflow

While you are enabling the overflow interrupt.

Find out the difference between Compare and Overflow in the datasheet and
your the king.

Meindert

Oh crap, I wish you were right!

But that was a mistake in my commenting!
TIMSK = TIMSK | 0x02  corresponds to setting OCIE0, which enables the
Output Compare Match Interrupt
which I believe is what I'm trying to catch with ISR(TIMER0_COMP_vect).

I have checked with AVR-LIBC over and over to make sure that that is
the right name for Output compare on an AtMega32.

Thanks though. But I'd appreciate it if you could look over it one more
time. Thanks again.

"ja.......@.mail.com" <jasimpson@gmail.com> wrote in message
news:1138958981.507424.247110@g44g2000cwa.googlegroups.com...
> Oh crap, I wish you were right!
>
> But that was a mistake in my commenting!
> TIMSK = TIMSK | 0x02  corresponds to setting OCIE0, which enables the
> Output Compare Match Interrupt
> which I believe is what I'm trying to catch with ISR(TIMER0_COMP_vect).
>
> I have checked with AVR-LIBC over and over to make sure that that is
> the right name for Output compare on an AtMega32.

Ok, the code seems to be OK then. I noticed you have a prescaler value of
1024. With a compare value of 0xA0, that is 163,840 clockcycles. Are you
waiting long enough? You might want to speed up the simulation by choosing a
lower prescaler value, like no prescaling at all.

Meindert

"Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> wrote in message 
news:11u6ddu9f5rje66@corp.supernews.com...
> "ja.......@.mail.com" <jasimpson@gmail.com> wrote in message
> news:1138958981.507424.247110@g44g2000cwa.googlegroups.com...
>> Oh crap, I wish you were right!
>>
>> But that was a mistake in my commenting!
>> TIMSK = TIMSK | 0x02  corresponds to setting OCIE0, which enables the
>> Output Compare Match Interrupt
>> which I believe is what I'm trying to catch with ISR(TIMER0_COMP_vect).
>>
>> I have checked with AVR-LIBC over and over to make sure that that is
>> the right name for Output compare on an AtMega32.
>
> Ok, the code seems to be OK then. I noticed you have a prescaler value of
> 1024. With a compare value of 0xA0, that is 163,840 clockcycles. Are you
> waiting long enough? You might want to speed up the simulation by choosing 
> a
> lower prescaler value, like no prescaling at all.
>
> Meindert
>
>

Since the vectors for different AVRs are in different locations (as far as I 
remember), are you compiling for the same processor as you are simulating 
with.

I spent ages doing exactly that some time ago. Everything compiles but when 
the interrupt occurs, the wrong vector was fetched for the interrupt 
routine.

If you induce an interrupt and single step through the call, where do you 
end up?

Pete Harrison

I changed it to no prescaler and its still doing the same thing - even
after I wait for a while..

Pete,

I might be having the same problem as you did. But:

1) How do I check which processor I'm compiling for? I know that I
specified in AVR Studio that I am targeting (simulating?) for an
AtMega32.

2) I'm relatively new to AVR Studio, How do I induce an interrupt when
simulating?

Thanks again!
Jim

"ja.......@.mail.com" <jasimpson@gmail.com> wrote in message
news:1139001337.657620.305290@g47g2000cwa.googlegroups.com...
> Pete,
>
> I might be having the same problem as you did. But:
>
> 1) How do I check which processor I'm compiling for? I know that I
> specified in AVR Studio that I am targeting (simulating?) for an
> AtMega32.

Well, somewhere you must have included a processor specific include file
that defines the interruptvector number you used in the declaration of the
interrupt handler:

ISR(TIMER0_COMP_vect) {

PORTA = 0xAA;
TCNT0 = 0x00;

}

TIMER0_COMP_vect must be declared in a processor-specific file. The vector
address is processor dependent.

Meindert

Meindert,

I'm using AVR-LIBC libraries and got the vector name from:
http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

which I believe corresponds to the interrupt.h file that i've included.

-Jim