ATmega 2561 - compiler generates eicall

[Dusan Ferbas]

Hi,

I am using WinAVR-20071221, because none of the most recent
toolchains produces a runnable code for our application.

Our bootloader starts at 0x3f800 (2kB).
In its code, we are using function[id](...) construction.
This is compiled with eicall instruction, but no EIND register is set.
Is there a way, how to tell the compiler, that code is linked in
upper half of flash ?
In bootloader code we can live with EIND=1 at its init.

But when we have a call from our application, neither EIND is set,
even address is not divided by 2 (WinAVR bug #1959227).
Probably some far attribute should be applied ?
When compiled for ATmega128 (with 0x1f806), it works ...

typedef void boot_loader_init(unsigned  char *);
#define boot_loader_data_init           ((boot_loader_init *)0x3F806)
...
   boot_loader_data_init(buffer);
...


Dusan  



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Stu Bell]

By the addresses it appears that you are using an ATmega2560 or 2561.
You are trying to use function pointers for upper flash (beyond the 128
Kbyte/64 Kword boundary).

The current GCC compiler does not know how to do this.  Function
pointers are kept as 2 byte entities.  While static (non-pointer)
function calls are dealt with using a neat device called a "trampoline"
(essentially a table of eijmps that the local function can call),
function pointers do not use this device.

I have the same problem and have resolved it by assigning all of my
pointer targets *and callers* into a separate linker section that is
forced into the lower part of flash.  I have the following macro:

   #define COMMAND_HANDLER   __attribute__ ((section (".fptr_target")))

Which I append to each function target prototype, for example:

CmdError CmdInitTrack( CmdPacket* pCmdPkt ) COMMAND_HANDLER;


Then, I created a custom linker script from avr6.x to place this section
in low flash:

. . .
  /* Internal text space or external memory.  */
  .text :
  {
. . .
    KEEP (*(.init8))
    *(.init9)  /* Call main().  */
    KEEP (*(.init9))
    /* Interrupt Service Routine code needs to be in the lower 128K
program */
    *(.isr)
    KEEP(*(.isr))
    /* Any code that is the target of a function pointer must also
       reside in lower memory */
    *(.fptr_target)
    KEEP(*(.fptr_target))
    /* An RTOS task should also be in low mmeory. */
    *(.task)
    KEEP(*(.task))
    /* Main code starts here - this code can oveflow into the upper 128K
program */
    *(.text)
    . = ALIGN(2);
    *(.text.*)
    . = ALIGN(2);
    *(.fini9)  /* _exit() starts here.  */
. . .


As you may notice, there are also two other custom sections, .isr and
.task.  All ISRs go into the .isr section for the same reason as the
function pointer targets -- the vector table will default jump only to
the low part of flash.  I accomplished this by having the following
macro:

    #define ISR_SECTION __attribute__ ((section (".isr")))

And making all of my ISR declarations...

    ISR( TIMER_OVERFLOW_SIG, ISR_BLOCK ISR_SECTION )

(Note the lack of a comma between ISR_BLOCK and ISR_SECTION -- not sure
why that must be, but it did not compile if a comma was there.)

The .task section is for RTOS task functions.  Since the tasks are
created at run time by pssing a function pointer to the task creation
mechanism, they fall under the same rules as the function pointers.

Using these techniques I have been able to get my code running under
WinAVR 20080521.  Hopefully, you can to.

Best of luck!


Best regards,

Stu Bell
DataPlay (DPHI, Inc.)


-----Original Message-----
From: avr-gcc-list-bounces+sbell=dataplay.com@...
[mailto:avr-gcc-list-bounces+sbell=dataplay.com@...] On Behalf Of
Dusan Ferbas
Sent: Tuesday, June 03, 2008 5:36 PM
To: avr-gcc-list@...
Subject: [avr-gcc-list] ATmega 2561 - compiler generates eicall

Hi,

I am using WinAVR-20071221, because none of the most recent toolchains
produces a runnable code for our application.

Our bootloader starts at 0x3f800 (2kB).
In its code, we are using function[id](...) construction.
This is compiled with eicall instruction, but no EIND register is set.
Is there a way, how to tell the compiler, that code is linked in upper
half of flash ?
In bootloader code we can live with EIND=1 at its init.

But when we have a call from our application, neither EIND is set, even
address is not divided by 2 (WinAVR bug #1959227).
Probably some far attribute should be applied ?
When compiled for ATmega128 (with 0x1f806), it works ...

typedef void boot_loader_init(unsigned  char *);
#define boot_loader_data_init           ((boot_loader_init *)0x3F806)
...
   boot_loader_data_init(buffer);
...


Dusan  



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Stu Bell]

Dang, it would help if I read the entire message.

Function pointers in the bootloader. I kept my bootloader
mind-bogglingly simple precisely to avoid problems like this.
Unfortunately, many folks have a need for a far more comples bootloader
than I need.

Since the eicall is being used, why not force EIND to 1 at the beginning
of your code...

    asm volatile ( "ldi  r24, 0x01 \n\t"
                   "out  0x3C, r24 \n\t"
                 );

Worth a shot, eh?

Best regards,

Stu Bell
DataPlay (DPHI, Inc.)


-----Original Message-----
From: avr-gcc-list-bounces+sbell=dataplay.com@...
[mailto:avr-gcc-list-bounces+sbell=dataplay.com@...] On Behalf Of
Dusan Ferbas
Sent: Tuesday, June 03, 2008 5:36 PM
To: avr-gcc-list@...
Subject: [avr-gcc-list] ATmega 2561 - compiler generates eicall

Hi,

I am using WinAVR-20071221, because none of the most recent toolchains
produces a runnable code for our application.

Our bootloader starts at 0x3f800 (2kB).
In its code, we are using function[id](...) construction.
This is compiled with eicall instruction, but no EIND register is set.
Is there a way, how to tell the compiler, that code is linked in upper
half of flash ?
In bootloader code we can live with EIND=1 at its init.

But when we have a call from our application, neither EIND is set, even
address is not divided by 2 (WinAVR bug #1959227).
Probably some far attribute should be applied ?
When compiled for ATmega128 (with 0x1f806), it works ...

typedef void boot_loader_init(unsigned  char *);
#define boot_loader_data_init           ((boot_loader_init *)0x3F806)
...
   boot_loader_data_init(buffer);
...


Dusan  



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Dusan Ferbas]

Hi Stu,

as you said - why not to read the whole email :-).
>In bootloader code we can live with EIND=1 at its init.

