Mega1284P Timer3 Vector Created but not in Vector Table

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

I have a working Mega1284 project that was ported from a Mega32 project. Having done all the register corrections it compiles and runs.
Wishing to now use the Timer 3 compare interrupt, I discovered that the vector table always points to bad interrupt and resets when called.

The vector code itself is being created, but not put into the vector table.

I created a new small program to check and the same happens.

 

/*
 * GccApplication1.c
 *
 * Created: 02/06/2020 09:01:05
 * Author : Rob
 */ 

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

unsigned char overflow = 0;

void SaveToEEMem();

int main(void)
{
    /* Replace with your application code */
    while (1)
    {
    }
}

ISR (TIMER3_COMPA_vect )
{
	SREG &= ~0X80;	// Global Interrupt Disable
	SaveToEEMem();
	SREG |= 0X80;	// Global Interrupt Enable

}

void SaveToEEMem()
{
	 overflow++; // reset the pseudo watchdog count
}

 

 

from the disassembly the vector 00x42 jumps to the bad interrupt which jumps to 0x0052  back to reset

 

00000042 13.c0                RJMP PC+0x0014		Relative jump
00000043 00.00                NOP 		No operation
00000044 11.c0                RJMP PC+0x0012		Relative jump
00000045 00.00                NOP 		No operation
--- ../../../../crt1/gcrt1.S ---------------------------------------------------
00000046 11.24                CLR R1		Clear Register
00000047 1f.be                OUT 0x3F,R1		Out to I/O location
00000048 cf.ef                SER R28		Set Register
00000049 d0.e4                LDI R29,0x40		Load immediate
0000004A de.bf                OUT 0x3E,R29		Out to I/O location
0000004B cd.bf                OUT 0x3D,R28		Out to I/O location
--- No source file -------------------------------------------------------------
0000004C 21.e0                LDI R18,0x01		Load immediate
0000004D a0.e0                LDI R26,0x00		Load immediate
0000004E b1.e0                LDI R27,0x01		Load immediate
0000004F 01.c0                RJMP PC+0x0002		Relative jump
00000050 1d.92                ST X+,R1		Store indirect and postincrement
00000051 a1.30                CPI R26,0x01		Compare with immediate
00000052 b2.07                CPC R27,R18		Compare with carry
00000053 e1.f7                BRNE PC-0x03		Branch if not equal
00000054 02.d0                RCALL PC+0x0003		Relative call subroutine
00000055 35.c0                RJMP PC+0x0036		Relative jump
00000056 a9.cf                RJMP PC-0x0056		Relative jump  ** BACK TO RESET

All the other interrupts work in the original project, just the newly added Timer3.

I can see iom1284p being referenced int the project. 

 

What am I doing wrong?

Last Edited: Tue. Jun 2, 2020 - 09:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I built your code. The .LSS file has:

  7c:	17 c0       	rjmp	.+46     	; 0xac <__bad_interrupt>
  7e:	00 00       	nop
  80:	1d c0       	rjmp	.+58     	; 0xbc <__vector_32>
  82:	00 00       	nop
  84:	13 c0       	rjmp	.+38     	; 0xac <__bad_interrupt>
  86:	00 00       	nop
  88:	11 c0       	rjmp	.+34     	; 0xac <__bad_interrupt>

so the vector at 0x0080 is pointing to "__vector__32" then later in the code is:

000000bc <__vector_32>:
    {
    }
}

