RE: [ECOS] Serial Tx problem

[Gary Thomas <gary at mlbassoc dot com>]

On Wed, 2005-11-16 at 09:00 -0500, Joe Porthouse wrote:
> Andy
>   I am currently writing serial drivers for the PXA255 as well.  Since we
> are dealing with RS485/422 with transmitter enable outputs we could not use
> the default serial drivers and wrote our own.  Are you using the eCos driver
> or are you building your own?

What kept you from just extending the existing drivers?

>   I have run into a different but similar problem.  I have no problem with
> small packets, but when my packet size is 700 bytes or so I start loosing
> some RX data.  With FIFO enabled I loose 32 bytes at a time, sometimes less.
> With FIFOs disabled I loose 10 bytes or less at a time.  It takes a while to
> see (300,000 bytes round trip to occur a few times).  I can see the bytes
> are never pulled from UART but I also don't get an overflow error.
>   I believe my problem may be that the default drivers are still loaded and
> on a poll basis they may be draining my RX chars.  Since my new driver is
> not using the Virtual Vectors, I am still trying to figure out how to remove
> the default drivers.

Try turning off CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT

>  
> Joe Porthouse
> Toptech Systems, Inc.
> 280 Hunt Park Cove
> Longwood, FL 32750
> 407-332-1774 x-265
> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andy Atkinson
> Sent: Wednesday, November 16, 2005 12:54 AM
> To: ecos-discuss@sources.redhat.com
> Subject: [ECOS] Serial Tx problem
> 
> Hi All
> 
> I am using an Intel PXA261. I have the BT-UART setup for 115200 baud
> with FIFOs enabled (half-full thresholds). Up to now we have only
> transmitted low-volume, bursty trafiic through the UART and out to our
> Bluetooth device. We have recently attempted to stream a lot (>1MB) of
> data through the UART and have come across an 'interesting' problem.
> 
> Every once in a while the transmission just stops. When we detected that
> the buffer (in the io layer) was no longer being drained, we inspected
> the IIR register and the status indicated that the THR and the
> shift-register were both empty. So why did everything just grind to a
> halt? It looks like the UART did not generate an interrupt. Anyway, we
> manually loaded the THR and off we went again until, some time into the
> future it all stopped again. Once more the IIR gave the same info.
> 
> Upon consulting the newsgroup archives, I came across the following
> thread:
> 
> http://sourceware.org/ml/ecos-discuss/2005-05/msg00243.html
> 
> This looked like what we needed (although if this really is the required
> fix it doesn't really explain how our Tx ever gets going in the first
> place as data is only loaded into the THR upon a Tx interrupt, so how
> does the first byte ever get in there? Does the BT-UART generate an
> interrupt when it is empty?). We implemented this fix and all was well
> as long as we used non-blocking IO calls. If we switched to blocking IO,
> we were back in the original situation.
> 
> Can anyone shed any more light on this problem?
> 
> Any help appreciated.
> 
> Andy Atkinson
> 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 
> 
> 

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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