RE: [avr-gcc-list] Problem with atmega162 timer interrupt

[Henko Gouws]

Hi Eric

Thank you for the feedback.

I use a Makefile that I got from an example that came with the portable
WinAvr and it seems to me there is a variable called MCU that gets set to
whatever cpu you choose and then elsewhere in the makefile this is used for
compile and link switches like this:

-mmcu=$(MCU)

So I assume it should be correct?

I even tried:
#if defined (__AVR_ATmega162__)
...
#endif...

...type constructs in the C code to make sure the compiler interprets the
MCU var correctly.

I am not so sure of the linking part though except that it seems this is
being done in the Makefile by the comment:
# Link: create ELF output file from object files.
and then
$(CC) $(ALL_CFLAGS) $^ --output $@ $(LDFLAGS)...
...and the ALL_CFLAGS var contains the -mmcu=$(MCU)part.

The output of the linking part looks like this:
>>>>>>
Linking: toggleNew2.elf
avr-gcc -mmcu=atmega162 -minit-stack=0x7FFF -I. -gdwarf-2 -DF_CPU=16000000UL
 -Os
 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wst
rict
-prototypes -Wundef -Wa,-adhlns=obj/toggleNew2.o  -std=gnu99 -Wundef -MD -MP
 -MF
 .dep/toggleNew2.elf.d obj/toggleNew2.o --output
toggleNew2.elf -Wl,-Map=toggleN
ew2.map,--cref -Xlinker --defsym -Xlinker
__init_wdtcr__=0x00 -Xlinker --defsym
-Xlinker __init_mcucr__=0x80 -Wl,-Tdata=0x801000 -Xlinker --defsym -Xlinker
__he
ap_start=0x803fff -Xlinker --defsym -Xlinker
__heap_end=0x805fff -Xlinker --defs
ym -Xlinker __stack=0x7fff   -lm
obj/toggleNew2.o: In function ...:
>>>>>>

Is this correct?

regards
Henko

-----Original Message-----
From: Eric Weddington [mailto:address@hidden
Sent: Monday, August 13, 2007 11:21 PM
To: 'Henko Gouws'; address@hidden
Subject: RE: [avr-gcc-list] Problem with atmega162 timer interrupt




> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Henko Gouws
> Sent: Monday, August 13, 2007 3:07 PM
> To: address@hidden
> Subject: [avr-gcc-list] Problem with atmega162 timer interrupt
>
> Hi
>
> I have used the 90s8515 for a home alarm system and it worked
> fine.  I used
> a timer0 overflow to emulate a simple scheduler etc.  The
> 90s8515 ran out of
> code space (8k) and I had to switch to the atmega162 to
> handle more sensors
> and conditions.
>
> After encountering some porting problems I just wrote a small
> program that
> toggles an LED.  This program worked on the 90s8515.  It does
> not work on
> the atmega162.  If I use timing loops (not timer 0) then the
> LED toggles
> nicely.  As soon as I call sei() then nothing seems to happen
> - even if the
> timing loops are present - I assume that the interrupt prolog
> and epilog
> might be incorrect and might cause the processor to hang or
> reset.  I do not
> have an ICE.
>
> Has anyone had similar problems with the atmega162 before?  I
> am using the
> portable winavr (last updated in April 2006 I think) and this
> compiler has
> worked well with the at90s8515.
>
> I have verified that the mcu = atmega162 works because the
> old register
> names of the 90s8515 are not accepted.
>
> If I understand correctly: There seems to be a difference in
> the interrupt
> vectors of the atmega162 and the 90s8515 - the 90s8515
> interrupt vectors are
> short vectors of 8bit each and the atmega162 vectors are 16
> bit vectors.
> Could this be the reason?

Are you correctly setting the -mmcu=<device> flag to the correct device on
both your compile and link command lines?

Eric