ISR (TIMER3_COMPA_vect )
{
  bc:	1f 92       	push	r1
  be:	0f 92       	push	r0
  c0:	0f b6       	in	r0, 0x3f	; 63
etc.

so that's pointing to the right place isn't it? From the device header...

<snip>

/* Timer/Counter3 Compare Match A */
#define TIMER3_COMPA_vect            _VECTOR(32)
#define TIMER3_COMPA_vect_num        32

/* Timer/Counter3 Compare Match B */
#define TIMER3_COMPB_vect            _VECTOR(33)
#define TIMER3_COMPB_vect_num        33

/* Timer/Counter3 Overflow */
#define TIMER3_OVF_vect            _VECTOR(34)
#define TIMER3_OVF_vect_num        34

#if (defined(__ASSEMBLER__) || defined(__IAR_SYSTEMS_ASM__))
#  define _VECTORS_SIZE 140
#else
#  define _VECTORS_SIZE 140U
#endif

So the T3_COMPA vector *is* the 3rd from the end. In your own disassembly you show:

00000042 13.c0                RJMP PC+0x0014		Relative jump
00000043 00.00                NOP 		No operation
00000044 11.c0                RJMP PC+0x0012		Relative jump
00000045 00.00                NOP 		No operation
--- ../../../../crt1/gcrt1.S ---------------------------------------------------
00000046 11.24                CLR R1		Clear Register

(note that the Atmel disassembler uses word addressing not byte addressing so 0x0042 here is 0x0084 in GCC) so you basically haven't shown enough context here. The vector you are hooking is immediately before this segment. (0040/0041)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
ISR (TIMER3_COMPA_vect )
{
	SREG &= ~0X80;	// Global Interrupt Disable
	SaveToEEMem();
	SREG |= 0X80;	// Global Interrupt Enable

}

By the way two things are wrong here. 

 

1) you don't need "SREG &= ~0x80" etc. The interrupt.h defines cli() and sei() for this purpose and are much clearer about what they are achieving (it's in the name!).

 

2) you should never use cli() and sei() in an ISR anyway. The AVR automatically does an implied CLI on it's way into an ISR() anyway so when you get into the ISR the I flag is already clear. But more than that you should never do SEI in an ISR. If you do there is a chance that the same interrupt may fire while the current one is handled (and during the handling of that it could be interrupted and so on ....). So just do:

ISR (TIMER3_COMPA_vect )
{
	SaveToEEMem();
}

and it will achieve what you want. But also try to avoid calling functions from ISRs. If you want to use this syntax then make SaveToEEMem() an "static inline" function.

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

Using SREG is habit.. it's copied very old code.

However, using sei() can be valid when the interrupt routine must give way to a higher priority interrupt if it unfortunately can't execute quick enough. I've used it cautiously when needed.

I can't remember why I did that in this particular bit of code however.

 

The function call was part of my attempt to see what was going wrong. Originally I used an 8 bit timer to check for a lack of interrupts forcing an eememory save.

Moving to the 1284, I have also moved up to 16Mhz ( from 8Mhz ) and the 8 bit timer I was using isn't large enough to do the count. Timer 3 was the saviour.. until now....:(

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

rowifi wrote:
. until now....:(
But as I showed above there is NO PROBLEM. The vector is being hooked just as you intended. So I suggest that if you have a problem then the source of that problem is something else.

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

Sorry Clawson..
Just read your first post. Somehow I've got my vectors mixed up in my mind...  let me go check what the hell I've doing. :)

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

Oh by the way, I don't know what use is being made of "overflow" in the real code. But if it's really incremented in the ISR then read in main() then:

unsigned char overflow = 0;

needs to be:

volatile unsigned char overflow = 0;

actually I would suggest:

volatile uint8_t overflow = 0;

Try to get into the habit of using <stdint.h> so variable widths are more obvious (and delivering what you really intend!)

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


 

I read and take onboard your comments thanks.. but what's with this from the datasheet?

 

The code jumps to vector 0x0042 when I allow this timer to get to its compare. The counter could indeed overflow because it's not being reset, but it was supposed to compare.

 

From AVR datasheet.  

 

 

 

 

Whats going on.. ? What am I missing here.

 

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

Vector numbers in the datasheet are '1' based. How does the header file define them?

 

[EDIT]

/* Interrupt Vectors */
/* Interrupt Vector 0 is the reset vector. */

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "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."

Last Edited: Tue. Jun 2, 2020 - 09:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


The datasheet numbers the vectors differently to GCC (offset by 1). Look at the start of the list:

 

 

and then look at the start of the list in GCC's .h file:

 

