Hi Stu, I appreciate your explanation and links. Thanks. I know, what are you talking about.
Maybe I did not described my case at all. All suggestions are to live with eind==0. For this gcc can generate icall instead. We are using Nut/OS, where you can setup interrupt handler address at run time. This is the reason, why eicall is generated in interrupt routine. I agree, that these routines should be placed in lower 128K, .isr section is fine. We use .lowtext.xxxx which has same effect, if a linker script covers it. For this eind has to be 0 at all time, an interrupt can occure. I think, axiom #0.
Now, I have a bootloader. Simple, no interrupts, part of it is called from an application to allow http upgrade. There is a decryption and then data based selection of routines to burn into different places - flash/eeprom/SPI flash. For this eicall seems to be proper way. But eind is expected to be 1 now, axiom #1. We manually has to force this and then reload 0 back. So I think ints has to be disabled during bootloader call, no other solution for current OS implementation. The other solution should be to rewrite OS to assign int rtns at link time as in freeRTOS.
Dusan At 16:26 10.3.2009, Stu Bell wrote:
I practically never use EIND in my code. This is useful if you intend to call functions in your bootloader, but otherwise the hassle of calling functions this way is a pain. My bootloader is very plain-vanilla, no interrupts code and does not provide any function to the main app *except* downloading new app code. For that one function, I force the boot procesure to a known location and call it with inline assembly language from the app. Check out the following for instructions on handling ISRs and function pointer targets: http://www.avrfreaks.net/index.php?module=PNphpBB2&file=viewtopic&t=6891 1 http://www.avrfreaks.net/index.php?module=PNphpBB2&file=viewtopic&t=7038 7 I am using FreeRTOS, so I also place any RTOS functions that may be called at switch-context time in lower memory. They are placed in the linker section .task using the same methods as above. Best regards, Stu Bell DataPlay (DPHI, Inc.) > -----Original Message----- > From: avr-gcc-list-bounces+sbell=dataplay....@nongnu.org > [mailto:avr-gcc-list-bounces+sbell=dataplay....@nongnu.org] > On Behalf Of Dusan Ferbas > Sent: Monday, March 09, 2009 3:19 PM > To: Weddington, Eric; avr-gcc-list@nongnu.org > Cc: Andy H > Subject: RE: [avr-gcc-list] Re: eicall & EIND > > OK, I am not arguing :-). > I am just adding some strength to this issue, because it is > not only a problem of impossibility to reach far code, but > problem is also with interrupts, if you manually force eind. > > I also asked about info for trampolines. I was not able to > google out, neither find in this list. Any advice ? > > At 18:34 8.3.2009, Weddington, Eric wrote: > > > in June 2008, I discussed here calling a bootloader from an > > > application. > > > Now, we recognized that this is a common problem with calling > > > functions with eicall instruction. > > > >Known issue: > ><http://sourceforge.net/tracker/index.php?func=detail&aid=202 8719&group> >_id=68108&atid=520074>
Dusan
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
