TIMER1_COMPA interrupt on Attiny85 not firing.

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

I am trying to use Timer1 on an ATTiny85 to generate a periodic interrupt. I created a simple test program which toggles an LED when the interrupt fires, but the interrupt never seems to fire.

I am using the internal 8Mhz oscillator and CKDIV8 fuse turn off, so its running at 8Mhz for F_CPU.

The IDE is Atmel Studio 6 and I am using AVR ISP MkII to program the device via standard ISP.

 

 

here is my code

 

#define F_CPU 8000000

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

void Timer1Init(void);

int main()
{
    DDRB |= _BV(PB0);
    
    Timer1Init();
    while(1);
    //  nothing to do, done with Timer1 Match interrupt
}

void Timer1Init(void)
{
    TCCR1 = 0;                  //stop the timer
    TCNT1 = 0;                  //zero the timer
    GTCCR = _BV(PSR1);          //reset the prescaler
    OCR1A = 100;                //set the compare value
    OCR1C = 100;
    TIMSK = _BV(OCIE1A);        //interrupt on Compare Match A
    
    TCCR1 = _BV(CTC1) | _BV(CS12); // Start timer, ctc mode, prescaler clk/8
    sei();
}

ISR(TIMER1_COMPA_vect)
{
    PORTB ^= _BV(PB0);         // Toggle the LED by toggling PB0
}

The tiny85 Timer1 seems like an odd duck, so I am not sure if I am doing things correctly.

 

Thanks,

 

Ben

This topic has a solution.
Last Edited: Thu. Aug 6, 2015 - 08:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Run your code in the simulator to see what is happening.
Have you looked out the compiler messages to see that you have chosen the correct vector name for the ISR?

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

It runs fine in the simulator.

There are no compiler warnings.

 

I think it is a programming/hardware problem because even a trivial busy led blink program does not work.
 

My hardware test setup is very simple. I have a breadboard with an ATTiny85 wired as follows:

 

Reset - 4.7k pullup to VCC

GND - Ground

VCC - 5V

 

I am monitoring PB0 with a Saleae Logic.

 

 

 

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

Its quite strange, because I have another very complex piece of code that uses timer0 interrupts, external interrupts and drives output lines and it loads and runs fine on the same hardware, but a simple LED blink program will not generate expected output on PB0 via logic analyzer.

 

#define F_CPU 8000000U

#include <avr/io.h>

 

int main()

{

    DDRB |= _BV(PB0);

 

    while(1)

    {

        PORTB ^= _BV(PB0);

    };

}

Last Edited: Mon. Aug 3, 2015 - 11:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oecben wrote:
#define F_CPU 8000000U

#include <avr/io.h>

 

int main()

{

    DDRB |= _BV(PB0);

 

    while(1)

    {

        PORTB ^= _BV(PB0);

    };

}

Post your .hex file, or better yet, your .lss file.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Here is the .lss file.

I don't see anything odd.

 


Timer1Test.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000064  00000000  00000000  00000054  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .comment      00000030  00000000  00000000  000000b8  2**0
                  CONTENTS, READONLY
  2 .debug_aranges 00000020  00000000  00000000  000000e8  2**0
                  CONTENTS, READONLY, DEBUGGING
  3 .debug_info   00000086  00000000  00000000  00000108  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_abbrev 00000051  00000000  00000000  0000018e  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_line   000000b8  00000000  00000000  000001df  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_frame  00000034  00000000  00000000  00000298  2**2
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_str    00000131  00000000  00000000  000002cc  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_loc    0000003b  00000000  00000000  000003fd  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_ranges 00000010  00000000  00000000  00000438  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0: 0e c0        rjmp .+28      ; 0x1e <__ctors_end>
   2: 15 c0        rjmp .+42      ; 0x2e <__bad_interrupt>
   4: 14 c0        rjmp .+40      ; 0x2e <__bad_interrupt>
   6: 13 c0        rjmp .+38      ; 0x2e <__bad_interrupt>
   8: 12 c0        rjmp .+36      ; 0x2e <__bad_interrupt>
   a: 11 c0        rjmp .+34      ; 0x2e <__bad_interrupt>
   c: 10 c0        rjmp .+32      ; 0x2e <__bad_interrupt>
   e: 0f c0        rjmp .+30      ; 0x2e <__bad_interrupt>
  10: 0e c0        rjmp .+28      ; 0x2e <__bad_interrupt>
  12: 0d c0        rjmp .+26      ; 0x2e <__bad_interrupt>
  14: 0c c0        rjmp .+24      ; 0x2e <__bad_interrupt>
  16: 0b c0        rjmp .+22      ; 0x2e <__bad_interrupt>
  18: 0a c0        rjmp .+20      ; 0x2e <__bad_interrupt>
  1a: 09 c0        rjmp .+18      ; 0x2e <__bad_interrupt>
  1c: 08 c0        rjmp .+16      ; 0x2e <__bad_interrupt>

0000001e <__ctors_end>:
  1e: 11 24        eor r1, r1
  20: 1f be        out 0x3f, r1 ; 63
  22: cf e5        ldi r28, 0x5F ; 95
  24: d2 e0        ldi r29, 0x02 ; 2
  26: de bf        out 0x3e, r29 ; 62
  28: cd bf        out 0x3d, r28 ; 61
  2a: 02 d0        rcall .+4       ; 0x30 <main>
  2c: 19 c0        rjmp .+50      ; 0x60 <_exit>

0000002e <__bad_interrupt>:
  2e: e8 cf        rjmp .-48      ; 0x0 <__vectors>

00000030 <main>:
#define F_CPU 8000000U

#include <avr/io.h>

int main()
{
  30: cf 93        push r28
  32: df 93        push r29
  34: cd b7        in r28, 0x3d ; 61
  36: de b7        in r29, 0x3e ; 62
    DDRB |= _BV(PB0);
  38: 87 e3        ldi r24, 0x37 ; 55
  3a: 90 e0        ldi r25, 0x00 ; 0
  3c: 27 e3        ldi r18, 0x37 ; 55
  3e: 30 e0        ldi r19, 0x00 ; 0
  40: f9 01        movw r30, r18
  42: 20 81        ld r18, Z
  44: 21 60        ori r18, 0x01 ; 1
  46: fc 01        movw r30, r24
  48: 20 83        st Z, r18
    
    while(1)
    {
        PORTB ^= _BV(PB0);
  4a: 88 e3        ldi r24, 0x38 ; 56
  4c: 90 e0        ldi r25, 0x00 ; 0
  4e: 28 e3        ldi r18, 0x38 ; 56
  50: 30 e0        ldi r19, 0x00 ; 0
  52: f9 01        movw r30, r18
  54: 30 81        ld r19, Z
  56: 21 e0        ldi r18, 0x01 ; 1
  58: 23 27        eor r18, r19
  5a: fc 01        movw r30, r24
  5c: 20 83        st Z, r18
    };
  5e: f5 cf        rjmp .-22      ; 0x4a <__SREG__+0xb>

00000060 <_exit>:
  60: f8 94        cli

00000062 <__stop_program>:
  62: ff cf        rjmp .-2       ; 0x62 <__stop_program>

 

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

-O0, eh? ;)

 

Are you building for the correct AVR model?  Are you >>positive<< that you are sending the correct firmware to the chip?

 

Perhaps post the build and ISP logs.

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

oecben wrote:
I don't see anything odd.
Really?:
theusch wrote:
-O0, eh? ;)

 

Nevertheless it should work.

 

theusch wrote:
Are you building for the correct AVR model?
It would appear so.  Vector table has 15 entries.  DDRB is at 0x17/0x37 and PORTB is at 0x18/0x38.

 

So:

theusch wrote:
Are you >>positive<< that you are sending the correct firmware to the chip?

 

To confirm this, read the flash memory from the device using avrdude and compare it against what you think should be in there.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Tue. Aug 4, 2015 - 03:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

-O0  Yes .. I removed all optimization in vain attempt to get it to run.

 

I have given up on it for the moment. Here is the situation:

 

Running from Atmel Studio 6 (Version 6.2.1563 - Service Pack 2)  

I use the tool built into Atmel Studio to program the devices; verify turned on

I am using an Atmel ISP MkII with latest firmware.

 

I have several existing pieces of software that I can modify, build and flash to the same device that will run without problem.

Starting a blank project and using the above basic code does not work.

 

Using WinAVR I have no problem with the same code, programmer and physical device, so I am inclined to assume it is something with my Atmel Studio installation.

 

 

Last Edited: Wed. Aug 5, 2015 - 01:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
so I am inclined to assume it is something with my Atmel Studio installation.
Anything is possible, but you should rule out the obvious first.

 

  • Program the device
  • Confirm that it is not working
  • Read the contents of the device's flash
  • Post the results

 

You can read flash with avrdude, or with atprogram.exe.  I don't know what atprogram.exe will generate, but you can get avrdude to generate a binary file with -U flash:r:foo.bin:r or an Intel Hex file with -U flash:r:foo.bin:i

 

Whatever you're able to grab, post it as an attachment here.

 

EDIT: While you're at it, read and post the fuse values.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Wed. Aug 5, 2015 - 01:46 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can read flash with avrdude, or with atprogram.exe. 

If OP is using Studio to do the ISP, wouldn't it be straightforward to use that to read the flash?  (I just posted the panel in https://www.avrfreaks.net/comment... )

 

And when one navigates to that panel in Studio with the project open, the full file name of the .HEX that Studio sends is shown.  Is that really the build results?  When you navigate there with Explorer, do the Properties indicate it is in fact the latest build?

 

[Wasn't there a very recent thread with something like that, and it was Debug vs Release ?]

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

theusch wrote:
If OP is using Studio to do the ISP, wouldn't it be straightforward to use that to read the flash?
Right, but:

so I am inclined to assume it is something with my Atmel Studio installation.

If Studio is in fact part of the problem (which I agree is unlikely), independently verifying that the device is being programmed with the correct image would seem to be an easy first step.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

theusch wrote:

And when one navigates to that panel in Studio with the project open, the full file name of the .HEX that Studio sends is shown.  Is that really the build results?  When you navigate there with Explorer, do the Properties indicate it is in fact the latest build?

 

[Wasn't there a very recent thread with something like that, and it was Debug vs Release ?]

 

This was it exactly. Stupid me, I assumed that it would automatically select the build product of the currently selected configuration, but it was actually selecting something that wasn't even in the right project folder. I am embarrassed I did not verify this earlier.

 

@joeymorin: you were right all along!!

 

This is my first adventure with AVR/Atmel Studio in a while. In the past I have commonly used Imagecraft or Code/Em::Blocks + WinAVR.

 

Thanks for all your help in chasing my own tail!!

Last Edited: Wed. Aug 5, 2015 - 06:31 PM