This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Problem with GDB/insight debugging standalone interrupt driven code
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: Miklos dot Pflancer at dbresearch dot co dot uk
- Cc: ecos-discuss at sourceware dot org
- Date: 22 Sep 2006 17:17:41 +0100
- Subject: Re: [ECOS] Problem with GDB/insight debugging standalone interrupt driven code
- References: <45126BF4.31450.911924@localhost> <4512B1C7.12757.12283E3@localhost>
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