Interrupt causes ATMega2560 to Reset.

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

Hello all!
I'm trying to catch PCINT20 on ATMega2560 MCU.
Here is related extraction of Code:

// Interrupt Initialization:
// Enable PCINT20 External Interrupt:
PCMSK2 |= 0x10;
// Enable Pin Change Interrupt:
PCICR = 4;
// Port Direction:
DDRE = 0;
// Enable Interrupts:
sei ();

// Interrupt Service Routine:
ISR(PCINT2_vect)
{
  SendString_P (PSTR("___________PCINT20!\n"));
}

When pin state is changed AVR goes to reset every time.
I've tested it with empty interrupt routine - the same result. So something wrong is with interrupt initialization.
Please help me or direct to any working example.

P.S.
Unfortunately search on this forum does not work.

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

Could you be building for the wrong device? Can you post a .lss file?

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

My crystal ball says it is not safe to call SendString_P() from an ISR.

JW

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

Thanks for responses.
I think my fault was that I didn't include avr/interrupt.h in file containing PCINT20 ISR. I've got warning but compilation was successful. So in fact I had enabled interrupt without it's service routine. In this case ATMega goes to reset every time interrupt causes.

clawson wrote:
Could you be building for the wrong device? Can you post a .lss file?

I don't think I build for another device. I'm new to AVR but not SO new. :D

wek wrote:
My crystal ball says it is not safe to call SendString_P() from an ISR.

Can you explain why it is not safe use SendString_P() from ISR?

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

Quote:

I've got warning but compilation was successful

Where in any of the preceding did you mention anything about a compilation warning?!? They must NEVER be ignored until you are 100% certain the warning is benign. -Werror is a good idea as it means you cannot ignore the warnings.

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

Quote:
Can you explain why it is not safe use SendString_P() from ISR?
If SendString_P() is also called from outside the ISR, it is possible that the ISR happens during the middle a call to SendString_P() which would likely cause big problems (do a search on "reentrant"). Aside from that, the call is likely expensive, which is something that you don't want in an ISR.

Regards,
Steve A.

The Board helps those that help themselves.

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

Quote:
-Werror is a good idea as it means you cannot ignore the warnings.

Yes, good idea. -Werror in couple with -Wall will stop compilation on any warning.

Koshchi, in this case calling ANY function from ISR is not safe.

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

Quote:

in this case calling ANY function from ISR is not safe.

No, only functions that are (a) non re-entrant and (b) called from both main()line and one or more ISR()s

But anyway you usually don't want to call a function from an ISR() on an 8bit micro anyway because you want the thing to complete within a few microseconds so that interrupts are not blocked. If you are calling functions your ISR()s are probably too complex. If you need to output a string as a result of an ISR() then in the ISR set a volatile flag to say that the message must be output then in the main() loop regularly check that flag and output the string when you see the flag set (and then reset it).