[ECOS] LPC2XXX: Spurious Interrupts Issue

[Sergei Gavrikov <w3sg at SoftHome dot net>]

Hello

I would want to discuss with customers of LPC2XXX targets one issue. That
is the 'Spurious Interrupt' events.

I did notice what sometimes the Spurious Interrupts occur on the DEBUG
COMM channel on my LPC2XXX targets from Olimex. Well, those 'spurious'
interrupts (for example, 'Interrupt: 6' from LPC2XXX UART0) occur when
any extra odd character != '\003' passes through this path

INT -> hal_ctrl_isr -> cyg_hal_plf_serial_isr -> hal_default_isr ->
hal_arch_default_isr -> hal_default_isr

There is a final catch for such interrupts in 'hal_default_isr'
(hal/common/current/src/hal_misc.c)

    result = hal_arch_default_isr (vector, data);
    if( 0 != result) return result;

    CYG_TRACE2(true, "Interrupt: %d, Data: 0x%08x", vector, data);
    CYG_FAIL("Spurious Interrupt!!!");

Note for eCos novices: you will see nothing in your terminal program,
if you do not use the eCos TRACING feature (this nice thing is turned off
by default). And you think then, What's happening there? My program does
hang every time!  Something messes up something! Where is my JTAG? (The
worst when you find an oscillograph :). You say, It's very strange, an
application works as expected as a standalone application (in ROM),
but it hangs every time in GDB. I'm not a mentor, I did think like you
recently.

They say us that to prevent any interference DIAG on DEBUG channel, we
have to separate these channels, i.e. we have to use different physical
ports.  But, some targets have only one serial connector, that's normal.
What is a solution for this? That is CYGDBG_HAL_DIAG_TO_DEBUG_CHAN == 1
(this is set to 1 by default). But if you have a stupid hardware ...

Okay, my digs with grep through the eCos tree showed what such a problem
quite occurs on some other platforms too. Folk did fix this by rewriting
the _ctrlc-related_ things instead the defaults are placed in hal_if.c,
and then they did redefine HAL_CTRLC_ISR macro for own targets. That
is a solution for real hackers, but I had no time and did a small fix
which overwrites DEBUG_COMM settings in my 'plf_if_init'. It seems that
is good place for such a hack

    void
    plf_if_init (void)
    {
    #ifdef FIX_SPURIOUS_INTERRUPTS
        hal_virtual_comm_table_t *__chan = CYGACC_CALL_IF_DEBUG_PROCS ();
        CYGACC_COMM_IF_DBG_ISR_SET (*__chan, my_plf_serial_isr);
    #endif
    }

Note: add in your platform CDL file

    implements CYGINT_HAL_PLF_IF_INIT.

That 'my_plf_serial_isr' does not return 0 never and there is a call

    HAL_INTERRUPT_MASK(chan->isr_vector);

on it's a head.

With same lazy hack I can use GDB with RedBoot smoothly, i.e. stop a
run with Ctrl-C, pass through out the eCos threads, even when I use ONE
serial connector on my target (for example, Olimex LPC-H2294 has one
USB connector). It lets me go for a walk by a working 'twothreads' eCos
exmaple in GDB, for example. One suggestion, for the smooth debugging
with GDB 5.3, turn a GCC optimization off (fix CYGBLD_GLOBAL_CFLAGS). I
use the '-g -gdwarf-2 -O0' flags instead defaults '-g -O2'.

It sounds good, but there are some limitations for a using of same
solution there. You have to configure eCos tree with the conditions

    CYGSEM_HAL_USE_ROM_MONITOR == GDB_stubs
    CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE == 1
    CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS == 0
    CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT == 1
    ...

Hope, you get the message. It is certainly, there is a happiness in the
eCos World. Most of us have get such conditions just when we type that
'ecosconfig new target' command.

I think what same optional catches would appear in LPC2XXX variant,
but perhaps that only my hardware gets such events. Did anyone get the
'Spurious Interrupt !!!' message on other LPC2XXX boards? If you did,
What do you done to fix it? Do you have own experience? I would very
appreciate your hints or medecine. Drop about, please.

Thanks,

Sergei


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss