Interrupt help

Log in or register to post comments
Go To Last Post
20 posts / 0 new
Author
Message
Avrduder
Avrduder's picture
Level: New Member
Joined: Sat. Feb 3, 2018
Posts: 5 View posts
#1
Posted by Avrduder: Sat. Feb 3, 2018 - 06:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm new programming in C and would like a pointer as to what's up with some code. I'm using an AtMega32-16PU processor and attempting to light up an LED using a simple interrupt routine. I have the LED plugged into pin1 with an in series resistor. 

 

This code does not work:

 

**********************

#include <avr/io.h>

#include <avr/interrupt.h>

 

 

int main(void)

{

sei();

DDRB |= 1<<PINB0;

TCCR1B = 0b00001001;

TIMSK |= 1<<OCIE1A;

OCR1A = 25;

 

    while(1){

    }

 

}

 

ISR(TIMER1_COMPA_vect){

PORTB ^= 1<<PINB0;

}

 

***************

 

 

However, if I initialize PORTB to 0x01, the LED lights up. The LED does not light if PORTB is initialized to 0x00.

 

I'm clearly missing some piece of information which surely makes this result the obvious correct behavior, but it seems odd to me that I have to initialize the value of PORTB and it has to be 0 here given the the way I've written the interrupt routine. 

 

Thoughts?

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Last Edited: Sat. Feb 3, 2018 - 09:21 PM
Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 21799 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Sat. Feb 3, 2018 - 07:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Welcome to AVR Freaks!

 

Several quick thoughts. First, I am not a Mega32 user so I do not know what those TCCR1B bits do. The preferred style is something like (I had to look this up)

 

TCCR1B = (1<<WGM112) | (1<<CS10);

 

Now, I know that you ARE setting the prescaler and are setting Waveform Generation Mode. 

 

Since the prescale factor is so small, I would bet that it is switching on and off so fast that you simply cannot see it. It may be that if you look at it closely, you will see that it is dimly on.

 

Second, you will also get much better response if you use the code editor. It is that button with a caption that looks like "<>". Your program looks like this:

 

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

int main(void)
{
sei();
DDRB |= 1<<PINB0;
TCCR1B = 0b00001001;
TIMSK |= 1<<OCIE1A;
OCR1A = 25;

    while(1){
    }

}

ISR(TIMER1_COMPA_vect){
PORTB ^= 1<<PINB0;
}

***************

A third small point, probably not contributing to your problem, is that the sei(); is usually executed after things are initialized. It prevents interrupts before your code is prepared to handle them.

 

Cheers

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sat. Feb 3, 2018 - 07:15 AM
Top
avrcandies
avrcandies's picture
Level: Raving Lunatic
Joined: Wed. Jun 30, 2004
Posts: 6226 View posts
Location: Cincinnati Oh
Posted by avrcandies: Sat. Feb 3, 2018 - 07:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sound like you irq is not running or doing nothing, maybe try

 

PORTB ^= 1<<PORTB0;

 

PIN is used to read a pin that is an input. On SOME avr's or you can write 1 to PIN register (not port) configured as an output to toggle it 's output state, but the mega 32 datasheet does not seem to have this feature.  So you need to do your own toggling.

 

Your divider in also very low, so even if it toggles , it will be extremely fast (blur), try setting some CSx bits  (like /1024)

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Feb 3, 2018 - 07:53 AM
Top
larryvc
larryvc's picture
Level: Raving Lunatic
Joined: Thu. Dec 6, 2007
Posts: 4229 View posts
Location: Redmond, WA, USA
Posted by larryvc: Sat. Feb 3, 2018 - 08:16 AM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
...maybe try

 

PORTB ^= 1<<PORTB0;

avrcandies wrote:
PIN is used...
If that were the case yes, partially true, pin is used to read the current value at the pin regardless of whether input or output.

 

Here, PINB0 and PB0 are defined in iom32.h and used as bit positions for use in the shift only.  PINB0 = 0, PB0 = 0, and although it is more appropriate to use PB0 in this case, it wouldn't have an impact on the code either way.  Note that PORTB0 is not defined at all.

 

It should be written clearly as

 

PORTB ^= (1 << PB0);

 

