[Top][All Lists]

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

Re: [avr-gcc-list] New prosessor goes into stack violation!

From: Per Arnold Blåsmo
Subject: Re: [avr-gcc-list] New prosessor goes into stack violation!
Date: Fri, 07 Jan 2005 21:14:53 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

Ben L. Titzer wrote:

Could this address be in the interrupt vector table for the device?

Perhaps your header file did not properly account for all the vectors or all the correct defintions?


avr-gcc-list mailing list

I was born not knowing and have had only a little time to change that here and there.
--Richard Feynman

No, this address is not, as I can understand, in the interrupt vector table. There are relatively few interrupt vector in this processor compared to the ordinary AVR processors. Since it originally is used in smart card applications it also has very limited I/O.

Since this is in the startup code and no calls or anything has been done, the SP has not changed from its initial value. The only thing it has done some far is to set the SP and start copying from the end of the program area in flash to SRAM.

As you can see from the disassembly this is ordinary avr-gcc startup code:

The interrupt vector table is in flash anyway, and ST writes to SRAM, so this shouldn't have anything to do with interrupts. Sorry I have to ask again, but what is the actual value of SP when the store occurs?

BTW, how much RAM does this particular chip have? The AT90 series had a maximum of 512b IIRC.

It may be that your program simply will no longer fit in the RAM of the chip.


The SP is 0xcff which is the top of the RAM. The chip has 3 kbyte SRAM. Since it only has moved about 150-160 bytes before it happends there should be plenty of SRAM left.

Per A.

Per Arnold Blåsmo
e-mail: address@hidden
Get Thunderbird <http://www.mozilla.org/products/thunderbird/>

reply via email to

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