I now checked the case also with WinAVR-20080512. Same bug as with
20071221 (WinAVR bug #1959227 at sf.net).

Is it possible to add an attribute st. like "near" to prevent
compiler using eicall and to generate icall (case 1 below) ?


--------------
case 1 (bootloader)
Problem is not with indirect call through a pointer saved in RAM.
typedef void (* WriteFN)(unsigned short page, unsigned short *data,
unsigned short len);
...
         WriteFN fn[3];
...
         fn[0] = FlashPage;              //FlashPage/2 (word address) is used
...
         fn[0](page, data, len);
-> eicall generated by compiler, which does not know, that the code
will be positioned with linker to an address in upper flash
(EIND=1 solves this)

         Here I would like to have an icall instruction.

--------------
case 2 (application calling fn in bootloader)
Problem is with "direct" call generated with eicall aid. I
understand, that compiler cannot count with link addresses,
but when address is constant even during compilation time, then it is
definitely a compiler bug.

typedef void Tboot_loader_data_init(unsigned char *);
#define boot_loader_data_init ((Tboot_loader_data_init *)0x3F806)

         boot_loader_data_init(buffer)

typedef void Tboot_loader_data_init(unsigned char *);
#define boot_loader_data_init ((Tboot_loader_data_init *)(0x3F806/2))
...
     EIND = 0x3F800 >> 17;
         boot_loader_data_init(workbuf);
     EIND = 0x00;

avr-gcc (GCC) 4.2.2 (WinAVR 20071221), ATmega2561
  241 0068 81E0                  ldi r24,lo8(1)
  242 006a 8CBF                  out 92-0x20,r24
  243 006c C501                  movw r24,r10
  244 006e E3E0                  ldi r30,lo8(-1021)
  245 0070 FCEF                  ldi r31,hi8(-1021)
  246 0072 1995                  eicall

Here you can see, that a workaround was needed. To have a word address,

avr-gcc (GCC) 4.2.2 (WinAVR 20071221),  ATmega128
#define boot_loader_data_init ((Tboot_loader_data_init *)0x1F806)
  229 0054 E6E0                  ldi r30,lo8(-2042)
  230 0056 F8EF                  ldi r31,hi8(-2042)
  231 0058 0995                  icall

Also for ATmega128, no division is done by gcc 4.2.2

avr-gcc (GCC) 3.4.6,  ATmega128
#define boot_loader_data_init ((Tboot_loader_data_init *)0x1F806)
741 006c FF95 03FC              call -2042

Older gcc uses efficient std call to a word address.

Dusan

=====================
At 16:30 4.6.2008, Stu Bell wrote:

>Dang, it would help if I read the entire message.
>
>Function pointers in the bootloader. I kept my bootloader
>mind-bogglingly simple precisely to avoid problems like this.
>Unfortunately, many folks have a need for a far more comples bootloader
>than I need.
>
>Since the eicall is being used, why not force EIND to 1 at the beginning
>of your code...
>
>     asm volatile ( "ldi  r24, 0x01                      \n\t"
>                    "out  0x3C, r24                      \n\t"
>                  );
>
>Worth a shot, eh?
>
>Best regards,
>
>Stu Bell
>DataPlay (DPHI, Inc.)
>
>
>-----Original Message-----
>From: avr-gcc-list-bounces+sbell=dataplay.com@...
>[mailto:avr-gcc-list-bounces+sbell=dataplay.com@...] On Behalf Of
>Dusan Ferbas
>Sent: Tuesday, June 03, 2008 5:36 PM
>To: avr-gcc-list@...
>Subject: [avr-gcc-list] ATmega 2561 - compiler generates eicall
>
>Hi,
>
>I am using WinAVR-20071221, because none of the most recent toolchains
>produces a runnable code for our application.
>
>Our bootloader starts at 0x3f800 (2kB).
>In its code, we are using function[id](...) construction.
>This is compiled with eicall instruction, but no EIND register is set.
>Is there a way, how to tell the compiler, that code is linked in upper
>half of flash ?
>In bootloader code we can live with EIND=1 at its init.
>
>But when we have a call from our application, neither EIND is set, even
>address is not divided by 2 (WinAVR bug #1959227).
>Probably some far attribute should be applied ?
>When compiled for ATmega128 (with 0x1f806), it works ...
>
>typedef void boot_loader_init(unsigned  char *);
>#define boot_loader_data_init           ((boot_loader_init *)0x3F806)
>...
>    boot_loader_data_init(buffer);
>...

Dusan  



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Andy H-2]

Compiler should not need "near". This is a constant address. So it
should do CALL, which can be handle like any other call.

This is a bug.

Andy





----------------------------------------------
Sent from my Dingleberry wired device.


-----Original Message-----
From: Dusan Ferbas <dferbas@...>
To: Stu Bell <sbell@...>; avr-gcc-list@...
Sent: Thu, 5 Jun 2008 7:29 pm
Subject: RE: [avr-gcc-list] ATmega 2561 - eicall uses "byte" address


Hi Stu, 
 
as you said - why not to read the whole email :-). 
>In bootloader code we can live with EIND=1 at its init. 
 