/* Vector 0 is the reset vector */
/* External Interrupt Request 0 */
#define INT0_vect            _VECTOR(1)
#define INT0_vect_num        1

/* External Interrupt Request 1 */
#define INT1_vect            _VECTOR(2)
#define INT1_vect_num        2

/* External Interrupt Request 2 */
#define INT2_vect            _VECTOR(3)
#define INT2_vect_num        3

/* Pin Change Interrupt Request 0 */
#define PCINT0_vect            _VECTOR(4)

Atmel choose to call "Reset" vector 1 even though it's not really an interrupt vector so they effectively start counting at 2 where 2 = INT0, 3, = INT1 etc.

 

GCC meanwhile uses what I personally think is a more sensible numbering scheme so the first real interrupt vector is 1, which makes 1 = INT0, 2 = INT1 etc.

 

But ignore the vector numbers now as that is a red herring (both the datasheet and the GCC ISR hooking scheme each know how they personally choose to interpret their own numbering schemes!). In stead look at the actual addresses. The table shows

TIMER3_CAPT  = 003E (word = 007C byte)
TIMER3_COMPA = 0040 (word = 0080 byte)
TIMER3_COMPB = 0042 (word = 0084 byte)
TIMER3_OVF   = 0044 (word = 0088 byte)

So the T3COMPA vector should be at 0040 if you look at it with Atmel's dreadful disassembler or 0080 if you use anything sensible. And that's exactly what you see. Like I say when you showed:

00000042 13.c0                RJMP PC+0x0014		Relative jump
00000043 00.00                NOP 		No operation
00000044 11.c0                RJMP PC+0x0012		Relative jump
00000045 00.00                NOP 		No operation
--- ../../../../crt1/gcrt1.S ---------------------------------------------------
00000046 11.24                CLR R1		Clear Register
00000047 1f.be                OUT 0x3F,R1		Out to I/O location

you were looking in the wrong place. This starts at 0042 but the vector you are hooking is at 0040 (even the datasheet admits this fact if it otherwise chooses to use some kind of nonsense vector numbering!)

 

One big question in all this is why in either scheme do they start counting at 1. Computer programmers usually count from 0 upwards !!

 

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

clawson wrote:

One big question in all this is why in either scheme do they start counting at 1. Computer programmers usually count from 0 upwards !!

 

Except when counting (physical) objects (I hope). How many programmers number their children from 0?

 

And yes, I know the counters in a 1284 start from number 0.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "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."

Last Edited: Tue. Jun 2, 2020 - 09:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahhhh..  So now I see what I've done!
I meant to use compare B, I enabled compare B, but I created vector Compare A.

Thanks everyone.. I will see if that fixes it!

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

Brian Fairchild wrote:
How many programmers number their children from 0?
Well me for one! Thankfully I haven't got any ;-)

 

But I tend to think of interrupt vectors as an "array" so to me it seems natural to call the first index 0. YMMV.

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

clawson wrote:
it seems natural to call the first index 0. 

Indeed.

 

Or just think of it as an offset from the start of the table ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
Except when counting (physical) objects

I disagree.

If you are measuring an angle, on my protractor, the first position is "0"!

Look at a ruler or tape measure, there is no number (at least on mine) at the beginning. The number "1" is one unit away from the start. So the start is 0 smiley

 

 

David

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

we'll be arguing whether 2000 or 2001 was the start of this millennium next ...

 

(he says, retreating to a safe distance)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Brian Fairchild wrote:

How many programmers number their children from 0?

Well me for one! Thankfully I haven't got any ;-)

That's not so much the 0th child as the 'null set' ;-)

"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

rowifi wrote:
Whats going on.. ? What am I missing here.

Tell us which datasheet you are looking at

Show us your build results.  That will tell us much information unknown at this point.  Toolchain; version; build options; target; ...

As it is a small test program, show the complete .LSS

 

With all the needed information, the end should be near.

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:

As it is a small test program, show the complete .LSS

 

Disassembly of section .text:

00000000 <__vectors>:
   0:	45 c0       	rjmp	.+138    	; 0x8c <__ctors_end>
   2:	00 00       	nop
   4:	53 c0       	rjmp	.+166    	; 0xac <__bad_interrupt>
   6:	00 00       	nop
   8:	51 c0       	rjmp	.+162    	; 0xac <__bad_interrupt>
   a:	00 00       	nop
   c:	4f c0       	rjmp	.+158    	; 0xac <__bad_interrupt>
   e:	00 00       	nop
  10:	4d c0       	rjmp	.+154    	; 0xac <__bad_interrupt>
  12:	00 00       	nop
  14:	4b c0       	rjmp	.+150    	; 0xac <__bad_interrupt>
  16:	00 00       	nop
  18:	49 c0       	rjmp	.+146    	; 0xac <__bad_interrupt>
  1a:	00 00       	nop
  1c:	47 c0       	rjmp	.+142    	; 0xac <__bad_interrupt>
  1e:	00 00       	nop
  20:	45 c0       	rjmp	.+138    	; 0xac <__bad_interrupt>
  22:	00 00       	nop
  24:	43 c0       	rjmp	.+134    	; 0xac <__bad_interrupt>
  26:	00 00       	nop
  28:	41 c0       	rjmp	.+130    	; 0xac <__bad_interrupt>
  2a:	00 00       	nop
  2c:	3f c0       	rjmp	.+126    	; 0xac <__bad_interrupt>
  2e:	00 00       	nop
  30:	3d c0       	rjmp	.+122    	; 0xac <__bad_interrupt>
  32:	00 00       	nop
  34:	3b c0       	rjmp	.+118    	; 0xac <__bad_interrupt>
  36:	00 00       	nop
  38:	39 c0       	rjmp	.+114    	; 0xac <__bad_interrupt>
  3a:	00 00       	nop
  3c:	37 c0       	rjmp	.+110    	; 0xac <__bad_interrupt>
  3e:	00 00       	nop
  40:	35 c0       	rjmp	.+106    	; 0xac <__bad_interrupt>
  42:	00 00       	nop
  44:	33 c0       	rjmp	.+102    	; 0xac <__bad_interrupt>
  46:	00 00       	nop
  48:	31 c0       	rjmp	.+98     	; 0xac <__bad_interrupt>
  4a:	00 00       	nop
  4c:	2f c0       	rjmp	.+94     	; 0xac <__bad_interrupt>
  4e:	00 00       	nop
  50:	2d c0       	rjmp	.+90     	; 0xac <__bad_interrupt>
  52:	00 00       	nop
  54:	2b c0       	rjmp	.+86     	; 0xac <__bad_interrupt>
  56:	00 00       	nop
  58:	29 c0       	rjmp	.+82     	; 0xac <__bad_interrupt>
  5a:	00 00       	nop
  5c:	27 c0       	rjmp	.+78     	; 0xac <__bad_interrupt>
  5e:	00 00       	nop
  60:	25 c0       	rjmp	.+74     	; 0xac <__bad_interrupt>
  62:	00 00       	nop
  64:	23 c0       	rjmp	.+70     	; 0xac <__bad_interrupt>
  66:	00 00       	nop
  68:	21 c0       	rjmp	.+66     	; 0xac <__bad_interrupt>
  6a:	00 00       	nop
  6c:	1f c0       	rjmp	.+62     	; 0xac <__bad_interrupt>
  6e:	00 00       	nop
  70:	1d c0       	rjmp	.+58     	; 0xac <__bad_interrupt>
  72:	00 00       	nop
  74:	1b c0       	rjmp	.+54     	; 0xac <__bad_interrupt>
  76:	00 00       	nop
  78:	19 c0       	rjmp	.+50     	; 0xac <__bad_interrupt>
  7a:	00 00       	nop
  7c:	17 c0       	rjmp	.+46     	; 0xac <__bad_interrupt>
  7e:	00 00       	nop
  80:	1d c0       	rjmp	.+58     	; 0xbc <__vector_32>
  82:	00 00       	nop
  84:	13 c0       	rjmp	.+38     	; 0xac <__bad_interrupt>
  86:	00 00       	nop
  88:	11 c0       	rjmp	.+34     	; 0xac <__bad_interrupt>
	...

