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

[Per Arnold Blåsmo]

I think I found out :-)
Just have to test it!

I did study the data sheets in more detail this weekend.
The processor has extended I/O like the atmega128 from 0x60 to 0xff.
My setup believes this is free SRAM.
So when moving data from FLASH to SRAM I move the data into extended I/O 
area.
That works ok since I am allowed to write to this area, until I reaches 
an I/O that has to do withe some stack limits.
Then I get a stack violation ;-) Of course :-)

So the question now is  how do I tell the  compiler that the start of 
SRAM is at 0x100?
Is this done in the linker script?

Per A.

E. Weddington wrote:

> Per Arnold Blåsmo wrote:
>
> > E. Weddington wrote:
> >
> > > Per Arnold Blåsmo wrote:
> > >
> > > > 00000030 <.do_copy_data_loop>:
> > > >  30:    05 90           lpm    r0, Z+
> > > >  32:    0d 92           st    X+, r0     <------This is where it 
> > > > crashes  X=0x00fe
> > >
> > > Ok. Shot in the dark:
> > > - Is this the *first* address that it is using? i.e. is this the 
> > > first time through the loop?
> > > - Does your device have that opcode variant?
> > No, it is not the first time trough the loop. I goes trough the loop 
> > approx. 150-160 times before it crashes.
> > What opcode variant?
>
>
> I was referring to whether it could execute a ST X+,R type 
> instruction. Obviously it can if it's going through the loop 150-160 
> times.
>
> IIRC, you're using a simulator/AVR Studio correct? That could very 
> well be an issue. Have you tried this on a real device yet?
>
> Of course, it's difficult to diagnose this while in the dark. :-/
>
> Eric

--
Per Arnold Blåsmo
Norbit AS
Stiklestadveien 1, 7041 Trondheim, Norway

Tel +47-73 98 25 57, Mob +47-901 63 657, Fax +47-972 45 736
e-mail: address@hidden
Get Thunderbird <http://www.mozilla.org/products/thunderbird/>