I now checked the case also with WinAVR-20080512. Same bug as with
20071221 (WinAVR bug #1959227 at sf.net). 
 
Is it possible to add an attribute st. like "near" to prevent compiler
using eicall and to generate icall (case 1 below) ? 
 
-------------- 
case 1 (bootloader) 
Problem is not with indirect call through a pointer saved in RAM. 
typedef void (* WriteFN)(unsigned short page, unsigned short *data,
unsigned short len); 
... 
  WriteFN fn[3]; 
... 
  fn[0] = FlashPage; //FlashPage/2 (word address) is used 
... 
  fn[0](page, data, len); 
-> eicall generated by compiler, which does not know, that the code
will be positioned with linker to an address in upper flash 
(EIND=1 solves this) 
 
  Here I would like to have an icall instruction. 
 
-------------- 
case 2 (application calling fn in bootloader) 
Problem is with "direct" call generated with eicall aid. I understand,
that compiler cannot count with link addresses, 
but when address is constant even during compilation time, then it is
definitely a compiler bug. 
 
typedef void Tboot_loader_data_init(unsigned char *); 
#define boot_loader_data_init ((Tboot_loader_data_init *)0x3F806) 
 
  boot_loader_data_init(buffer) 
 
typedef void Tboot_loader_data_init(unsigned char *); 
#define boot_loader_data_init ((Tboot_loader_data_init *)(0x3F806/2)) 
... 
  EIND = 0x3F800 >> 17; 
  boot_loader_data_init(workbuf); 
  EIND = 0x00; 
 
avr-gcc (GCC) 4.2.2 (WinAVR 20071221), ATmega2561 
 241 0068 81E0 ldi r24,lo8(1) 
 242 006a 8CBF out 92-0x20,r24 
 243 006c C501 movw r24,r10 
 244 006e E3E0 ldi r30,lo8(-1021) 
 245 0070 FCEF ldi r31,hi8(-1021) 
 246 0072 1995 eicall 
 
Here you can see, that a workaround was needed. To have a word address, 
 
avr-gcc (GCC) 4.2.2 (WinAVR 20071221), ATmega128 
#define boot_loader_data_init ((Tboot_loader_data_init *)0x1F806) 
 229 0054 E6E0 ldi r30,lo8(-2042) 
 230 0056 F8EF ldi r31,hi8(-2042) 
 231 0058 0995 icall 
 
Also for ATmega128, no division is done by gcc 4.2.2 
 
avr-gcc (GCC) 3.4.6, ATmega128 
#define boot_loader_data_init ((Tboot_loader_data_init *)0x1F806) 
741 006c FF95 03FC call -2042 
 
Older gcc uses efficient std call to a word address. 
 
Dusan 
 
===================== 
At 16:30 4.6.2008, Stu Bell wrote: 
>Dang, it would help if I read the entire message. 
> 
>Function pointers in the bootloader. I kept my bootloader 
>mind-bogglingly simple precisely to avoid problems like this. 
>Unfortunately, many folks have a need for a far more comples
bootloader 
>than I need. 
> 
>Since the eicall is being used, why not force EIND to 1 at the
beginning 

>of your code... 
> 
> asm volatile ( "ldi r24, 0x01 \n\t" 
> "out 0x3C, r24 \n\t" 
> ); 
> 
>Worth a shot, eh? 
> 
>Best regards, 
> 
>Stu Bell 
>DataPlay (DPHI, Inc.) 
> 
> 
>-----Original Message----- 
>From: avr-gcc-list-bounces+sbell=dataplay.com@... 
>[mailto:avr-gcc-list-bounces+sbell=dataplay.com@...] On Behalf

Of 

>Dusan Ferbas 
>Sent: Tuesday, June 03, 2008 5:36 PM 
>To: avr-gcc-list@... 
>Subject: [avr-gcc-list] ATmega 2561 - compiler generates eicall 
> 
>Hi, 
> 
>I am using WinAVR-20071221, because none of the most recent toolchains 
>produces a runnable code for our application. 
> 
>Our bootloader starts at 0x3f800 (2kB). 
>In its code, we are using function[id](...) construction. 
>This is compiled with eicall instruction, but no EIND register is set. 
>Is there a way, how to tell the compiler, that code is linked in upper 
>half of flash ? 
>In bootloader code we can live with EIND=1 at its init. 
> 
>But when we have a call from our application, neither EIND is set,

even 
>address is not divided by 2 (WinAVR bug #1959227). 
>Probably some far attribute should be applied ? 
>When compiled for ATmega128 (with 0x1f806), it works ... 
> 
>typedef void boot_loader_init(unsigned char *); 
>#define boot_loader_data_init ((boot_loader_init *)0x3F806) 
>... 
> boot_loader_data_init(buffer); 
>... 
 
Dusan  
 
_______________________________________________ 
AVR-GCC-list mailing list 
AVR-GCC-list@... 
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list 



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Dusan Ferbas]

I agree that there is a bug.

But with call, I have different opinion.
Compiler does not know, where a module will be linked.
However it knows, where the call targets, it does not know, from
where the call is made.
If it is in a same flash "bank", call is sufficient. If not, there
should be eicall with EIND handling.
It is strange, that compiler generates eicall without EIND handling,
even initializing.

So with near and far attributes, there will be possibility to force
compiler to use call or eicall.
Otherwise we have to code it in asm.

At 13:47 6.6.2008, hutchinsonandy@... wrote:

>Compiler should not need "near". This is a constant address. So it
>should do CALL, which can be handle like any other call.
>
>This is a bug.
>
>Andy
>
>-----Original Message-----
>From: Dusan Ferbas <dferbas@...>
>To: Stu Bell <sbell@...>; avr-gcc-list@...
>Sent: Thu, 5 Jun 2008 7:29 pm
>Subject: RE: [avr-gcc-list] ATmega 2561 - eicall uses "byte" address
>
>I now checked the case also with WinAVR-20080512. Same bug as with
>20071221 (WinAVR bug #1959227 at sf.net).
>
>Is it possible to add an attribute st. like "near" to prevent
>compiler using eicall and to generate icall (case 1 below) ?

Dusan



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Andy H-2]

CALL  can reach all 4M of address space.

EICALL is special version of ICALL - which would be appropropriate for
non-constant function pointers. And this would be the area in which
near/far pointer support would be useful. However, the true functions
pointers inside compiler are only 16bits, so its not a trivial change.

But your code has constant pointer. So CALL  should be ok.

Andy




----------------------------------------------
Sent from my Dingleberry wired device.


-----Original Message-----
From: Dusan Ferbas <dferbas@...>
To: hutchinsonandy@...; sbell@...; avr-gcc-list@...
Sent: Fri, 6 Jun 2008 3:02 pm
Subject: Re: [avr-gcc-list] ATmega 2561 - eicall uses "byte" address


I agree that there is a bug. 
 
But with call, I have different opinion. 
Compiler does not know, where a module will be linked. 
However it knows, where the call targets, it does not know, from where
the call is made. 
If it is in a same flash "bank", call is sufficient. If not, there
should be eicall with EIND handling. 
It is strange, that compiler generates eicall without EIND handling,
even initializing. 
 
So with near and far attributes, there will be possibility to force
compiler to use call or eicall. 
Otherwise we have to code it in asm. 
 
At 13:47 6.6.2008, hutchinsonandy@... wrote: 

>Compiler should not need "near". This is a constant address. So it
>should do CALL, which can be handle like any other call. 
> 
>This is a bug. 
> 
>Andy 
> 
>-----Original Message----- 
>From: Dusan Ferbas <dferbas@...> 
>To: Stu Bell <sbell@...>; avr-gcc-list@... 
>Sent: Thu, 5 Jun 2008 7:29 pm 
>Subject: RE: [avr-gcc-list] ATmega 2561 - eicall uses "byte" address 
> 
>I now checked the case also with WinAVR-20080512. Same bug as with
>20071221 (WinAVR bug #1959227 at sf.net). 
> 
>Is it possible to add an attribute st. like "near" to prevent
>compiler using eicall and to generate icall (case 1 below) ? 

 
Dusan  



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Dusan Ferbas]

Hi guys,

we have 2 issues with eicall instruction on ATmega2561 platform.

1st is, that a call to a constant bootloader (BL) location is compiled with eicall instruction without setting EIND register.
2nd is, that in BL area, indexed call /that is compiled with eicall/ seems not to work, when used from application area.
We tried both WinAVR-20071221 and WinAVR-20080610.

I noticed, that even on ATmega128, call was compiled with all unused PC bits set to 1.
Does it mean, that we should set all "1"s in EIND ?

ad 1) same c code works on ATmega128
ATmega128 way:
-------------------------
typedef int boot_loader_send(unsigned  char *, unsigned  char *, short);
#define boot_loader_data_send ((boot_loader_send*) 0x3F80A)

