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

[Per Arnold Blåsmo]

Marek Michalkiewicz wrote:

> Hi,
>
> On Fri, Jan 07, 2005 at 12:05:26PM +0100, Per Arnold Bl?smo wrote:
>
>  
>
> > It happens when the operation 'ST X+, R0' executes and X=0x00fe.
> >    
>
> If this is a "secure" chip, perhaps it has some memory protection
> features?  This would make sense - preventing buffer overflow
> exploits overwriting the stack.  Hard to tell without the datasheet,
> but I don't see any other reason for a "crash" in startup code...
>
> Perhaps the IAR startup code sets up some registers (which control
> the address range of protected memory, or something like that -
> again, just guessing since I don't have the datasheet...) before
> data and bss initialization?
>
> The problem is that datasheets for these secure chips are under NDA
> (It seems that Atmel believes in "security through obscurity"...),
> so getting them may require some industrial espionage ;)
>
> Hope this helps,
> Marek
>
>
>  
I might be some memory  protection, but I do not see that this is it.

In the example startup code it:
1. Hardware Stack Pointer initialization (SP)
2. Initializes something it refers to as the CSTACK  ("C Stack Pointer 
initialization (Y)")
3. Inits the random generator (or it can be other parts of the chip)
4. calls __segment_init which is standard IAR runtime. This is where it 
does the same as avr-gcc is trying to do, copy data from flash to SRAM.
5. calls main

The init of the random generator I will have to put in on of the .initN 
sections, but I will do that later.
The only thing I see different is the CSTACK init. I am not sure why or 
what this is.

I know some of this stuff is NDA, and will not and cant not show the 
example code nor the data sheets.
But I can discuss basic elements :-)


Per A.

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