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

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

[bugzilla-daemon]

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.

[Bug 1000660] ARM HAL breaks on spurious interrupt

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000660

Morten Lave <ml@tctechnologies.tc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ml@tctechnologies.tc

--- Comment #4 from Morten Lave <ml@tctechnologies.tc> 2011-02-23 15:39:22 GMT ---
I have seen the same problem and it is in both eCos 2.x and 3.0. We have
created a fix which has worked well for 2.x and this as far as i can see works
for 3.0 as well. The fix seems to be along the same lines as what has allegedly
been done in eCosPro.

We have replaced:
        // The return value from the handler (in r0) will indicate whether a 
        // DSR is to be posted. Pass this together with a pointer to the
        // interrupt object we have just used to the interrupt tidy up routine.

                              // don't run this for spurious interrupts!
        cmp     v1,#CYGNUM_HAL_INTERRUPT_NONE
        beq     17f
        ldr     r1,.hal_interrupt_objects

With
        // The return value from the handler (in r0) will indicate whether a 
        // DSR is to be posted. Pass this together with a pointer to the
        // interrupt object we have just used to the interrupt tidy up routine.

                              // don't run this for spurious interrupts!
        cmp     v1,#CYGNUM_HAL_INTERRUPT_NONE
        //ML23-02-2011, even spurious interrupts must unlock scheduler
        moveq   r0,#0         
        ldr     r1,.hal_interrupt_objects

This will make sure that interrupt_end is called even for a spurious interrupt
but no DSR is posted as r0 is zero and therefore the vector is ignored.

This fix replaces a conditional branch with a conditional move so it would not
add any latency to regular interrupt processing.

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