[ECOS] Separate console and debug ports?

[ECOS] Separate console and debug ports?

[Grant Edwards]

I've given up on network debugging, so now I really need to get
serial debugging to work. The porting guide recommends using
separate ports for GDB debugging and for console I/O.  I've got
two diagnostic serial ports, so I'm trying to configure RedBoot
to use one for console I/O and the other for GDB debugging.

I guess I need to set CYGPKG_REDBOOT_ANY_CONSOLE to 0 (will
that disable console on TCP port 9000?).  I can't figure out
how to tell it to use diag serial port 0 for console and port 1
for debugger.  Can anybody loan me a clue?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Separate console and debug ports?

[Jesper Skov]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> I've given up on network debugging, so now I really need to get
Grant> serial debugging to work. The porting guide recommends using
Grant> separate ports for GDB debugging and for console I/O.  I've got
Grant> two diagnostic serial ports, so I'm trying to configure RedBoot
Grant> to use one for console I/O and the other for GDB debugging.

Grant> I guess I need to set CYGPKG_REDBOOT_ANY_CONSOLE to 0 (will
Grant> that disable console on TCP port 9000?).  I can't figure out
Grant> how to tell it to use diag serial port 0 for console and port 1
Grant> for debugger.  Can anybody loan me a clue?

You're looking for the CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL and
CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL options.

You also need to disable CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE and
CYGDBG_HAL_DIAG_TO_DEBUG_CHAN.

Jesper

Re: [ECOS] Separate console and debug ports?

[Grant Edwards]

On Thu, Mar 08, 2001 at 08:13:23AM +0100, Jesper Skov wrote:

> Grant> separate ports for GDB debugging and for console I/O.  I've got
> Grant> two diagnostic serial ports, so I'm trying to configure RedBoot
> Grant> to use one for console I/O and the other for GDB debugging.
> 
> Grant> I guess I need to set CYGPKG_REDBOOT_ANY_CONSOLE to 0 (will
> Grant> that disable console on TCP port 9000?).  I can't figure out
> Grant> how to tell it to use diag serial port 0 for console and port 1
> Grant> for debugger.  Can anybody loan me a clue?
> 
> You're looking for the CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL and
> CYGNUM_HAL_VIRTUAL_VECTOR_CONSOLE_CHANNEL options.
> 
> You also need to disable CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE and
> CYGDBG_HAL_DIAG_TO_DEBUG_CHAN.

Thanks.  I've got serial gdb debugging working on the console
channel, so I'm going to try to split the diag and debug
channels next.

In order to avoid loosing input characters I got rid of the
timeouts in RedBoot's gets(), so now if there's no input on a
UART, it doesn't delay. It checks the next UART (or the
network) immediately.  I don't understand the purpose of the
delay after checking a UART -- my configuration works a lot
better without them.  

Since nobody is calling the 1ms delay routine that updates the
system time, I did have to add to the main loop a call to a new
routine in ticks.c to advance the system by about 80us
everytime through the loop.  The unfortunate thing about that
setup is that you have to tune the "system time adjust" value
by hand to get a reasonably accurate system time.

But, ping resonse time is 1-2 ms and I never loose console
characters at 57.6K baud.  :)

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Separate console and debug ports?

[Jonathan Larmour]

Grant Edwards wrote:
> 
> In order to avoid loosing input characters I got rid of the
> timeouts in RedBoot's gets(), so now if there's no input on a
> UART, it doesn't delay. It checks the next UART (or the
> network) immediately.  I don't understand the purpose of the
> delay after checking a UART -- my configuration works a lot
> better without them.
> 
> Since nobody is calling the 1ms delay routine that updates the
> system time, I did have to add to the main loop a call to a new
> routine in ticks.c to advance the system by about 80us
> everytime through the loop.  The unfortunate thing about that
> setup is that you have to tune the "system time adjust" value
> by hand to get a reasonably accurate system time.
> 
> But, ping resonse time is 1-2 ms and I never loose console
> characters at 57.6K baud.  :)

I may well be talking out my *rse, but what about trying to make the timer
interrupt driven rather than polled, and then delay_us just reads a global
volatile counter? Normally RedBoot is completely polled, but as long as you
mask all your unused interrupt sources I don't know any reason why there'd
be a problem. Admittedly I don't think we would want such a change in the
master sources so this wouldn't solve the problem for everyone.

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

Re: [ECOS] Separate console and debug ports?

[Grant Edwards]

On Tue, Mar 13, 2001 at 08:25:41PM +0000, Jonathan Larmour wrote:

> > In order to avoid loosing input characters I got rid of the
> > timeouts in RedBoot's gets(), so now if there's no input on a
> > UART, it doesn't delay. It checks the next UART (or the
> > network) immediately.  I don't understand the purpose of the
> > delay after checking a UART -- my configuration works a lot
> > better without them.
> > 
> > Since nobody is calling the 1ms delay routine that updates the
> > system time, I did have to add to the main loop a call to a new
> > routine in ticks.c to advance the system by about 80us
> > everytime through the loop.  The unfortunate thing about that
> > setup is that you have to tune the "system time adjust" value
> > by hand to get a reasonably accurate system time.
> > 
> > But, ping resonse time is 1-2 ms and I never loose console
> > characters at 57.6K baud.  :)
> 
> I may well be talking out my *rse, but what about trying to
> make the timer interrupt driven rather than polled, and then
> delay_us just reads a global volatile counter?

That would work just fine.  In fact, what you described is
pretty much exactly how the bootloader in one of our other
products works: the only interrupt is a 1ms timer that does
nothing but increment a counter.  Everthing else is polled in a
main loop.

> Normally RedBoot is completely polled, but as long as you mask
> all your unused interrupt sources I don't know any reason why
> there'd be a problem. Admittedly I don't think we would want
> such a change in the master sources so this wouldn't solve the
> problem for everyone.

The reason I avoided using a timer interrupt is that I didn't
know what would happen when I started using GDB stubs to debug
an eCos app.  Both my hardware timers are used for other
purposes by eCos -- if GDB stubs need us_delay, then I can't
use any hardware timers at all (interrupt or not) in the
us_delay routine.
-- 
Grant Edwards
grante@visi.com