Serial Tx problem

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Serial Tx problem

Andy Atkinson
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

Reply | Threaded
Open this post in threaded view
|

RE: Serial Tx problem

Joe Porthouse
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?
  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.
 
Joe Porthouse
Toptech Systems, Inc.
280 Hunt Park Cove
Longwood, FL 32750
407-332-1774 x-265
-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Andy Atkinson
Sent: Wednesday, November 16, 2005 12:54 AM
To: [hidden email]
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




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

Reply | Threaded
Open this post in threaded view
|

RE: Serial Tx problem

Gary Thomas
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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Andy Atkinson
> Sent: Wednesday, November 16, 2005 12:54 AM
> To: [hidden email]
> 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

Reply | Threaded
Open this post in threaded view
|

RE: Serial Tx problem

Joe Porthouse
Re: "What kept you from just extending the existing drivers?"
Knowledge!!!  I have been working with eCos for about 3 months writing my
application.  I have no problem with hardware code, but I am still getting
up to speed on the eCos code architecture.  I am using an Arcom PXA255 eCos
release that was originally used to build RedBoot only, but it looks like
the current serial drivers are only poll based.  I'm still looking for the
actual PXA255 serial code that I can extend/replace.

Joe Porthouse
Toptech Systems, Inc.
280 Hunt Park Cove
Longwood, FL 32750
407-332-1774 x-265

-----Original Message-----
From: Gary Thomas [mailto:[hidden email]]
Sent: Wednesday, November 16, 2005 9:10 AM
To: [hidden email]
Cc: eCos Discussion
Subject: RE: [ECOS] Serial Tx problem

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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Andy Atkinson
> Sent: Wednesday, November 16, 2005 12:54 AM
> To: [hidden email]
> 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