...
rslt = boot_loader_data_send(workbuf, buf, len);
(compiled with simple call)

2561 solution
------------------
- code for 128 generates eicall
- using a static inline wrap function with asm call
        - it is optimized (arguments are not used, so they are not prepared in registers)
        - preparing registers in a "called" rtn did not work (however i believe that is nearly the same as a next working case)
- finally we created a rtn in an external .c module (see code with asm jmp below)
-> anyone knows an easier way ?


ad 2) works from BL area, does not from an application
following is called both from BL when XMODEM is used over a UART and also from an application
it works from BL, but does not, when called from an application
        - when indexed call was replaced with a list of calls in switch-case, it works (but we do not fit in BL area :-) )

init
         BootInfoHeader->fn[0] = FlashPage;
         BootInfoHeader->fn[1] = EEprom_write_page;
call
        unsigned char eind_local = EIND;
        EIND = 0x3F800 >> (16 + 1); //highest bit of LoadAddr (for ATmega2561 == 1, because in words)
         BootInfoHeader->fn[section_id](address, (unsigned short *)p_received_data, pagesize);
        EIND = eind_local;


code for ad 1) case
-------------------------------

int boot_loader_data_send(unsigned char *p_WorkBuffer, unsigned char *received_data_p, unsigned short data_length)
{
         p_WorkBuffer = p_WorkBuffer;
         received_data_p = received_data_p;
         data_length = data_length;
        
//      int      rslt;

//      asm volatile (  "movw r20,%3" "\n\t"
//                                          "movw r22,%2" "\n\t"
//                                          "movw r24,%1" "\n\t"
//                                          "call 0x3F00A" "\n\t"
//                                          "movw %0,r24" :
//                                          "=r" (rslt) :
//                                          "r" (p_WorkBuffer),
//                                          "r" (received_data_p),
//                                          "r" (data_length));

        asm volatile ("jmp 0x3F00A");

//      return rslt;
}

======================================
At 02:27 4.6.2008, Andy H wrote:

I cant answer your question fully. ...

Anatoly is adding support for 256 on version gcc 4.3 and gcc 4.4. He or Eric may provide you a better way to do call. (Even if it needs asm /macro wrapper)

Dusan Ferbas wrote:

Hi,

I am using WinAVR-20071221, because none of the most recent toolchains produces a runnable code for our application.

Our bootloader starts at 0x3f800 (2kB).
In its code, we are using function[id](...) construction.
This is compiled with eicall instruction, but no EIND register is set.
Is there a way, how to tell the compiler, that code is linked in upper half of flash ?
In bootloader code we can live with EIND=1 at its init.

But when we have a call from our application, neither EIND is set, even address is not divided by 2 (WinAVR bug #1959227).
Probably some far attribute should be applied ?
When compiled for ATmega128 (with 0x1f806), it works ...

typedef void boot_loader_init(unsigned  char *);
#define boot_loader_data_init           ((boot_loader_init *)0x3F806)
...
  boot_loader_data_init(buffer);
...


Dusan

Dusan Ferbas
www.etech.cz

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Tristan Gingold-2]

On Jul 2, 2008, at 11:14 AM, Dusan Ferbas wrote:

> Hi Tristan,
>
> I noticed a notice about eicall support.
> (2008-06-26  Tristan Gingold  <gingold@...> Add support for  
> avr6 instructions: eijmp, eicall)
>
> Can you point me to some link/resource/advice ?