EDIT: Cleaned up answer

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Sat. Feb 3, 2018 - 10:58 AM
Top
avrcandies
avrcandies's picture
Level: Raving Lunatic
Joined: Wed. Jun 30, 2004
Posts: 6226 View posts
Location: Cincinnati Oh
Posted by avrcandies: Sat. Feb 3, 2018 - 09:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you configured the project for the correct chip---if it is configured to produce code for a chip that has the irq at some other location, then things would go awry.  Some AVR's have a slightly different irq vector table. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Top
Paulvdh
Paulvdh's picture
Level: Raving Lunatic
Joined: Fri. Aug 3, 2001
Posts: 2802 View posts
Posted by Paulvdh: Sat. Feb 3, 2018 - 10:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you put this in your interrupt:

ISR(TIMER1_COMPA_vect) {
  ++PORTB;
}

Then you wil create a binary counter on PORTB.

Each bit wil have a different blink rate, which makes it easier to see if it works.

Ofcourse you have to make all bits outputs:

  DDRB = 0xff;      // All bits of PORTB are outputs.

 

I have not tried your code, but from memory it looks like you have enabled the interrupt properly, but you havent started the counter.

To turn the timer on you have to turn on one or more of the "WGM" bits as Jim suggests in post #2

 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101074 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Sat. Feb 3, 2018 - 01:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree with Jim. It's probably flashing too fast to see. Even if we assume the micro is only run at 1MHz then the CS10 means that the timer runs at the same speed. So even if it's a 16 bit timer that has to count to 65536 before it overflows it will do that 15 times per second which is probably just too fast to see. This gets worse if the CPU runs at more than 1MHz, at 8 MHz it switches 122 times in one second that a human has no hope of seeing.

Try setting CS bits to divide by 64 or something like that.

Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Sat. Feb 3, 2018 - 08:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree with Jim. It's probably flashing too fast to see.

But:

However, if I initialize PORTB to 0x01, the LED lights up. The LED does not light if PORTB is initialized to 0x00.

 

So you've set CTC mode, /1 prescaler, with TCCR1B = 0b00001001, and you've set a period of 26 with OCR1A = 25.  Since the ISR toggles every pass, so the LED on PB0 will show a 50% square wave with double the timer period, or 52 cycles.

 

At 1 MHz, that's 1000000 / 52 = 19.23 kHz.  Way too fast to see.

 

However I'm puzzled by the fact that when you "initialize PORTB to 0x01, the LED lights up. The LED does not light if PORTB is initialized to 0x00".  Perhaps you need to show us how you're doing that exactly?

 

Also, you could post the .hex file that you're uploading to the m32.  Maybe we'll spot something (like wrong mcu type?).

 

 

"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]

 

Top
Paulvdh
Paulvdh's picture
Level: Raving Lunatic
Joined: Fri. Aug 3, 2001
Posts: 2802 View posts
Posted by Paulvdh: Sun. Feb 4, 2018 - 04:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My timer knowledge is a bit rusty, but Jim in #2 and I in post #6 I noticed:

Paulvdh wrote:
but you havent started the counter.
Am I being silly here or do you have to set some of the WGM bits to make the timer do anything?

 

 

 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101074 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Sun. Feb 4, 2018 - 04:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The thing that starts a timer is setting any pattern of CS bits (prescalar) other than 000 (and setting them all to 0 stops it).

Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Sun. Feb 4, 2018 - 05:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I didn't see the unedited OP.  As of this writing, it was last edited after my post #8.  When I made that post he had (and still has):

TCCR1B = 0b00001001;

... which definitely starts the timer.

"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]

 

Top
Avrduder
Avrduder's picture
Level: New Member
Joined: Sat. Feb 3, 2018
Posts: 5 View posts
Posted by Avrduder: Sun. Feb 4, 2018 - 05:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry guys let me be a little more clear

 

This code works and runs. I can see a waveform on my scope of 18.2kHz. I haven't reasoned about the cycles, but that is reasonably close to the analysis Joey did. I initialized PORTB to have a value of 1 in PB0.

 

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

int main(void)
{
	sei();
	DDRB |= 1<<PB0;
	PORTB ^= 1<<PB0;
	TCCR1B = (1<<CS10) | (1<<WGM12);
	TIMSK |= 1<<OCIE1A;
	OCR1A = 25;

    while(1){
    }

}

ISR(TIMER1_COMPA_vect){
	PORTB ^= 1<<PB0;
}

 

However, this code does not produce any waveform on my scope. I just commented out initializing the value in PORTB.

 

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

