[En-Nut-Discussion] Interrupt within a bootloader

[Timothy M. De Baillie]

Ole,

We have written three different bootloaders.  One over ethernet,
one over serial, and one over an rf interface through the SPI.  I can
tell you from experience that it is VERY important to disable all of
the interrupts in the system before jumping from one OS build (bootloader)
to another (target). 

It has been our practice to essential "turn off" the devices as well as 
disabling
the interrupts to avoid reinitializing the device from a "weird" state.

If you are using a SAM7, you should check the status of the AIC to disable
any interrupts that are enabled and the PMC to disable any peripheral
clocks.  Additionally, it is useful to lock the flash space of AT LEAST the
bootloader before you jump to avoid any unwanted overwrites from the
target.

Tim

Ole Reinhardt wrote:
> Hi all,
>
> For a ethernut3 project I'm using my own xmodem / ymodem bootloader over
> the RS232. This bootloader itself is a "normal" NutOS application whitch
> is using a the at91usart driver with interrupts enabled.
>
> I experienced now a problem with occured from time to time when the
> bootloader tries to start the application with is located at address
> 0x10010000 in flash. The application ends up in the exception handler
> when data is send to the uart right in the moment when the bootloader
> jumps into the user application and the first bytes of the user
> application are executed.
>
> Probably the problem exists because the interrupts of the UART are still
> enabled when I jump into the user application. I seems that in the
> moment when the user application updates the interrupt vector table it
> might occur that that an uart interrupt occurs. This directly leads into
> a data abort exception as supposely the old interrupt code of the
> bootloader is still called which will modify any undefined memory
> addresses.
>
> Ok, disabling the UART interrupts before booting should help, but I'm
> not shure if there are'nt any other interrupts that might be still
> active? The system timer for example?
>
> @Harald: How is the bootmon handling this problem? At least the ethernet
> interface will still throw interrupts, right? I don't see that the
> interrupts are globaly disabled before booting.
>
> Btw: will disabling global interrupt be sufficient before booting a
> NutOS application to avoid calling undefined interrupts? Or might we run
> into any problem with (perhaps even unused) devicedrivers when the
> hardware is still enabled after booting? 
>
> Regards,
>
> Ole Reinhardt
>
>