[Bug 1000660] New: ARM HAL breaks on spurious interrupt

[bugzilla-daemon at ecoscentric dot com]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000660

           Summary: ARM HAL breaks on spurious interrupt
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: ARM
            Status: UNCONFIRMED
          Severity: major
          Priority: normal
         Component: HAL
        AssignedTo: jifl@ecoscentric.com
        ReportedBy: pvanvugt@axys.com
         QAContact: ecos-bugs@ecos.sourceware.org
             Class: ---


Overview:
I see from the mailing list that this issue is not new. The way that the ARM
HAL's vectors.S handles spurious interrupts is badly broken, pretty much as
described in:
http://www.mail-archive.com/ecos-discuss@ecos.sourceware.org/msg05895.html

Steps to Reproduce:
The source of the spurious interrupts is similar to this one:
http://www.mail-archive.com/ecos-discuss@ecos.sourceware.org/msg02237.html ,
albeit with different hardware. I have a UART that is generating an RX timeout
interrupt and then clearing it shortly thereafter when a start bit is received.
The errata sheet from TI (see the first entry on
http://focus.ti.com/lit/er/sllz049/sllz049.pdf) documents this issue.
Understandably, this is a hard one to reproduce.

Build Date & Platform:
AnonCVS 2008-12-11 Atmel ARM7TDMI

Additional Builds and Platforms:
All ARM

Additional Information:
It is unavoidable that hardware will sometimes cause spurious interrupts that
cannot easily be fixed, such as in my situation.

I don't want to stop using the UART FIFO and I cannot easily switch UARTs, so
the only solution is to fix eCos' handling of spurious interrupts. I tried the
solution suggested in
http://www.mail-archive.com/ecos-discuss@ecos.sourceware.org/msg02242.html ,
but I still ran into other problems, such as the kernel reporting that my main
thread had exited after a spurious interrupt, which basically broke everything.

I would offer to fix the current ARM HAL, but that looks like a lot more work
than I have time for. I plan to fix my HAL by adding a new interrupt number
(increment CYGNUM_HAL_ISR_MAX) and then redefining CYGNUM_HAL_INTERRUPT_NONE
from its current value of -1 to CYGNUM_HAL_ISR_MAX. Either the hardware
initialization or the kernel initialization will then install an empty ISR.
This way, the handling of spurious interrupts will be pretty much identical to
that of regular, legitimate interrupts, and the incurred performance and code
size overhead will be negligible. Furthermore, I can also instrument the
spurious interrupt ISR/DSR if I need to. It would be nice if I didn't have to
fork my code base, but I can see that it would be a lot easier to fix the ARM
HAL than to update and test every architecture's HAL in this manner.


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.