int main(void)
{
	sei();
	DDRB |= 1<<PB0;
	// PORTB ^= 1<<PB0;
	TCCR1B = (1<<CS10) | (1<<WGM12);
	TIMSK |= 1<<OCIE1A;
	OCR1A = 25;

    while(1){
    }

}

ISR(TIMER1_COMPA_vect){
	PORTB ^= 1<<PB0;
}

This final code block does not work either, but really puzzles me. I would expect it to be no different than the first set of code because the statement in the interrupt should toggle PBO regardless of the value it is initialized with. 

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

int main(void)
{
	sei();
	DDRB |= 1<<PB0;
	PORTB ^= 0<<PB0;
	TCCR1B = (1<<CS10) | (1<<WGM12);
	TIMSK |= 1<<OCIE1A;
	OCR1A = 25;

    while(1){
    }

}

ISR(TIMER1_COMPA_vect){
	PORTB ^= 1<<PB0;
}

 

Anyone have an idea of what is going on here? I've uploaded the makefile as well as the complied hex code. Any help would be greatly appreciated!

 

 

Attachment(s): 

Binary Data main.hex
Plain text icon Makefile.txt
Top
Bronze MarkJohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26945 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Sun. Feb 4, 2018 - 07:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the second code snippet above does not work then it hints at the ISR never being called.

 

If my hypothesis is true then something else makes PORTB pin 0 wiggle. Repeated resets is one possibility. Could be caused by e.g. watchdog resets. Is it disabled?

 

 

As for

	PORTB ^= 0<<PB0;

xor'ing with zero does nothing. It is a meaningless operation. The above line will leave PORTB unchanged. Regardless of it's initial value. Always.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101074 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Sun. Feb 4, 2018 - 08:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dangerous to sei() before config is complete!

Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Sun. Feb 4, 2018 - 09:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the second code snippet above does not work then it hints at the ISR never being called.

Except he reports seeing 18.2 kHz.

 

If my hypothesis is true then something else makes PORTB pin 0 wiggle. Repeated resets is one possibility. Could be caused by e.g. watchdog resets. Is it disabled?

Not at 18.2 kHz.

 

I'm still waiting for the .hex 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]

 

Top
Avrduder
Avrduder's picture
Level: New Member
Joined: Sat. Feb 3, 2018
Posts: 5 View posts
Posted by Avrduder: Mon. Feb 5, 2018 - 09:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Joey the .hex file was attached to my last post, but here it is again if you'd like to take a look.

Attachment(s): 

Binary Data main.hex
Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Mon. Feb 5, 2018 - 11:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, missed it.

 

OK, so here's what main.hex in post #16 disassembles to:

$ avr-objdump -Dzmavr main_7.hex

main_7.hex:     file format ihex

Disassembly of section .sec1:

00000000 <.sec1>:
   0:	0c 94 2a 00 	jmp	0x54	;  0x54
   4:	0c 94 34 00 	jmp	0x68	;  0x68
   8:	0c 94 34 00 	jmp	0x68	;  0x68
   c:	0c 94 34 00 	jmp	0x68	;  0x68
  10:	0c 94 34 00 	jmp	0x68	;  0x68
  14:	0c 94 34 00 	jmp	0x68	;  0x68
  18:	0c 94 34 00 	jmp	0x68	;  0x68
  1c:	0c 94 34 00 	jmp	0x68	;  0x68
  20:	0c 94 34 00 	jmp	0x68	;  0x68
  24:	0c 94 34 00 	jmp	0x68	;  0x68
  28:	0c 94 34 00 	jmp	0x68	;  0x68
  2c:	0c 94 34 00 	jmp	0x68	;  0x68
  30:	0c 94 34 00 	jmp	0x68	;  0x68
  34:	0c 94 34 00 	jmp	0x68	;  0x68
  38:	0c 94 34 00 	jmp	0x68	;  0x68
  3c:	0c 94 34 00 	jmp	0x68	;  0x68
  40:	0c 94 34 00 	jmp	0x68	;  0x68
  44:	0c 94 34 00 	jmp	0x68	;  0x68
  48:	0c 94 34 00 	jmp	0x68	;  0x68
  4c:	0c 94 34 00 	jmp	0x68	;  0x68
  50:	0c 94 34 00 	jmp	0x68	;  0x68
  54:	11 24       	eor	r1, r1
  56:	1f be       	out	0x3f, r1	; 63
  58:	cf e5       	ldi	r28, 0x5F	; 95
  5a:	d8 e0       	ldi	r29, 0x08	; 8
  5c:	de bf       	out	0x3e, r29	; 62
  5e:	cd bf       	out	0x3d, r28	; 61
  60:	0e 94 36 00 	call	0x6c	;  0x6c
  64:	0c 94 45 00 	jmp	0x8a	;  0x8a
  68:	0c 94 00 00 	jmp	0	;  0x0
  6c:	81 e0       	ldi	r24, 0x01	; 1
  6e:	87 bb       	out	0x17, r24	; 23
  70:	8e bd       	out	0x2e, r24	; 46
  72:	21 e0       	ldi	r18, 0x01	; 1
  74:	8c b5       	in	r24, 0x2c	; 44
  76:	9d b5       	in	r25, 0x2d	; 45
  78:	81 34       	cpi	r24, 0x41	; 65
  7a:	9c 49       	sbci	r25, 0x9C	; 156
  7c:	d8 f3       	brcs	.-10     	;  0x74
  7e:	1d bc       	out	0x2d, r1	; 45
  80:	1c bc       	out	0x2c, r1	; 44
  82:	88 b3       	in	r24, 0x18	; 24
  84:	82 27       	eor	r24, r18
  86:	88 bb       	out	0x18, r24	; 24
  88:	f5 cf       	rjmp	.-22     	;  0x74
  8a:	f8 94       	cli
  8c:	ff cf       	rjmp	.-2      	;  0x8c

 

And here are my annotations showing the C code which (likely) generated it:


<main>:

int main(void) {

	DDRB = (1<<PB0);
  6c:	81 e0       	ldi	r24, 0x01	; 1
  6e:	87 bb       	out	0x17, r24	; 23

	TCCR1B = (1<<CS10);
  70:	8e bd       	out	0x2e, r24	; 46

  72:	21 e0       	ldi	r18, 0x01	; 1

	while (1) {
		while (TCNT1 < 40001);
  74:	8c b5       	in	r24, 0x2c	; 44
  76:	9d b5       	in	r25, 0x2d	; 45
  78:	81 34       	cpi	r24, 0x41	; 65
  7a:	9c 49       	sbci	r25, 0x9C	; 156
  7c:	d8 f3       	brcs	.-10     	;  0x74

		TCNT1 = 0;
  7e:	1d bc       	out	0x2d, r1	; 45
  80:	1c bc       	out	0x2c, r1	; 44

		PORTB ^= (1<<PB0);
  82:	88 b3       	in	r24, 0x18	; 24
  84:	82 27       	eor	r24, r18
  86:	88 bb       	out	0x18, r24	; 24

  88:	f5 cf       	rjmp	.-22     	;  0x74
	}	// while (1)

}	// int main(void)

 

This bears little resemblance to the code you've posted in #1.

 

I note with some annoyance that the main.hex you posted in #16 does not match the one you posted in #16#12:


main_6.hex:     file format ihex

Disassembly of section .sec1:

00000000 <.sec1>:
   0:	12 c0       	rjmp	.+36     	;  0x26
   2:	19 c0       	rjmp	.+50     	;  0x36
   4:	18 c0       	rjmp	.+48     	;  0x36
   6:	17 c0       	rjmp	.+46     	;  0x36
   8:	16 c0       	rjmp	.+44     	;  0x36
   a:	15 c0       	rjmp	.+42     	;  0x36
   c:	15 c0       	rjmp	.+42     	;  0x38
   e:	13 c0       	rjmp	.+38     	;  0x36
  10:	12 c0       	rjmp	.+36     	;  0x36
  12:	11 c0       	rjmp	.+34     	;  0x36
  14:	10 c0       	rjmp	.+32     	;  0x36
  16:	0f c0       	rjmp	.+30     	;  0x36
  18:	0e c0       	rjmp	.+28     	;  0x36
  1a:	0d c0       	rjmp	.+26     	;  0x36
  1c:	0c c0       	rjmp	.+24     	;  0x36
  1e:	0b c0       	rjmp	.+22     	;  0x36
  20:	0a c0       	rjmp	.+20     	;  0x36
  22:	09 c0       	rjmp	.+18     	;  0x36
  24:	08 c0       	rjmp	.+16     	;  0x36
  26:	11 24       	eor	r1, r1
  28:	1f be       	out	0x3f, r1	; 63
  2a:	cf e5       	ldi	r28, 0x5F	; 95
  2c:	d4 e0       	ldi	r29, 0x04	; 4
  2e:	de bf       	out	0x3e, r29	; 62
  30:	cd bf       	out	0x3d, r28	; 61
  32:	14 d0       	rcall	.+40     	;  0x5c
  34:	21 c0       	rjmp	.+66     	;  0x78
  36:	e4 cf       	rjmp	.-56     	;  0x0
  38:	1f 92       	push	r1
  3a:	0f 92       	push	r0
  3c:	0f b6       	in	r0, 0x3f	; 63
  3e:	0f 92       	push	r0
  40:	11 24       	eor	r1, r1
  42:	8f 93       	push	r24
  44:	9f 93       	push	r25
  46:	88 b3       	in	r24, 0x18	; 24
  48:	91 e0       	ldi	r25, 0x01	; 1
  4a:	89 27       	eor	r24, r25
  4c:	88 bb       	out	0x18, r24	; 24
  4e:	9f 91       	pop	r25
  50:	8f 91       	pop	r24
  52:	0f 90       	pop	r0
  54:	0f be       	out	0x3f, r0	; 63
  56:	0f 90       	pop	r0
  58:	1f 90       	pop	r1
  5a:	18 95       	reti
  5c:	78 94       	sei
  5e:	b8 9a       	sbi	0x17, 0	; 23
  60:	88 b3       	in	r24, 0x18	; 24
  62:	88 bb       	out	0x18, r24	; 24
  64:	89 e0       	ldi	r24, 0x09	; 9
  66:	8e bd       	out	0x2e, r24	; 46
  68:	89 b7       	in	r24, 0x39	; 57
  6a:	80 61       	ori	r24, 0x10	; 16
  6c:	89 bf       	out	0x39, r24	; 57
  6e:	89 e1       	ldi	r24, 0x19	; 25
  70:	90 e0       	ldi	r25, 0x00	; 0
  72:	9b bd       	out	0x2b, r25	; 43
  74:	8a bd       	out	0x2a, r24	; 42
  76:	ff cf       	rjmp	.-2      	;  0x76
  78:	f8 94       	cli
  7a:	ff cf       	rjmp	.-2      	;  0x7a

 

And my annotations:


main_6.hex:     file format ihex

Disassembly of section .sec1:

00000000 <.sec1>:
	// This vector table is has entries which are only one word long.
	// The m32's vector table has entreis which are two words long.
	// Conclusion:  This was not built for the m32.  It was likely built
	// for its smaller cousin, the m8, which has single-word entries.
	// Register annotations below make that assumption.
   0:	12 c0       	rjmp	.+36     	;  0x26
   2:	19 c0       	rjmp	.+50     	;  0x36
   4:	18 c0       	rjmp	.+48     	;  0x36
   6:	17 c0       	rjmp	.+46     	;  0x36
   8:	16 c0       	rjmp	.+44     	;  0x36
   a:	15 c0       	rjmp	.+42     	;  0x36
   c:	15 c0       	rjmp	.+42     	;  0x38
   e:	13 c0       	rjmp	.+38     	;  0x36
  10:	12 c0       	rjmp	.+36     	;  0x36
  12:	11 c0       	rjmp	.+34     	;  0x36
  14:	10 c0       	rjmp	.+32     	;  0x36
  16:	0f c0       	rjmp	.+30     	;  0x36
  18:	0e c0       	rjmp	.+28     	;  0x36
  1a:	0d c0       	rjmp	.+26     	;  0x36
  1c:	0c c0       	rjmp	.+24     	;  0x36
  1e:	0b c0       	rjmp	.+22     	;  0x36
  20:	0a c0       	rjmp	.+20     	;  0x36
  22:	09 c0       	rjmp	.+18     	;  0x36
  24:	08 c0       	rjmp	.+16     	;  0x36

  26:	11 24       	eor	r1, r1
  28:	1f be       	out	0x3f, r1	; 63
  2a:	cf e5       	ldi	r28, 0x5F	; 95
  2c:	d4 e0       	ldi	r29, 0x04	; 4
  2e:	de bf       	out	0x3e, r29	; 62
  30:	cd bf       	out	0x3d, r28	; 61
  32:	14 d0       	rcall	.+40     	;  0x5c
  34:	21 c0       	rjmp	.+66     	;  0x78

  36:	e4 cf       	rjmp	.-56     	;  0x0

