Re: h5400/h5550 Bluetooth troubles (possible cause: wlan driver)

I have also noticed the overflow issue with bluetooth.
Since I do not use the wlan, I have never noticed it
causing issues. However, I can easily reproduce
the problem by putting the ipaq in the cradle and
generating small levels of activity( ie ls a
directory ) will cause the overflows.

This same handheld running pocketpc does not seem to
have this issue. I used haret to dump the gpio
setting so I could see how the uart was being setup.
Pocket PC assigned the uart pins GPIO 42,43,44, and
45 as using alternative function 3. This defines this
uart as HWUART and not BTUART. I am not certain
exactly what the differences between defining this
uart as a HWUART and BTUART. Is it possible that
HWUART provides hardware based flow control and
prevents the overflows, while BTUART uses software
flow control and the overflows occur because the irq's
are not serviced fast enough?

My attempts to redefine pins to match Pocket PC's
setup have be unsuccessful. Simply changing these
gpio pins to use alternative function 3 does not work,
and I am unsure if there are other changes needed
elsewhere.

Can anyone can point me to some more documentation
regarding how the processor and the bluetooth modules
are connected?

Will

--- Catalin Drula <Catalin.Drula_at_imag.fr> wrote:

> Hi,
>
> I am running Familiar 0.8.0 and 0.8.1 on h5400 and
> h5550 iPaqs. I have
> been running into trouble while using Bluetooth on
> these devices. The
> problem has been reported previously on this list.
> Basically what happens
> is that under any kind of sustained transfer rate
> through Bluetooth, bytes
> get lost between the host and the Bluetooth
> controller. The immediate
> effect of this is that of losing data, but worse,
> control data is also
> lost, which eventually leads to a loss of
> synchronization with the
> controller and effectively a "freeze" of the
> Bluetooth interface. Hard
> reinitialization is usually required to get it into
> a working state again.
>
> I have noticed that these lost bytes between the
> host and the controller
> are due to overruns on the UART (the BTUART, that
> is) of the PXA
> processor. These can be seen in
> /proc/tty/driver/serial. The immediate
> cause of the overruns seemed to be the irqs
> generated by the BTUART were
> not handled in a timely manner. It seems that the
> usb-ohci irqs (for the
> wlan interface) are to blame here. Once the wlan is
> taken down (ifconfig
> down) no more overruns occur. Sustained transfer
> rates (80kB/sec) can be
> acheived for extended periods of time (e.g. 12
> hours) with no errors. I am
> not sure why the usb-ohci (or wlan driver) is
> causing this. Even if the
> wlan is not actually connected to a network, but
> it's "up" (thus
> generating only few irqs) it still causes overruns
> at the BTUART.
>
> This seems to be the biggest problem of Bluetooth on
> the h5550 and h5400.
> Some issues and instability still remains however.
> For example, somewhere
> between every 30MB and every 300MB of data
> transfered, a sequence of bytes
> (e.g. 10 to 50) is not what was transmitted. The
> test program that I use
> is l2test from the bluez-utils package. The contents
> of the L2CAP packets
> that it sends consists of a small header and then
> the rest is filled with
> the value 0x7F. Like I said, very very rarely a
> small sequence of bytes is
> wrong on the receiving end (i.e. it is corrupted,
> having a different value
> than 0x7F) . At first I was leaning to blame this on
> the inherent error
> rate of the Bluetooth baseband (which can vary
> between 10^-6 and 10^-16
> depending on packet type and BER - bit error rate
> -), but there might be
> another cause (errors of transmission between the
> UART of the Bluetooth
> module and the UART in the CPU?).
>
> Another issue is that the Bluetooth chip in the
> iPaqs does not seem to
> like concurrent ACL connections. Generally speaking
> a single L2CAP
> connection is quite stable and performs well for
> extended periods of time.
> As soon as you start experimenting with tearing down
> connections,
> injecting faults by moving out of range, more
> complex piconet topologies,
> things seem to get a bit unstable.
>
> On one occasion, in /proc/tty/driver/serial several
> "framing errors" were
> reported (this are under the rubric "fe:"). This
> only happened once and I
> do not know how to easily reproduce it, but I think
> it is very bad news.
> The PXA manual says that framing errors (quoting
> from memory) occur when
> the stop bit (which should always be a 1, if I
> remember correctly) is a 0
> (again, quoting from memory). This spells "buggy
> hardware" all over for
> me. I am more willing to believe that the UART in
> the RTX Telecom module
> (as I understand the chip is a National LMX9814) is
> buggy rather than the
> BTUART in the PXA, but it could be either, or both.
> As I said, this has
> happened only once.
>
> To conclude, removing the wlan interface, gets rid
> of most of the problems
> with Bluetooth on an h5400 and h5550. With the wlan
> interface up, overrun
> errors occur in a matter of seconds (under a
> sustained transfer rate) at
> the BTUART. Although disabling the wlan cures the
> overrun problems, there
> are stability issues with the Bluetooth interface on
> these devices, some
> of which may even be due to buggy hardware.
>
> Any comments are welcome, please cc: me in your
> replies as I am not
> subscribed to the mailing list,
>
> Catalin
>
>
> _______________________________________________
> H5400-port mailing list
> H5400-port_at_handhelds.org
>
https://www.handhelds.org/mailman/listinfo/h5400-port
>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Received on Fri Mar 04 2005 - 10:36:12 EST