volatile variable not updated by ISR

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to update a variable (led) in an ISR but the change is not reflected in the main code. I did declare it volatile. Any suggestions?

More details:
- I'm using optimization: -0s.
- I tried the other optimizations and they didn't work either.
- The interrupt handler is getting called.

Here's my code:

// crystal frequency in Hz
#define F_CPU 8000000

#include
#include
#include

volatile uint8_t led;

ISR(INT7_vect)
{
led++;
}

int main( void )
{
DDRB = 0xFF; // Set PORTB as output (LEDs)
PORTE = 0xFF;
DDRE = 0x00; // Set PORTE as inputs

// interrupt setup code
sei(); // Enable interrupts
EICRB = 0xC0; // Interrupt on rising edge
EIMSK = 0x80; // Enable external interrupt 7
EIFR = 0x80;

led = 1;

while (1) { // Loop forever
PORTB = ~led; // Invert the output
}

return 1;
}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What AVR model are you using?

How do you know the ISR is getting called?

Why do you say it isn't updated?

Is it connected to a button? Buttons bounce.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using:
AVR Studio 4.17
Atmega128

I know the ISR is getting called because I put a delay subroutine in the ISR (not shown in code above) and tested that led variable was being updated by outputting the results to LEDs. Yes, it's connected to a button (for now), but button bouncing is not the problem (i.e., see above comment).

Thanks for any help here.

Here's my ISR test code (replaces ISR code in my first post) in case you're interested. PORTB is connected to an LED array.

ISR(INT7_vect)
{
led++;
PORTB = ~led;
_delay_ms(100);
}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'm using:
AVR Studio 4.17
Atmega128

I'm going to sic the GCC gurus on you anyway, so might as well tell the GCC version.

Sounds strange, doesn't it?

The test program is small enough, so let's see all the generated code--at least the "guts" of the main() and the ISR.

Also practice using the Code tags

because when
    the formatting is
    preserved
it makes it much easier to analyze.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm--if the M103C fuse was set, is there a CALL or a JMP to main()? Could the program be restarting every time a RETI is done?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Atmega128

Have you unprogrammed the mega103 compatibility fuse?

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
PORTB is connected to an LED array.
What value resistors are you using with the LEDs?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Schematic would be nice :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wouldn't think hardware or schematic are pertinent from what has been posted so far, since the right display apparently takes place when the display is done from within the ISR.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well he could have hooked the LEDs up in a funny but i just read that he checked the LED's when he tested the ISR so never mind.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about trying to define led as volatile unsigned char led instead of uint8_t? It may not make any difference but just something to try.

Also did you simulate it in the AVR Simulator?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just don't trust newbees and leds.

Quote:
define led as volatile unsigned char led instead of uint8_t?
It is defined as volatile.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

How about trying to define led as volatile unsigned char led instead of uint8_t? It may not make any difference but just something to try.

What are you talking about? stdint.h contains:

typedef unsigned char uint8_t;

????

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It was the M103C fuse indeed! Thanks Steve A. & 10k+ Superfreak...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had the same problem with mega64 because datasheet suggested that you have to turn on compatibility mode on purpose(page 5 "By programming the M103C Fuse...").
No more sleepless nights on this strange case, thanks to freaks:)