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

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
Received on Thu Mar 03 2005 - 17:33:43 EST