[En-Nut-Discussion] Interrupt within a bootloader

Dave Warren dwarren at luescher.com
Mon Aug 18 15:49:42 CEST 2008


I had problems in my bootloader,sometimes the restart of the application 
caused an exception. Solution was to switch first to the slow clock.

while((inr(PMC_SR) & _BV(3)) == 0) ;

I also reset all periperals by toggling hardware reset pin, then branch to 
the app.


Dave Warren

----- Original Message ----- 
From: "Ole Reinhardt" <ole.reinhardt at embedded-it.de>
To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
Sent: Friday, August 15, 2008 2:39 PM
Subject: [En-Nut-Discussion] Interrupt within a bootloader

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

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?


Ole Reinhardt

|                                                             |
| Embedded-IT          Hard- und Softwarelösungen             |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        +49 (0)271  7420433 |
| Luisenstraße 29      Mobil:             +49 (0)177  7420433 |
| 57076 Siegen         eMail:    ole.reinhardt at embedded-it.de |
| Germany              Web:         http://www.embedded-it.de |
|                      UstID / VAT:       DE198944716         |


More information about the En-Nut-Discussion mailing list