[ECOS] diag_printf to debug Ctrl-C behaviour.

[ECOS] diag_printf to debug Ctrl-C behaviour.

[Fabrice Gautier]

Hi,

Where is it safe to place diag_printf, to debug ctrl-C handling?

I believe it is safe to put diag_printf in redboot but i've encountered some
strange behaviour when using diag_printf in the code which is part of the
program,like in ctrlc_isr for example.

My guess is this has something to do with
CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG()

Can somebody enlight me about this?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

RE: [ECOS] diag_printf to debug Ctrl-C behaviour.

[Gary Thomas]

On 04-Nov-2000 Fabrice Gautier wrote:
> Hi,
> 
> Where is it safe to place diag_printf, to debug ctrl-C handling?
> 
> I believe it is safe to put diag_printf in redboot but i've encountered some
> strange behaviour when using diag_printf in the code which is part of the
> program,like in ctrlc_isr for example.
> 

I would definitely avoid any calls to diag_printf() in the ^C path
in your application.  This could get very messy and also not be terribly
productive.

Adding printf() calls within RedBoot should be pretty safe, however.

> My guess is this has something to do with
> CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG()

More than likely.  They key with this flag is that it gets set when
the target (application) has detected that a ^C has occurred on the
console.  This causes the debugger (GDB via RedBoot) to insert a
breakpoint in such a way that the application will stop at the next
reasonable opportunity.

This flag is tested, primarily, at the exit to the console print
code which runs the "GDB mangler" (the piece of code that actually
knows how to talk GDB protocol).  This is why using "diag_printf()"
in your application to debug the use of the flag would be so tricky
and/or dangerous.