Reply by ja.....@.mail.com●February 6, 20062006-02-06
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
Reply by ja.....@.mail.com●February 6, 20062006-02-06
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
Reply by Peter Harrison●February 5, 20062006-02-05
Note that I seem to be using an older AVR-LIBC than you. Nevertheless,
the outcome should be much the same.
I think
pete
Reply by Peter Harrison●February 5, 20062006-02-05
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
Reply by Meindert Sprang●February 5, 20062006-02-05
"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
Reply by ja.....@.mail.com●February 5, 20062006-02-05
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
Reply by Peter Harrison●February 3, 20062006-02-03
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
>
Reply by Peter Harrison●February 3, 20062006-02-03
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
Reply by ja.....@.mail.com●February 3, 20062006-02-03
Reply by Meindert Sprang●February 3, 20062006-02-03
"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