[M168 WinAVR] Strange interrupt behavior

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

I have an ATmega168 in power-save mode with Timer2 enabled (32768 Hz x-tal). On Timer 2 overflow it wakes up and executes this procedure (via the same interrupt):

ISR(SIG_OVERFLOW2)
{
 clock_++;
 
 if (clock_==128)
	{	   	 		  	   	  				   	
	clock_=0;
	hour[h_sek]++;
	if (timer[5]&BIT(fl_timer_chet)) timer[0]--;  
  	if ((int_curr[c_started]==1)&&(int_curr[h_min]<100))  int_curr[h_sek]++;
	time_flag&=~BIT(fl_sek_1_switch);	
  	time_in_regim--;
  	time_signal--;
    }
 if (clock_==112) time_flag|=BIT(fl_sek_1_switch);
 if ((clock_==48)||(clock_==80)) time_flag|=BIT(fl_plus);
 if ((clock_==32)||(clock_==64)) time_flag&=~BIT(fl_plus);
 time_note--;
 
 if (ps_started==1) ps_time++;


}

Several arithmetic operations and no more. Then it goes to the same sleep mode.

At 4 MHz everything works fine. At 8 MHz the procedure is sometimes executed TWICE per one wakeup - the clock runs at double speed. I need to add a delay approx. 5 us inside the procedure to eliminate this bug. What's the reason?

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

PS. The MCU is waked up on the interrupt and the procedure is also performed on this interrupt. It's a clock with an emergency battery-powered mode, in the normal mode the MCU runs constantly and does not sleep, but this procedure is executed 128 times per second via this interrupt.

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

How many cycles in the worst case ISR execution?

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

WrightFlyer wrote:
How many cycles in the worst case ISR execution?
Hidden-Cliff, perhaps you should mention that "worst" means "shortest" here. ;-)

watchmaker,
read the data sheet about "asynchronous timer mode and sleeping" and you will find the answer.

Stefan Ernst

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

Note I have deleted the post you made in the AVR Forum sticky thread about 168 bug. Of course this isn't a bug in the silicon - it's your faulty program. In the extraordinarily unlikely event that this did turn out to be a fault in the 168 then reinstate your post.

Moderator.