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

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

Re: [avr-gcc-list] atmega128 & external SRAM problem - Tracking down the


From: Brett Abbott
Subject: Re: [avr-gcc-list] atmega128 & external SRAM problem - Tracking down the reboot fault quickly
Date: Wed, 16 Oct 2002 08:29:26 +1300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1

Hi

A quick (and simple) trick is to use the following approach.  I have included a debug section of code which lists all interupts.  Set a breakpoint on each abort(); within each interupt routine and use the simulator to test your code.  Obviously delete those already defined elsewhere.  You will need to alter the names of the signals to suit your particular chip.  The ones shown below are for the 161.

This quickly shows up the interupts causing most of your reboot problems.

Signal names for your chip can be found in avr/include/*.h , for the 161, see <iom161.h>

Cheers
Brett

/*================ Shell Signals to trap events during debugging ================== */
#if DTL_ENVIRONMENT == DTL_STUDIO_355
SIGNAL(SIG_INTERRUPT0)
{
abort();
}
SIGNAL(SIG_INTERRUPT1)
{
abort();
}
SIGNAL(SIG_INTERRUPT2)
{
abort();
}
SIGNAL(SIG_OUTPUT_COMPARE2)
{
abort();
}
SIGNAL(SIG_INPUT_CAPTURE1)
{
abort();
}
SIGNAL(SIG_OUTPUT_COMPARE1B)
{
abort();
}
SIGNAL(SIG_OVERFLOW1)
{
abort();
}
SIGNAL(SIG_OUTPUT_COMPARE0)
{
abort();
}
SIGNAL(SIG_OVERFLOW0)
{
abort();
}
SIGNAL(SIG_SPI)
{
abort();
}
SIGNAL(SIG_EEPROM_READY)
{
abort();
}
SIGNAL(SIG_COMPARATOR)
{
abort();
}
SIGNAL(SIG_OUTPUT_COMPARE1A)
{
abort();
}
SIGNAL(SIG_UART0_RECV)
{
abort();
}
SIGNAL(SIG_UART1_RECV)
{
abort();
}
SIGNAL(SIG_UART0_TRANS)
{
abort();
}
SIGNAL(SIG_UART1_DATA)
{
abort();
}
SIGNAL(SIG_OVERFLOW2) 
{
abort();
}

#endif


Joerg Wunsch wrote:
"Frank Siegemund" <address@hidden> wrote:

However, when I run a small test program, it just reboots after a
short time indicating that the additional SRAM cannot be accessed.

Are you sure with your analysis?

The reboot could also happen if you accidentally trigger an interrupt
that doesn't have a vector assigned in your application. Since you
didn't post all of your application (but enough to see that interrupts
are enabled ;-), it's not clear whether you didn't make an error there
(e. g. like mistyping the name of the interrupt function).


-- 
-----------------------------------------------------------------
Brett Abbott, Managing Director, Digital Telemetry Limited
Email: address@hidden
PO Box 24 036 Manners Street, Wellington, New Zealand
Phone +64 (4) 5666-860  Mobile +64 (21) 656-144
------------------- Commercial in confidence --------------------


reply via email to

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