[ECOS] Problem with GDB/insight debugging standalone interrupt driven code

Nick Garnett nickg@ecoscentric.com
Fri Sep 22 16:17:00 GMT 2006

Miklos.Pflancer@dBResearch.co.uk writes:

> Hi Nick
> My startup code only sets up the stacks and copies the IRQ vector 
> instruction
> 		 ldr     PC, [PC,#-0xFF0]  
> to the IRQ vector (after remap)
> 		  ldr     r0,=0xe51ffff0
>              ldr	r1,=0x40000018
> 		  str     r0,[r1]           
> I the zero .bss and copy .data and jump to main
> When I step through my code the following instruction which enables 
> IRQ's causes GDB to hang
> asm volatile (" msr  cpsr, %0" : /* no outputs */ : "r" (val)  );
> As I mentioned earlier, the code seems to work fine when I use gdb to 
> load and run this application

RedBoot enables receive interrupts on the serial device being used for
GDB just before passing control to the application. This is so that
you can use Ctrl-C to interrupt execution. eCos has code in its
interrupt system to deal with these apparently spurious interrupts and
pass them on to RedBoot. Since your application presumably does not
deal with these interrupts, then this may explain why it fails, since
there may be a pending interrupt remaining after the transfer of

The simple solution is to program the interrupt controller to mask all
interrupt sources before enabling IRQs in the CPU. A more complex
alternative is to duplicate the eCos code to permit Ctrl-C handling to
still work.

Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts

Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list