// This was intended to be TIMER1_COMPA_vect, but with the incorrect vector table,
// an m32 would never get here.
<__vector_6>:
ISR (TIMER1_COMPA_vect) {
  38:	1f 92       	push	r1
  3a:	0f 92       	push	r0
  3c:	0f b6       	in	r0, 0x3f	; 63
  3e:	0f 92       	push	r0
  40:	11 24       	eor	r1, r1
  42:	8f 93       	push	r24
  44:	9f 93       	push	r25

	PORTB ^= (1<<PB0);
  46:	88 b3       	in	r24, 0x18	; 24
  48:	91 e0       	ldi	r25, 0x01	; 1
  4a:	89 27       	eor	r24, r25
  4c:	88 bb       	out	0x18, r24	; 24

  4e:	9f 91       	pop	r25
  50:	8f 91       	pop	r24
  52:	0f 90       	pop	r0
  54:	0f be       	out	0x3f, r0	; 63
  56:	0f 90       	pop	r0
  58:	1f 90       	pop	r1
  5a:	18 95       	reti
}

<main>:
int main(void) {
	sei();
  5c:	78 94       	sei

	DDRB |= (1<<PB0);
  5e:	b8 9a       	sbi	0x17, 0	; 23

	// This was probably your PORTB ^= 0<<PB0;
	PORTB = PORTB;
  60:	88 b3       	in	r24, 0x18	; 24
  62:	88 bb       	out	0x18, r24	; 24

	TCCR1B = (1<<WGM12) | (1<<CS10);
  64:	89 e0       	ldi	r24, 0x09	; 9
  66:	8e bd       	out	0x2e, r24	; 46

	TIMSK |= (1<<OCIE1A);
  68:	89 b7       	in	r24, 0x39	; 57
  6a:	80 61       	ori	r24, 0x10	; 16
  6c:	89 bf       	out	0x39, r24	; 57

	OCR1A = 25;
  6e:	89 e1       	ldi	r24, 0x19	; 25
  70:	90 e0       	ldi	r25, 0x00	; 0
  72:	9b bd       	out	0x2b, r25	; 43
  74:	8a bd       	out	0x2a, r24	; 42

	while (1);
  76:	ff cf       	rjmp	.-2      	;  0x76
}

<exit>:
  78:	f8 94       	cli
  7a:	ff cf       	rjmp	.-2      	;  0x7a

 

If you upload that to an m32, you'll see the symptoms you've reported.  Specifically, you've enabled OCIE1A, but there is effectively no ISR since the vector table is the wrong.  Whenever the interrupt occurs, the result will be a 'soft reset'.  That is, the app will restart without the device actually experiencing a hardware reset.

 

I'm not really inclined to help you sort out what's going on until you can assure me wink that you're:

  1. building the code you say you're building
  2. building for the device you say you have
  3. actually uploading that built hex file to the device.

 

"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. Feb 7, 2018 - 03:07 AM
Top
avrcandies
avrcandies's picture
Level: Raving Lunatic
Joined: Wed. Jun 30, 2004
Posts: 6226 View posts
Location: Cincinnati Oh
Posted by avrcandies: Tue. Feb 6, 2018 - 01:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using studio7?  You can select the proper chip ("the target"), under your project properties.   The important thing is your program gets set up and compiled for the proper chip...a generated hex file can be programmed into any chip---but it is up to you to ensure it is based on the proper type.  The results can be like putting motor oil into the window washer tank.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Top
Avrduder
Avrduder's picture
Level: New Member
Joined: Sat. Feb 3, 2018
Posts: 5 View posts
Posted by Avrduder: Wed. Feb 7, 2018 - 02:00 AM (Reply to #17)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Turns out my makefile was not properly configured. Thank you all for taking a look. I've made sense of everything now.

 

 

Last Edited: Wed. Feb 7, 2018 - 01:59 AM
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101074 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Feb 7, 2018 - 10:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So you are using Linux rather than Windows? If you use Linux then get a sensible Makefile template here:

 

http://www.sax.de/~joerg/mfile/

 

The commands in that will have thought of loads of things you have never yet thought of!

Top