[ECOS] Ctrl-C/Break with RedBoot, GDB and TCP

[ECOS] Ctrl-C/Break with RedBoot, GDB and TCP

[Fabrice Gautier]

Hi,

Here is the situation:

- I boot my PC target with RedBoot and I connect GDB via TCP to the target
- I download an application program which do not have a stub inside but
trley on Redboot
- I can run, set breakpoint, step ...

But I can't interrupt the program with a Ctrl-C

So: How does this case is supposed to work ?

RedBoot doesn't manage interrupts and anyway (as seen before) the
application takes control of the IRQs when loaded. So I guess the
application should be involved. However, the application doesn't use net
support and so doesn't have any interrupt handler connected on the ethernet
channel.

So How do we do that ? 


-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

RE: [ECOS] Ctrl-C/Break with RedBoot, GDB and TCP

[Gary Thomas]

On 25-Oct-2000 Fabrice Gautier wrote:
> Hi,
> 
> Here is the situation:
> 
> - I boot my PC target with RedBoot and I connect GDB via TCP to the target
> - I download an application program which do not have a stub inside but
> trley on Redboot
> - I can run, set breakpoint, step ...
> 
> But I can't interrupt the program with a Ctrl-C
> 
> So: How does this case is supposed to work ?
> 
> RedBoot doesn't manage interrupts and anyway (as seen before) the
> application takes control of the IRQs when loaded. So I guess the
> application should be involved. However, the application doesn't use net
> support and so doesn't have any interrupt handler connected on the ethernet
> channel.
> 
> So How do we do that ? 

Does your application include the TCP/IP stack?

If so, then your network driver needs to "cooperate" in the detection
of ^C via the ethernet.  This involves having the interrupt handler 
(what was the DSR before the restructuring) call into RedBoot to let 
it do some processing on the data.  See the CF ethernet for a working
example (devs/eth/cf/...)

If you don't have TCP/IP included in your application, then any interrupts
from the ethernet device should come into the system via the "default"
interrupt handler.  This handler should call into RedBoot appropriately.

Finally, your application needs to have CYGSEM_USE_HAL_MONITOR set for
any of this to work properly (IIRC).

RE: [ECOS] Ctrl-C/Break with RedBoot, GDB and TCP

[Fabrice Gautier]

> -----Original Message-----
> From: Gary Thomas [ mailto:gthomas@redhat.com ]
> Subject: RE: [ECOS] Ctrl-C/Break with RedBoot, GDB and TCP
[...]
> > So How do we do that ? 
> 
> Does your application include the TCP/IP stack?

No. (Not yet).
 
[...]
 
> If you don't have TCP/IP included in your application, then 
> any interrupts
> from the ethernet device should come into the system via the "default"
> interrupt handler.  This handler should call into RedBoot 
> appropriately.
> 
> Finally, your application needs to have CYGSEM_USE_HAL_MONITOR set for
> any of this to work properly (IIRC).

I think I need CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT too.

I've dome some printf'ing too and the problem is probably the
hal_saved_interrupt_state variable which is used in hal_ctrlc_isr (file
hal_if.c) as an argument to cyg_hal_user_break.

(By the way this variable is declared as a 'struct HAL_SavedRegisters*' and
is transtyped to a 'CYGADDRWORD*' when passed to cyg_hal_user_break which in
turn trantype its argument to plain 'HAL_SavedRegisters*' not a struct... So
far I've only found one arch that defined HAL_SavedRegisters as a struct,
but all define it as a type. It won't compile if you try to access a member
of the struct)

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com