RE: [avr-gcc-list] Re: eicall & EIND

[Stu Bell]

> We are using Nut/OS, where you can setup interrupt handler 
> address at run time.

Interesting.  Is this done through a single "master interrupt"?  You
cannot rewrite the vector table real-time.  Just curious.

> 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.

The common solution to the "interrupts when running in the BLS" problem
is to generate the boot as a totally separate application, then use the
IVSEL control bit to set the processor to use the vector table at the
beginning of the BLS.

I was one of the "weird" guys who didn't follow this approach.  There
are both good things and bad things to not writing the boot as an
application, and the one bad is that interrupts are pretty much thrown
out the window.

EIND should not be needed by general code in the bootloader.  The
compiler rarely uses the EICALL/EIJMP instruction but instead tends to
use RJMP/RCALL.  The only place I know that it is used is when the
single call prologue is used (the compiler switch -mno-call-prologues
turns this off).  The mega2560 library should *not* be using that in the
latest RC version of WinAVR, and that may have been fixed in WinAVR
20081205.

If you are upgrading the application, don't you want to restart the O/S
as well?  The usual method to do that is to force a watchdog timeout,
which will cause a CPU reset and clear all interrupt flags (which is
what you want anyway) and all the control registers, EIND included.

> 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.

Well, not necessarily.  As I said above, you can generate the boot as an
app, use IVSEL to switch interrupts to the boot's interrupt table, and
all is wonderful.

If NutOS wants to use functions in the bootloader during normal
processing (say if there are funcitons that are shared between boot and
app), you will need to generate a function table for the bootloader
residing in the BLS.  I've never done that, but I think some folks on
AVR Freaks have, so a quick forum search should yield some results.


Best regards, 

Stu Bell 
DataPlay (DPHI, Inc.)