This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Questions about GDB Ctrl-C support.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]