RE: [avr-gcc-list] avr-gcc 4.2.2 atmega 2561 issues

[Stu Bell]

I assume you are using the latest/greatest version (either WinAVR
20081205 or the equivalent).

I also came across this and I believe I wrote a bug report on it.  IIRC,
the issue is that the library was compiled with a switch that tells the
compiler to use a prologue routine rather than inlining the prologue.
That makes sense for ATTinys but causes us in the mega2560 headaches.
The problem is that the prologue routine, as you noted, assumes that
it's current location is the proper "page" for the eijump.  To fix it
permanently I think the prologue call would somehow have to encode the
return address' page.  This is all from memory, so it may be wrong.

Again, IIRC, I solved it by re-arranging the code map to avoid the
victim routines straddling the 128K boundary.  That can be done easily
enough by re-arranging the list of objects handed to the linker. It
links them in order that the object files are listed.

You can also download the source to avr-libc and compile it yourself
using the appropriate flags.  Of course, you would need to do that every
time you updated the WinAVR/avr-libc stuff.

Unfortunately there is no simple fix to the problem.  Or maybe there is,
and I can't remember what I did.

Best regards, 

Stu Bell 
DataPlay (DPHI, Inc.) 

 

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden 
> On Behalf Of Simon Eatough
> Sent: Monday, December 15, 2008 7:50 PM
> To: address@hidden
> Subject: [avr-gcc-list] avr-gcc 4.2.2 atmega 2561 issues
> 
> Hi folks
> I've got a project where the code has just crossed the 
> dreaded 128k boundary. 
> Specifically glibc straddles the boundary. 
> I've got problems with the code crashing,  due i think to 
> call of si_to_float in libgcc  which sets up the Z register 
> for the eijmp in __prolog_saves__  ,but does not set EIND . 
> causing the eijmp instruction to jump to the wrong address.
> 
> disassembly below.
> 
> si_to_float (SItype arg_a)
> {
>    1fee4:   a8 e0           ldi r26, 0x08   ; 8
>    1fee6:   b0 e0           ldi r27, 0x00   ; 0
>    1fee8:   e8 e7           ldi r30, 0x78   ; 120
>    1feea:   ff ef           ldi r31, 0xFF   ; 255
>    1feec:   0d 94 7f 04     jmp 0x208fe ; 0x208fe 
> <__prologue_saves__+0x12>
>    1fef0:   9b 01           movw    r18, r22
>    1fef2:   ac 01           movw    r20, r24
>   fp_number_type in;
> 
> /snip
> 
> 
> 000208ec <__prologue_saves__>:
>    208ec:   2f 92           push    r2
>    208ee:   3f 92           push    r3
>    208f0:   4f 92           push    r4
>    208f2:   5f 92           push    r5
>    208f4:   6f 92           push    r6
>    208f6:   7f 92           push    r7
>    208f8:   8f 92           push    r8
>    208fa:   9f 92           push    r9
>    208fc:   af 92           push    r10
>    208fe:   bf 92           push    r11
>    20900:   cf 92           push    r12
>    20902:   df 92           push    r13
>    20904:   ef 92           push    r14
>    20906:   ff 92           push    r15
>    20908:   0f 93           push    r16
>    2090a:   1f 93           push    r17
>    2090c:   cf 93           push    r28
>    2090e:   df 93           push    r29
>    20910:   cd b7           in  r28, 0x3d   ; 61
>    20912:   de b7           in  r29, 0x3e   ; 62
>    20914:   ca 1b           sub r28, r26
>    20916:   db 0b           sbc r29, r27
>    20918:   0f b6           in  r0, 0x3f    ; 63
>    2091a:   f8 94           cli
>    2091c:   de bf           out 0x3e, r29   ; 62
>    2091e:   0f be           out 0x3f, r0    ; 63
>    20920:   cd bf           out 0x3d, r28   ; 61
>    20922:   19 94           eijmp
> 
> 
> Wonder if there is a workaround for this ?
> 
> Cheers
> Simon
> 
> 
> --
> Simon Eatough
> Development Engineer
> Pertronic Industries
> Wellington NZ
> 
> 
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>