This is a patch for avrtest (not yet committed) - and avrtest doesn't  
support bootloader.

I have not fully followed your issue.  But from what I understand gcc  
can't generate code
for 256x bootloader.

> Will there be a new winavr/avr-gcc release ?

I can't answer this one because I am not the release manager.

Tristan.

>
>
> Thanks
>
> Dusan
>
>> Date: Mon, 30 Jun 2008 13:14:12 +0200
>> To: avr-gcc-list@...
>> From: Dusan Ferbas <dferbas@...>
>> Cc: Andy H <hutchinsonandy@...>
>> Subject: [avr-gcc-list] eicall & EIND
>>
>> Hi guys,
>>
>> we have 2 issues with eicall instruction on ATmega2561 platform.
>>
>> 1st is, that a call to a constant bootloader (BL) location is  
>> compiled with eicall instruction without setting EIND register.
>> 2nd is, that in BL area, indexed call /that is compiled with  
>> eicall/ seems not to work, when used from application area.
>> We tried both WinAVR-20071221 and WinAVR-20080610.
>>
>> I noticed, that even on ATmega128, call was compiled with all  
>> unused PC bits set to 1.
>> Does it mean, that we should set all "1"s in EIND ?
>>
>> ad 1) same c code works on ATmega128
>> ATmega128 way:
>> -------------------------
>> typedef int boot_loader_send(unsigned  char *, unsigned  char *,  
>> short);
>> #define boot_loader_data_send ((boot_loader_send*) 0x3F80A)
>>
>> ...
>> rslt = boot_loader_data_send(workbuf, buf, len);
>> (compiled with simple call)
>>
>> 2561 solution
>> ------------------
>> - code for 128 generates eicall
>> - using a static inline wrap function with asm call
>>         - it is optimized (arguments are not used, so they are not  
>> prepared in registers)
>>         - preparing registers in a "called" rtn did not work  
>> (however i believe that is nearly the same as a next working case)
>> - finally we created a rtn in an external .c module (see code with  
>> asm jmp below)
>> -> anyone knows an easier way ?
>>
>>
>> ad 2) works from BL area, does not from an application
>> following is called both from BL when XMODEM is used over a UART  
>> and also from an application
>> it works from BL, but does not, when called from an application
>>         - when indexed call was replaced with a list of calls in  
>> switch-case, it works (but we do not fit in BL area :-) )
>>
>> init
>>          BootInfoHeader->fn[0] = FlashPage;
>>          BootInfoHeader->fn[1] = EEprom_write_page;
>> call
>>         unsigned char eind_local = EIND;
>>         EIND = 0x3F800 >> (16 + 1); //highest bit of LoadAddr (for  
>> ATmega2561 == 1, because in words)
>>          BootInfoHeader->fn[section_id](address, (unsigned short *)
>> p_received_data, pagesize);
>>         EIND = eind_local;
>>
>>
>> code for ad 1) case
>> -------------------------------
>>> int boot_loader_data_send(unsigned char *p_WorkBuffer, unsigned  
>>> char *received_data_p, unsigned short data_length)
>>> {
>>>          p_WorkBuffer = p_WorkBuffer;
>>>          received_data_p = received_data_p;
>>>          data_length = data_length;
>>>
>>> //      int      rslt;
>>>
>>> //      asm volatile (  "movw r20,%3" "\n\t"
>>> //                                          "movw r22,%2" "\n\t"
>>> //                                          "movw r24,%1" "\n\t"
>>> //                                          "call 0x3F00A" "\n\t"
>>> //                                          "movw %0,r24" :
>>> //                                          "=r" (rslt) :
>>> //                                          "r" (p_WorkBuffer),
>>> //                                          "r" (received_data_p),
>>> //                                          "r" (data_length));
>>>
>>>         asm volatile ("jmp 0x3F00A");
>>>
>>> //      return rslt;
>>> }
>>
>> ======================================
>> At 02:27 4.6.2008, Andy H wrote:
>>> I cant answer your question fully. ...
>>>
>>> Anatoly is adding support for 256 on version gcc 4.3 and gcc 4.4.  
>>> He or Eric may provide you a better way to do call. (Even if it  
>>> needs asm /macro wrapper)
>>>
>>> Dusan Ferbas wrote:
>>>> Hi,
>>>>
>>>> I am using WinAVR-20071221, because none of the most recent  
>>>> toolchains produces a runnable code for our application.
>>>>
>>>> Our bootloader starts at 0x3f800 (2kB).
>>>> In its code, we are using function[id](...) construction.
>>>> This is compiled with eicall instruction, but no EIND register  
>>>> is set.
>>>> Is there a way, how to tell the compiler, that code is linked in  
>>>> upper half of flash ?
>>>> In bootloader code we can live with EIND=1 at its init.
>>>>
>>>> But when we have a call from our application, neither EIND is  
>>>> set, even address is not divided by 2 (WinAVR bug #1959227).
>>>> Probably some far attribute should be applied ?
>>>> When compiled for ATmega128 (with 0x1f806), it works ...
>>>>
>>>> typedef void boot_loader_init(unsigned  char *);
>>>> #define boot_loader_data_init           ((boot_loader_init *)
>>>> 0x3F806)
>>>> ...
>>>>   boot_loader_data_init(buffer);
>>>> ...
>>> Dusan
>>>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Dusan Ferbas]

