This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Asynchronous GDB break serial target
- To: <ecos-discuss at sources dot redhat dot com>
- Subject: [ECOS] Asynchronous GDB break serial target
- From: "Raymund Hofmann" <rhofmann at raygmbh dot de>
- Date: Wed, 1 Aug 2001 12:01:38 +0100
- Organization: RAY Electronic-Design GmbH
- Reply-To: "Raymund Hofmann" <rhofmann at raygmbh dot de>
I ported a existing 1.3.1 board package (Triscend A7(ARM)) for operation
with the current cvs.
Most of the things seem to work, but one particular thing does not:
Asynchronous GDB break (serial).
I installed a Redboot rom monitor and use this to debug a application in
ram.
>From my investigation so far, i have come tho know:
For the RAM application library:
i deactivated "initialize whole virtual vector table"
i deactivated "claim comms virtual vector table"
But i don't understand how the rom-monitor should receive control in case of
a GDB serial interrupt because:
The processor vector table points to IRQ handler in the RAM.
The entries in 'hal_interrupt_handlers' table do not point to ROM, it points
to a default handler in RAM except one timer interrupt handler in RAM.
So redboot in ROM has no chance of noteicing the break.
After issuing "continue" in GDB, and the target does not encounter a
breakpoint i can observe that interrupts for the appropriate serial channel
are enabled.
I also looked at the rom-monitor which does not install a isr to handle gdb
breaks, but calls a default 'hal_default_isr' which is supposed to handle
this by calling 'hal_ctrlc_isr'.
But this can't be called when the interrupt entry in the RAM target is used.
Could someone help me get a clearer Picture of how this is supposed to work
?
Raymund Hofmann
RAY Electronic-Design GmbH
Lagerstrasse 49
64807 Dieburg, Germany
Tel ++49 6071-986000
Fax ++49 6071-9860098