ATMEGA328PB No Timer interrupt

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


/*********************************************************
 *                                                       *
 *          16 BIT TIMER #1
                                *
 *********************************************************/

/*

 At 16 MHz    Ck = 0.0625uS    ( 0.5us after  divide by 8 )   2.374mS = 2374uS 
*/

	TCCR1A = 00; ;	// reset on compare
	TCCR1B =  (1<<WGM12) | (1<<CS11); 	// select divide by 8

	OCR1AH = 0x00;
	OCR1AL = 200;  // 100uS

	TIMSK1 = (1<<OCIE1A); // Enable  Compare A interrupt

/*********************************************************
 *                                                       *
 *          16 BIT TIMER #3
                                *
 *********************************************************/

/*

 At 16 MHz    Ck = 0.0625uS    ( 0.5us after  divide by 8 )   2.374mS = 2374uS 
*/

	TCCR3A = 00; ;	// reset on compare
	TCCR3B =  (1<<WGM32) | (1<<CS30); // select divide by 0


	OCR3A =  4748; // 2374uS *2 @ 16mHZ
	TIMSK3 = (1<<OCIE3A) | (1<<TOIE3);   // Enable Compare A and OVF Interrupts

 

Timers used just for interrupting - no I/O operations used.

 

 

Timer 1 interrupt fires perfectly, Timer 3 doesn't trigger either the compare or the overrun.

Examining the I/O when paused, the  T3 counter is running, the TIFR  has been set flag is set, the Int mask bits are set - yet it never jumps to the ISR.

The ISR vector is present at the correct address .. 

Stumped for the moment.

 

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

UPDATE. ATMega328PB  complete mini test program as shown.

Works in the simulator but still doesn't trigger T4 interrupt when run in debug mode on target device.

Confirmation from anyone please.

 

/*
 * Test1.c
 *
 * Created: 26/10/2018 23:25:08
 * Author : Rob
 */ 

#include <avr/io.h>
#include <avr/interrupt.h>

int main(void)
{
	
	
	
	/*********************************************************
 *                                                       *
 *          16 BIT TIMER #1
                                *
 *********************************************************/

/*

 At 16 MHz    Ck = 0.0625uS    ( 0.5us after  divide by 8 )   2.374mS = 2374uS 
*/

	TCCR1A = 00; ;	// reset on compare
	TCCR1B =  (1<<WGM12) | (1<<CS11); 	// select divide by 8

	OCR1AH = 0x00;
	OCR1AL = 200;  // 100uS

	TIMSK1 = (1<<OCIE1A); // Enable  Compare A interrupt

/*********************************************************
 *                                                       *
 *          16 BIT TIMER #3
                                *
 *********************************************************/

/*

 At 16 MHz    Ck = 0.0625uS    ( 0.5us after  divide by 8 )   2.374mS = 2374uS 
*/

	TCCR3A = 00; ;	// reset on compare
	TCCR3B =  (1<<WGM32) | (1<<CS30); // select divide by 0


	OCR3A =  4748; // 2374uS *2 @ 16mHZ
	TIMSK3 = (1<<OCIE3A) | (1<<TOIE3);   // Enable Compare A and OVF Interrupts
	
	
	SREG |= 0X80;	// Global Interrupt Enable
	
		
    /* Replace with your application code */
    while (1) 

    {
				
			PORTB ^= 10;
			PORTC ^= 20;	
			PORTB ^= 20;		
			PORTC ^= 10;					
		
    }
}


ISR (TIMER1_COMPA_vect)
{

	PORTB ^= 0x01;
}

ISR (TIMER3_COMPA_vect)
{
	PORTB ^= 0x04;
}


ISR (TIMER3_OVF_vect)
{

	PORTB ^= 0x02;
}

 

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

rowifi wrote:
complete mini test program as shown

... still doesn't trigger T4 interrupt when run in debug mode on target device.

How exactly do you observe that?

1) None of the pins is actually an output.

2) You are toggling the same pins in the T3 interrupts and the main loop.

Stefan Ernst

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

PORTB ^= 10; seems a tad suspect. Methinks you wanted 0x10
Same for the others.

The OCR registers need value + 1

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

1. I meant Timer T3 not T4 in any text.

2. The port toggle is dummy code so I can set a break point on it, it's not intended to do anything and could be replaced by anything really.

 

The original code in my program never seemed to execute it's intended purpose which is to perform a function at regular intervals, no outputs are involved.

The T3  ISR was never accessed - checked using break point.

 

The test program was used to ensure I hadn't done anything silly in my main program so I reduced it to basically timers and interrupts.

 

The Timer 3 Compare ISR is executed - (breakpoint on the ' pin toggle' ) when running in simulator.

It isn't executed when running in debug mode on a target processor.

 

It's been reduced to the simplest code imaginable to prove a point, which suggests T3 interrupts are definitely not working on my targets but do on the simulator.

I'm still stumped by this.

 

 

 

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

Have you tried just running the code?  Not using debug

mode, but actually hooking up a few LEDs to the chip?

--Mike

 

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

Are you sure you are compiling, testing and debugging on the same type of processor? I.e. on a 328PB-xx?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

Everyone.. thanks.

 

I think I'm onto a solution, and as usual it's something I've done/not done.

 

Having tried the minimal solution yet again on the target - it worked... so could be finger trouble.

That led me to minimise the original program chopping sections out, bit by bit  that indicate a cause.

What has happened is that a UART file used the original ( single Uart)  mega328 ISR vector names which surprised me by not flagging a compile error, instead causing a default interrupt handler to fire for the uart instead of the real one.

They now of course need to target one of the TWO UARTS, and in doing so the Timers now appear to correctly execute their vectors.

 

 

 

 

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

Wrong vectors cause warnings, not errors. Are you really claiming the wrong vector name caused no warning? (It will have used the term "misspelled")

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

To be honest, I didn't check the warnings.. I know it didn't give me an error, so my bad.

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

Kind of my point. Never ignore anything reported during the build unless you are 100% certain it's benign (and in which case do something to quell such warnings so the important messages stand out).