Hi Tristan,

thanks for reply.

Gcc can generate code for bootloader.
But I am not sure if eicall does not require EIND to be filled with ones.
Spec (AVR_instr_doc0856.pdf) is saying, that EIND is concatenated
with Z (r30, r31),
so EIND=1 should be sufficient.

But when call 0x1f800 is compiled for ATmega128, all "unused" MS bits
are filled with ones.

Can I look at your patch what is it about (support for eicall) ?

Dusan

At 11:27 2.7.2008, Tristan Gingold wrote:

>On Jul 2, 2008, at 11:14 AM, Dusan Ferbas wrote:
>
>>Hi Tristan,
>>
>>I noticed a notice about eicall support.
>>(2008-06-26  Tristan Gingold  <gingold@...> Add support for
>>avr6 instructions: eijmp, eicall)
>>
>>Can you point me to some link/resource/advice ?
>
>This is a patch for avrtest (not yet committed) - and avrtest doesn't
>support bootloader.
>
>I have not fully followed your issue.  But from what I understand gcc
>can't generate code
>for 256x bootloader.

Dusan Ferbas
www.etech.cz



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Tristan Gingold-2]

On Jul 2, 2008, at 12:13 PM, Dusan Ferbas wrote:

> Hi Tristan,
>
> thanks for reply.
>
> Gcc can generate code for bootloader.

Sure but there might be subtile bugs.
gcc and ld assumes EIND=0 which is not correct for a bootloader.

> But I am not sure if eicall does not require EIND to be filled with  
> ones.
> Spec (AVR_instr_doc0856.pdf) is saying, that EIND is concatenated  
> with Z (r30, r31),
> so EIND=1 should be sufficient.
>
> But when call 0x1f800 is compiled for ATmega128, all "unused" MS  
> bits are filled with ones.
>
> Can I look at your patch what is it about (support for eicall) ?

Sure, it is in the mailing list archive.  But it is for the simulator.

Tristan.

>
> Dusan
>
> At 11:27 2.7.2008, Tristan Gingold wrote:
>> On Jul 2, 2008, at 11:14 AM, Dusan Ferbas wrote:
>>
>>> Hi Tristan,
>>>
>>> I noticed a notice about eicall support.
>>> (2008-06-26  Tristan Gingold  <gingold@...> Add support for
>>> avr6 instructions: eijmp, eicall)
>>>
>>> Can you point me to some link/resource/advice ?
>>
>> This is a patch for avrtest (not yet committed) - and avrtest doesn't
>> support bootloader.
>>
>> I have not fully followed your issue.  But from what I understand gcc
>> can't generate code
>> for 256x bootloader.
>
>
> Dusan Ferbas
> www.etech.cz

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list