Re: [ECOS] LPC2XXX: Spurious Interrupts Issue

[Sergei Gavrikov <w3sg at SoftHome dot net>]

On Thu, 1 Feb 2007, wang cui wrote:

> Actually, I always face Spurious Interrupts in all my
> LPC2XXX(LPC2138,LPC2220,LPC2290) targets and it hangs.
> Not only in GDB debug mode as you described, but also
> in ROM.
>
> I solve it with attached patch. It works in ROM, but
> not tested in GDB debug mode.

Thanks, I brief look at the patch. You fix the LPC2XX vector table.  But,
IMHO, we shouldn't mess up with LPC-related code in the arm vector.S. I
meet such hangs never for my standalone application, i.e. that what
starts from the LPC on-chip flash, because my flash programmer for LPC
parts recalculates a check sum of the arm vectors and writes a correct
value in that 'unused' word.  So, such a job is a post-build job. For
example, I think you would make 'make' do it after a building executables
for LPC2XXX with one script.

I did talk about unexpected interrupts that what occur on the virtual
debug channel. I did notice that unexpected interrupt occurs after a few
step in GNU gdb. At first, I did think, That's a hardware bug. But then
I begun to learn a chain of events. RedBoot masks all interrupts on the
virtual channels but don't mask one source. That source is the DBG ISR
vector. That's normal. We desire to stop a program with Ctrl-C. This is a
way to inform RedBoot's GDB things to invoke a break command. If you look
at the first 'start' function, this calls the 'hal_ctrlc_isr_init'. That
just says the debug COMM driver, unmask the debug ISR vector. That does
it. In far, 'hal_ctrlc_isr' handler will be to call itself from the
'hal_default_isr'. That 'hal_ctrlc_isr' handler read a character from
the debug virtual channel and if that character isn't an ascii ETX,
clears that interrupt and quite returns 0, i.e. !CYGINT_ISR_HANDLED.

So, if a read value is any odd character, that returned 0 occurs the
spurious interrupt report. I did think, okay, lets my 'hal_ctrlc_isr'
returns !0 every time. I did think that is a solution, but unexpected
I got an interrupt loop with it. It looked like that what something
unmask the vector too fast after an interrupt acknowledgment. Was that
new odd character on the virtual channel? I didn't understand. Perhaps,
the twice-read was wanted.

At the end, I did decide to attach own interrupt handler for the debug
ISR vector instead of the 'hal_default_isr'. I put a piece of code in my
plf_misc.c:hal_plf_hardware_init() function. That attach to the DBG ISR
vector such a tweak

        cyg_uint32
        gdb_isr (cyg_vector_t vector, CYG_ADDRWORD data)
        {
             HAL_INTERRUPT_MASK (vector);
             return hal_default_isr (vector, data);
        }

It works for me. And with the tweak I can debug the threaded application
with GNU gdb 5.3 (eCosCentric) very smoothly. The Ctrl-C events in GDB
are handled as we can expect. Tomorrow, I put new olpc*.epk on my web.

Thanks for the feedback,

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