This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Serial overruns


> Jonathan Larmour <jlarmour@redhat.com> writes:
>
> > Still, hardware flow control should prevent this. It looks like
> it's gotten
> > broken since the PC target uses the generic 16550 serial driver
> (assuming
> > you are using anonymous CVS, not 1.3.1), and that supports it.
>
> What, even though it is the FIFO in the chip that is overflowing? I
> thought the hardware flow control was activated by software when the
> buffer in the serial driver reached the high watermark? If this is the
> case, then hardware flow control won't help a bit...or can the UART
> itself active flow control?

Some UARTs can handle h/w flow control automatically in the chip - the bog
standard 16550 can't. So I agree that it won't make any difference.

> Incidentally, I tried an intermediate buffer in the ISR, and it didn't
> make any difference, so I'm guessing the ISR is just not getting run
> in time.

I had a look at my initial solution and realised it was flawed simply
because the ISR was disabling all interrupts on the serial port, i.e.:

<snip>
    cyg_drv_interrupt_mask(apcm7tdmi_chan->int_num);
    cyg_drv_interrupt_acknowledge(apcm7tdmi_chan->int_num);
    return CYG_ISR_CALL_DSR;  // Cause DSR to be run
}

at the end of the function.

(Incidentally, is it supposed to return CYG_ISR_HANDLED | CYG_ISR_CALL_DSR
or just CYG_ISR_CALL_DSR at the end? The use seems inconsistent between
platforms)

This means that the ISR will not run again until re-enabled right at the end
of the DSR, so the interim buffer only helps by sucking out (in my case) 8
characters from the Rx FIFO, which gives it twice as long to overflow -
hence the small improvement I saw. Having the serial port interrupt disabled
from the ISR to the end of the DSR would therefore I guess probably account
for the overflow on the receive side I am seeing, especially when running
from relatively slow memory.

I have subsequently modified my serial port drivers to only disable the
interrupts which are handled in the DSR, i.e. leave Rx interrupts enabled,
and to use the interim buffer. This seems to have fixed the problem - I can
now run out of flash with no overrun errors.

I am in the process of applying the equivalent changes to ser_16x5x.c, but I
have no way of testing it. It's not quite as straightforward as the ARM
Prime Cell UART to implement. If you'd like me to send you the completed
file, let me know.

>
> > This used to work. So if anyone has time to look at that, that would be
> > good.
>
> I'll have a look, see what I can come up with. It could well be
> something else I've screwed up :), so I'll test it with a much
> simpler application.

Any other information you find out would be appreciated.

Robert Cragie
Design Engineer
Jennic Ltd.
Furnival Street
Sheffield
S1 4QT
United Kingdom
Tel: +44 (0) 114 281 4512
Fax: +44 (0) 114 281 2951
mailto:rcc@jennic.com
http://www.jennic.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]