What is the behavior if ISR is not written

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

Assume that the condition is satisfied for an interrupt to occur and interrupt is enabled along with I bit. What will happen if ISR is not written? Is the behavior is undefined or ISR will just return without executing?

I one of my program, I observed strange behavior. In the outline code given below, I had forgot to implement ISR(PCINT2_vect). Because of that code was getting executed until while(!flag) and it was waiting for the flag to set; but then rest of the code was getting skipped. I was trying to use PCINT2 interrupt, but forgot to implement. I was expecting endless wait because flag was not getting set inside ISR, but while(1) was getting entered again and again

while(1)
{
    //Implement first Part
    
    while(!flag);
    
    // Implement second part
    
}


inline void commonCode(void)
{
   // some code here common to all ISRs
}


ISR(PCINT0_vect)
{
    flag=1;
    commonCode();
}

ISR(PCINT1_vect)
{
    flag=1;
    commonCode();
}

ISR(PCINT2_vect)
{
    flag=1;
    commonCode();
}

Secondly, if I have some common code to be executed by ISR, is it OK to write an inline function and call it from ISR like the one shown above?  

This topic has a solution.

Last Edited: Thu. Dec 28, 2017 - 05:31 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The AVR will do whatever >>your<< code tells it to do.

 

As the fragments that you posted imply that you are using C and a certain toolchain, then it is >>your chosen<< toolchain's action on how the interrupt vector table is filled in by default.  >>You<< can also override that default action.

 

GCC's default action and the override mechanism has been mentioned and discussed many times here.  [short answer:  A jump to 0]  There are no mentions in the documentation?

 

[edit]

http://www.nongnu.org/avr-libc/u...

Catch-all interrupt vector

If an unexpected interrupt occurs (interrupt is enabled and no handler is installed, which usually indicates a bug), then the default action is to ...

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.

Last Edited: Thu. Dec 28, 2017 - 04:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joneewheelock wrote:
What will happen if ISR is not written? Is the behavior is undefined

The behaviour of the hardware is very clearly defined - it will execute whatever code it finds at the vector address.

 

As theusch said, your toolchain might define some default code...

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

As Lee has explained. Missing ISR()s will just crash and reset.
.
Regarding inline. This will be unrolled in every ISR. No problem with CALL,RET. Try it and see for yourself.
.
David.

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

Lee already gave you the link to the page about GCC interrupt handling but you could do worse than read the whole user manual:

 

http://www.nongnu.org/avr-libc/u...

 

You may not take it all in at first reading but in future you may then have an idea where to go back to look for details.

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

david.prentice wrote:
Missing ISR()s will just crash and reset.

We don't know what toolchain the OP is using - so that might not be the case ...

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

Of course we know what toolchain he's using!

 

(Unless you know something besides GCC that uses ISR()?)

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

Well, I can't say that I know for sure that no other AVR toolchain uses ISR() ...

 

cheeky

 

@joneewheelock: It is important that you state what toolchain you are  talking about - it isn't always obvious.

 

But, irrespective, the following is always true - for any toolchain:

clawson wrote:
you could do worse than read the whole user manual ... You may not take it all in at first reading but in future you may then have an idea where to go back to look for details.

Last Edited: Thu. Dec 28, 2017 - 05:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Toolchain used is avr8-gnu-toolchain by atmel. Thanks for all the help. So explanation in the link given makes sense and that is why I see rest of the code skipping and basically control is resetting. 

 

Last Edited: Thu. Dec 28, 2017 - 05:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Missing ISR()s will just crash and reset.

After the introductory course above on Uncaught Interrupts In GCC 101, the time has come for the intermediate level discussion.

 

--  How does an AVR "crash"?  (or any computer program, for that matter)  In this case, as Andy pointed out, it interprets whatever word the Program Counter points to as an instruction and carries it out.  So we call unexpected operation "crashes".  Perhaps not too pertinent here, but on to ...

 

-- The AVR doesn't reset.  (Are there any conditions where code can cause an AVR8 to actually reset?  Xmega?  Xtiny?)  The default action for an uncaught interrupt in GCC C and some other toolchains is to end up with a jump to 0.  Which is the reset vector.  But, and this is usually subtle, it is not an AVR reset which sets I/O registers to initial values.  If your toolchain or programming, for example, does not reset SP stack pointer at startup, instead relying on the default value after a reset, then operation may not be clean after the ersatz "reset".  The doc I linked to above also says that the AVR is reset -- I wish that different wording would be used.

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.

Last Edited: Thu. Dec 28, 2017 - 05:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
The AVR doesn't reset.

Indeed.

 

If one did want it to reset, one approach would be to have the default ISR just do an infinite loop - and rely on a Watchdog to do a real reset ...

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

Why not force the Watchdog - used this to reset Tiny2313 when required:

	wdt_enable(WDTO_8S);	// 8 seconds
	// reset shortly
	while(1) { delay_ms(250); }

But make sure the Watchdog is stopped early in the startup code (using longish WDT of 8 seconds above gives you (lots of) TIME)

	wdt_reset();	// reset the wdt
	MCUSR = 0;		// clear just about everything
	wdt_disable();	// and disable watchdog

HTH

Dave

Dave