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

[Ben L. Titzer]

> > > 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?
> > >
> > > Eric
> > >
> > > _______________________________________________
> > > avr-gcc-list mailing list
> > > address@hidden
> > > http://www.avr1.org/mailman/listinfo/avr-gcc-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.

-B

> Disassembly of section .text:
>
> 00000000 <__vectors>:
>   0:    0c 94 0e 00     jmp    0x1c
>   4:    0c 94 27 00     jmp    0x4e
>   8:    0c 94 27 00     jmp    0x4e
>   c:    0c 94 27 00     jmp    0x4e
>  10:    0c 94 27 00     jmp    0x4e
>  14:    0c 94 27 00     jmp    0x4e
>  18:    0c 94 27 00     jmp    0x4e
>
> 0000001c <__ctors_end>:
>  1c:    11 24           eor    r1, r1
>  1e:    1f be           out    0x3f, r1    ; 63
>  20:    cf ef           ldi    r28, 0xFF    ; 255
>  22:    cd bf           out    0x3d, r28    ; 61
>
> 00000024 <__do_copy_data>:
>  24:    12 e0           ldi    r17, 0x02    ; 2
>  26:    a0 e6           ldi    r26, 0x60    ; 96
>  28:    b0 e0           ldi    r27, 0x00    ; 0
>  2a:    ec e2           ldi    r30, 0x2C    ; 44
>  2c:    fe e0           ldi    r31, 0x0E    ; 14
>  2e:    02 c0           rjmp    .+4          ; 0x34
>
> 00000030 <.do_copy_data_loop>:
>  30:    05 90           lpm    r0, Z+
>  32:    0d 92           st    X+, r0     <------This is where it 
> crashes  X=0x00fe
>
> 00000034 <.do_copy_data_start>:
>  34:    a6 38           cpi    r26, 0x86    ; 134
>  36:    b1 07           cpc    r27, r17
>  38:    d9 f7           brne    .-10         ; 0x30
>
> 0000003a <__do_clear_bss>:
>  3a:    13 e0           ldi    r17, 0x03    ; 3
>  3c:    a6 e8           ldi    r26, 0x86    ; 134
>  3e:    b2 e0           ldi    r27, 0x02    ; 2
>  40:    01 c0           rjmp    .+2          ; 0x44
>
> Per A.
> --
> Per Arnold Blåsmo
> e-mail: address@hidden
> Get Thunderbird <http://www.mozilla.org/products/thunderbird/>
========================================================
Whenever anyone says, "theoretically," they really mean, "not really."
--Dave Parnas