"Joe Porthouse" <[EMAIL PROTECTED]> writes: > Clearing this interrupt occurs if you read from the Receiver FIFO, set the > FCR[RESETRF] bit or A NEW START BIT IS RECEIVED!!! > > So if the RX FIFO is below the trigger point and a timeout occurs an IRQ > request is generated, but if a new start bit is detected the IRQ request is > then immediately cleared. :(
That certainly sounds like the cause of your problems. It sounds like there is no way to fix it without disabling the timeout interrupt. I'm not sure whether it is a bug in the UART for cancelling an interrupt it has raised, or a bug in the interrupt controller for not latching interrupt requests. At least it seems to be a fairly narrow race window, so isn't going to interfere with performance too much. > > Wow an interrupt that can clear its own IRQ request before service occurs!!! > That would surely cause a Spurious Interrupt. > > If my conclusions are correct and I want don't want characters to hang out > in my RX FIFO I will either need to: > #1. Stop using the UART FIFO. > #2. Poll the FIFO for trailing characters. > #3. Live with the Spurious Interrupts as a processor UART design issue. > > I will probably follow through with #3 by commenting out lien 951 and 952 in > the /hal/arm/arch/current/src/vectors.S file. > That sounds like the best approach. I guess we ought to take a look at making this a permanent feature. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss