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

[Nick Garnett <nickg at ecoscentric dot com>]

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

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