AVR Silly Interrupt problem

ja.......@.mail.com wrote:
> 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.
> 

I am not familiar with WinAVR - sorry

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

arrange things so that you are single-stepping in the compiled code 
while viewing the disassembled version. In the left pane, be sure you 
are looking at the processor IO.

Run the code to the endless loop and start to single-step. Now you can 
manually set the overflow/interrupt flags in the IO view. Step your code 
again and the interrupt will occur. There are more sophisticated ways 
but that will work (I expect).

Pete

ja.......@.mail.com wrote:
> 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.
> 

Right - got it now

Your project should have a MakeFile. If not, you can set the processor 
on the compiler command line but I really don't know what you have to 
do. You will have to ask someone else how all that works sorry.

In the makefile will be some lines like this:

# MCU name32
MCU= atmega32
# speed required by avr/delay.h
F_CPU= 8000000


That is where the compiler gets to find out which processor you are using.

Pete

> 

Pete,

I single stepped and forced an interrupt in the I/O view like you
mentioned and something interesting happens!!
Instead of going to the ISR for the corresponding interrupt (Timer0
compare match), the next step takes to me to "int main (void) {" !!!
Which means that the system is getting reset by the interrupt
everytime!?

And the Timer seems to be running fine. Cause if I let the code Auto
Step, I can see TCNT0 incrementing till OCR0 (0xA0) and the program
being reset-ed.

Which should make you think that the vector name I've specified is not
correct. Right?
But I'm using the same vector name that AVR-LIBC tells me to and the
same code!!!!

What do you think is going on?

Oh, and I checked the Makefile and the MCU = atmega32 and I'm
simulating for atmega32 too.

Do you think I should test it in hardware now instead of wasting time
simulating?

Thanks,
Jim

"ja.......@.mail.com" <jasimpson@gmail.com> wrote in message
news:1139114242.007309.284080@f14g2000cwb.googlegroups.com...
> Pete,
>
> I single stepped and forced an interrupt in the I/O view like you
> mentioned and something interesting happens!!
> Instead of going to the ISR for the corresponding interrupt (Timer0
> compare match), the next step takes to me to "int main (void) {" !!!
> Which means that the system is getting reset by the interrupt
> everytime!?
>
> And the Timer seems to be running fine. Cause if I let the code Auto
> Step, I can see TCNT0 incrementing till OCR0 (0xA0) and the program
> being reset-ed.
>
> Which should make you think that the vector name I've specified is not
> correct. Right?
> But I'm using the same vector name that AVR-LIBC tells me to and the
> same code!!!!

Have you actually CHECKED if the vector is the right one? Look at the
address of the code and compare it with the vector list in the datasheet.

> What do you think is going on?
>
> Oh, and I checked the Makefile and the MCU = atmega32 and I'm
> simulating for atmega32 too.
>
> Do you think I should test it in hardware now instead of wasting time
> simulating?
No, the simulator is perfectly capable of simulating timer interrupts. I do
it too.

Meindert

ja.......@.mail.com wrote:
> Pete,
> 
> I single stepped and forced an interrupt in the I/O view like you
> mentioned and something interesting happens!!
> Instead of going to the ISR for the corresponding interrupt (Timer0
> compare match), the next step takes to me to "int main (void) {" !!!
> Which means that the system is getting reset by the interrupt
> everytime!?
> 
> And the Timer seems to be running fine. Cause if I let the code Auto
> Step, I can see TCNT0 incrementing till OCR0 (0xA0) and the program
> being reset-ed.
> 
> Which should make you think that the vector name I've specified is not
> correct. Right?
> But I'm using the same vector name that AVR-LIBC tells me to and the
> same code!!!!
> 
> What do you think is going on?
> 
> Oh, and I checked the Makefile and the MCU = atmega32 and I'm
> simulating for atmega32 too.
> 
> Do you think I should test it in hardware now instead of wasting time
> simulating?
> 
> Thanks,
> Jim
> 
I don't know what compiler or environment you are using but, for this 
program to work for me ( I use WinAVR - GCC 3.4.3 ), the first few lines 
or the source file need to look like this:

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

//ISR(TIMER0_COMP_vect)
SIGNAL(SIG_OUTPUT_COMPARE0)
{
    PORTA = 0xAA;
    TCNT0 = 0x00;
}

I have no ISR macro defined and the SIGNAL macro needs the signal.h file 
to be included. Without that, there are compiler errors. I would expect 
you to be getting those errors as well. They may look like warnings only 
but they are fatal to the execution of your program. You are asking the 
compiler to create a function called ISR. It does not know that it is 
meant to be an interrupt service function so does not put an entry into 
the interrupt vector table. Consequently, the table is probably full of 
zeros causing the processor to jump to address zero when the interrupt 
occurs. This is functionally the same as a soft reset.

Pete

Note that I seem to be using an older AVR-LIBC than you. Nevertheless, 
the outcome should be much the same.

I think

pete

I'm using WinAVR - AVR GCC 3.4.3
and AVR-LIBC 1.2.3

and they recommend using ISR() over SIGNAL() or INTERRUPT()..

But I'm downloading the latest version of WinAVR cause I have a feeling
that 1.2.3 is probably too old of an AVR-LIBC version.

-Jim

OMG IT FINALLY WORKS!!!

Yes, I was using an old version of AVR-LIBC which had not started
supporting ISR() yet.

I downloaded the latest version 1.4.3 and it fixed the problem!

Thanks a lot Mike and Pete for walking me through this weird problem.

-Jim