avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] RE: avr-gcc-list Digest, Vol 22, Issue 4


From: wbounce
Subject: [avr-gcc-list] RE: avr-gcc-list Digest, Vol 22, Issue 4
Date: Thu, 4 Nov 2004 19:19:16 -0500

If you enable interrupts an encounter an interrupt you do not have a
routine for it calls the default one. If you do not have a default one
it resets so I just put this dummy code in my programs. I think you
could just have the function with no code. Try it and see what happens

SIGNAL(__vector_default)
{
// user code here
  uint8_t i;
i=1;
}

-----Original Message-----
Date: Thu, 04 Nov 2004 09:42:16 +1100
From: Curtis Maloney <address@hidden>
To: address@hidden
Subject: [avr-gcc-list] Problems porting from CodeVisionAVR to WinAVR
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 3


Greetings,

        We've recently decided to migrate all of our AVR development to
avr-gcc, for 
various reasons.

        We figured as a good exercise we'd port some existing, working
code from cvavr. 
  And weren't there some differences.

        No longer the handy notation of PORTx.y for accessing port pins,
and declaring 
interrupts is a little different, but in general the changes have been
simple 
and minor.

        However, this has not yet resulted in success.  For some reason,
whenever we 
enable the Timer 0 Overflow interrupt, the setup resets.  Not
immediately, of 
course, but after the timer expires.

        So far, I've checked we're not overflowing the stack, ensured
the correct 
signal declaration is included, ensured the binary is being generated 
correctly... it just seems it's never hitting the interrupt (even put
"UDR = 
'!'" as the first instruction in the handler... no luck).

        So it looks to me like it's hitting the generic bad interrupt
handler.  But 
providing a __vector_default function still doesn't result in any
noticeable output.

        Anything else I can test/check?  This hardware does work with
the CVAVR 
generated code.

--
Curtis Maloney

------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]