0000008c <__ctors_end>:
  8c:	11 24       	eor	r1, r1
  8e:	1f be       	out	0x3f, r1	; 63
  90:	cf ef       	ldi	r28, 0xFF	; 255
  92:	d0 e4       	ldi	r29, 0x40	; 64
  94:	de bf       	out	0x3e, r29	; 62
  96:	cd bf       	out	0x3d, r28	; 61

00000098 <__do_clear_bss>:
  98:	21 e0       	ldi	r18, 0x01	; 1
  9a:	a0 e0       	ldi	r26, 0x00	; 0
  9c:	b1 e0       	ldi	r27, 0x01	; 1
  9e:	01 c0       	rjmp	.+2      	; 0xa2 <.do_clear_bss_start>

000000a0 <.do_clear_bss_loop>:
  a0:	1d 92       	st	X+, r1

000000a2 <.do_clear_bss_start>:
  a2:	a1 30       	cpi	r26, 0x01	; 1
  a4:	b2 07       	cpc	r27, r18
  a6:	e1 f7       	brne	.-8      	; 0xa0 <.do_clear_bss_loop>
  a8:	02 d0       	rcall	.+4      	; 0xae <main>
  aa:	35 c0       	rjmp	.+106    	; 0x116 <_exit>

000000ac <__bad_interrupt>:
  ac:	a9 cf       	rjmp	.-174    	; 0x0 <__vectors>

000000ae <main>:
unsigned char overflow = 0;

void SaveToEEMem();

int main(void)
{
  ae:	ff cf       	rjmp	.-2      	; 0xae <main>

000000b0 <SaveToEEMem>:

}

void SaveToEEMem()
{
	 overflow++; // reset the pseudo watchdog count
  b0:	80 91 00 01 	lds	r24, 0x0100	; 0x800100 <__DATA_REGION_ORIGIN__>
  b4:	8f 5f       	subi	r24, 0xFF	; 255
  b6:	80 93 00 01 	sts	0x0100, r24	; 0x800100 <__DATA_REGION_ORIGIN__>
  ba:	08 95       	ret

000000bc <__vector_32>:
    {
    }
}

ISR (TIMER3_COMPA_vect )
{
  bc:	1f 92       	push	r1
  be:	0f 92       	push	r0
  c0:	0f b6       	in	r0, 0x3f	; 63
  c2:	0f 92       	push	r0
  c4:	11 24       	eor	r1, r1
  c6:	0b b6       	in	r0, 0x3b	; 59
  c8:	0f 92       	push	r0
  ca:	2f 93       	push	r18
  cc:	3f 93       	push	r19
  ce:	4f 93       	push	r20
  d0:	5f 93       	push	r21
  d2:	6f 93       	push	r22
  d4:	7f 93       	push	r23
  d6:	8f 93       	push	r24
  d8:	9f 93       	push	r25
  da:	af 93       	push	r26
  dc:	bf 93       	push	r27
  de:	ef 93       	push	r30
  e0:	ff 93       	push	r31
	SREG &= ~0X80;	// Global Interrupt Disable
  e2:	8f b7       	in	r24, 0x3f	; 63
  e4:	8f 77       	andi	r24, 0x7F	; 127
  e6:	8f bf       	out	0x3f, r24	; 63
	SaveToEEMem();
  e8:	e3 df       	rcall	.-58     	; 0xb0 <SaveToEEMem>
	SREG |= 0X80;	// Global Interrupt Enable
  ea:	8f b7       	in	r24, 0x3f	; 63
  ec:	80 68       	ori	r24, 0x80	; 128
  ee:	8f bf       	out	0x3f, r24	; 63

}
  f0:	ff 91       	pop	r31
  f2:	ef 91       	pop	r30
  f4:	bf 91       	pop	r27
  f6:	af 91       	pop	r26
  f8:	9f 91       	pop	r25
  fa:	8f 91       	pop	r24
  fc:	7f 91       	pop	r23
  fe:	6f 91       	pop	r22
 100:	5f 91       	pop	r21
 102:	4f 91       	pop	r20
 104:	3f 91       	pop	r19
 106:	2f 91       	pop	r18
 108:	0f 90       	pop	r0
 10a:	0b be       	out	0x3b, r0	; 59
 10c:	0f 90       	pop	r0
 10e:	0f be       	out	0x3f, r0	; 63
 110:	0f 90       	pop	r0
 112:	1f 90       	pop	r1
 114:	18 95       	reti

00000116 <_exit>:
 116:	f8 94       	cli

00000118 <__stop_program>:
 118:	ff cf       	rjmp	.-2      	; 0x118 <__stop_program>

PS when SaveToEEMem() is switched to static inline the ISR() becomes a much more reasonable:

000000b0 <__vector_32>:
    {
    }
}

ISR (TIMER3_COMPA_vect )
{
  b0:	1f 92       	push	r1
  b2:	0f 92       	push	r0
  b4:	0f b6       	in	r0, 0x3f	; 63
  b6:	0f 92       	push	r0
  b8:	11 24       	eor	r1, r1
  ba:	8f 93       	push	r24
	SREG &= ~0X80;	// Global Interrupt Disable
  bc:	8f b7       	in	r24, 0x3f	; 63
  be:	8f 77       	andi	r24, 0x7F	; 127
  c0:	8f bf       	out	0x3f, r24	; 63

}

static inline void SaveToEEMem()
{
	 overflow++; // reset the pseudo watchdog count
  c2:	80 91 00 01 	lds	r24, 0x0100	; 0x800100 <__DATA_REGION_ORIGIN__>
  c6:	8f 5f       	subi	r24, 0xFF	; 255
  c8:	80 93 00 01 	sts	0x0100, r24	; 0x800100 <__DATA_REGION_ORIGIN__>

ISR (TIMER3_COMPA_vect )
{
	SREG &= ~0X80;	// Global Interrupt Disable
	SaveToEEMem();
	SREG |= 0X80;	// Global Interrupt Enable
  cc:	8f b7       	in	r24, 0x3f	; 63
  ce:	80 68       	ori	r24, 0x80	; 128
  d0:	8f bf       	out	0x3f, r24	; 63

}
  d2:	8f 91       	pop	r24
  d4:	0f 90       	pop	r0
  d6:	0f be       	out	0x3f, r0	; 63
  d8:	0f 90       	pop	r0
  da:	1f 90       	pop	r1
  dc:	18 95       	reti

While the SREG manipulation should probably be dropped all together, if just changed to cli() and sei() then it further becomes:

000000b0 <__vector_32>:
    {
    }
}

ISR (TIMER3_COMPA_vect )
{
  b0:	1f 92       	push	r1
  b2:	0f 92       	push	r0
  b4:	0f b6       	in	r0, 0x3f	; 63
  b6:	0f 92       	push	r0
  b8:	11 24       	eor	r1, r1
  ba:	8f 93       	push	r24
	cli();	// Global Interrupt Disable
  bc:	f8 94       	cli

}

static inline void SaveToEEMem()
{
	 overflow++; // reset the pseudo watchdog count
  be:	80 91 00 01 	lds	r24, 0x0100	; 0x800100 <__DATA_REGION_ORIGIN__>
  c2:	8f 5f       	subi	r24, 0xFF	; 255
  c4:	80 93 00 01 	sts	0x0100, r24	; 0x800100 <__DATA_REGION_ORIGIN__>

ISR (TIMER3_COMPA_vect )
{
	cli();	// Global Interrupt Disable
	SaveToEEMem();
	sei();	// Global Interrupt Enable
  c8:	78 94       	sei

}
  ca:	8f 91       	pop	r24
  cc:	0f 90       	pop	r0
  ce:	0f be       	out	0x3f, r0	; 63
  d0:	0f 90       	pop	r0
  d2:	1f 90       	pop	r1
  d4:	18 95       	reti

 

Last Edited: Wed. Jun 3, 2020 - 08:18 AM