This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Questions about GDB Ctrl-C support.
- To: Grant Edwards <grante at visi dot com>
- Subject: Re: [ECOS] Questions about GDB Ctrl-C support.
- From: Jonathan Larmour <jlarmour at redhat dot com>
- Date: Fri, 07 Sep 2001 01:19:02 +0100
- Cc: ecos-discuss at sources dot redhat dot com
- References: <20010906164103.A7868@visi.com>
Grant Edwards wrote:
>
> I'm trying to use gdb via serial connection to RedBoot, and
> everything works peachy-keen until the point where eCos enables
> interrupts. I can set break-points, single-step, etc. in the
> initialization stuff, but once interrupts are enabled, I get
> "spurious interrupt" messages complaining about interrupts from
> the serial port that RedBoot is using to talk to gdb.
>
> I don't have virtual vectors enabled in my eCos HAL, since I
> don't my HAL to depend on RedBoot. I don't want diag_printf to
> do output with calls to RedBoot.
>
> [I'm using a CVS snapshot from December.]
At that age, the likely fix is to include this bit from the current redboot
main.c:
// Mask interrupts on all channels
for (i = 0; i < CYGNUM_HAL_VIRTUAL_VECTOR_NUM_CHANNELS;
i++) {
CYGACC_CALL_IF_SET_CONSOLE_COMM(i);
__chan = CYGACC_CALL_IF_CONSOLE_PROCS();
CYGACC_COMM_IF_CONTROL( *__chan, __COMMCTL_IRQ_DISABLE
);
}
just before control is passed to the stub by a breakpoint. Or perhaps the
better thing is to ensure the serial interrupt is masked in the diag init
code.
> However, I would like to add GDB ctrl-C support to my HAL, and
> I'm not sure what I need to do. I've looked at
>
> http://sources.redhat.com/ecos/docs-latest/porting/hal-stubs.html
>
> But, that seems to be describing how it works when you're using
> the gdb stubs built into the eCos HAL (I'm using the stubs that
> are in RedBoot).
If you've got a VV enabled HAL, all you need to ensure is that you don't
take over the vector corresponding to the debug channel RX.
> It also keeps refering to a "serial driver,"
> and I don't know what driver that would be -- there is no eCos
> driver for the debug UART -- eCos doesn't even know it exists.
The diag driver - whatever driver there is for the debug channel.
> The hal_arch_default_isr() that I have doesn't do anything
> except print a "spurious interrupt message". I've looked at the
> HAL files for other platforms in my snapshot, and they seem to
> be doing stuff with CygMon.
Perhaps the ones you've looked at have been only catering for Cygmon.
> I presume that I need to modify hal_arch_default_isr() to make
> a call to RedBoot via the virtual vector table so that it can
> service the UART and check for 0x03. Or do I add a
> hal_default_isr() to my HAL, and figure out how to get that
> used in place of hal_arch_default_isr()?
You call hal_ctrlc_isr_init which lives in hal_if.c from vectors.S - i.e.
the platform HAL shouldn't be involved at all (except for the
implementation of the underlying driver).
hal_default_isr is meant to come from the hal/common's hal_misc.c. In most
cases hal_arch_default_isr (defined in the arch hal usually) shouldn't do
anything except return 0.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine