This is the mail archive of the ecos-discuss@sourceware.org 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]
Other format: [Raw text]

Re: Uart missing chars when in Release


On 2008-01-28, Laurie Gellatly <laurie.gellatly@netic.com> wrote:

> Reading the LPC manual I thought that just looping thru reading
> as many chars as were available could (if a new char arrived
> while looping) remove a newly arrived OE.

It would.  If you want to detect overrun errors, you have to
check the OE bit every time the LSR is read.

> The original code loops reading the LSR to check for any chars
> available which also clears any OE that might have happened
> after the original interrupt and while you were looping.

I see.

> I changed the RDA case to just read a threshold full (not
> touching LSR) so that it would preserve the error till
> interrupts were enabled again. I can see I misunderstood you.
> I checked out a fresh copy via CVS and ser_16x5x.c is what I
> started from.

Sorry about the misunderstanding.

> I just changed the BCFG for the RAM bank to be make accessing
> RAM as slow as the flash. Running the test again did produce
> just a few errors. RAM is normally 15ns and flash 70ns on my
> board.
>
> I then slowed comms to 9600 baud and that works perfectly with
> code running from flash.

I'd say it's definitely an interrupt latency issue.

> So, how would you approach this now?

With a threshold of 8, that shuold give you almost 700us to
respond to an interrupt.

The first step is to find out why interrupts or DSRs are being
disabled for so long.  It's probably a DSR that's running
longer than 700us.  If that's so, you need to figure out what
DSR is running longer than that and speed it up.  Locating all
the ISRs and DSRs in RAM appears to be one solution.  It would
be instructive to know which DSR is taking too long.

The way I usually do that is to instrument all the DSRs so that
they set a spare port pin high at entry and low at exit.

Then you hook a scope or logic analyzer up to the spare port
pins and see where the problem is.

Once you know where the problem is, you can break the culprit
up into a state machine that runs for a little while
(performing part of the work), then reschedules itself (which
will let other DSRs run) and exits.

-- 
Grant Edwards                   grante             Yow! Was my SOY LOAF left
                                  at               out in th'RAIN?  It tastes
                               visi.com            REAL GOOD!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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