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

On Fri, Mar 04, 2005 at 07:33:53AM -0800, Will Spruce wrote:
> Can anyone can point me to some more documentation
> regarding how the processor and the bluetooth modules
> are connected?

The principle documentation is the pxa250 and pxa255 processor manuals.
Note chapters 4, 10 and 17.

The pxa255 processor manual can be found here:
ftp://download.intel.com/design/pca/applicationsprocessors/manuals/27869302.pdf

I have been unable to find a freely available datasheet for the lmx9814.
Let me know if you find one. The lmx9820 datasheet is publicly
available, but it as a 20 instead of a 14 for a reason. I imagine it
doesn't work the same.

The code for all of this is split between bluez (obviously),
drivers/serial.c and the h5400 and pxa code in arch/arm/mach-pxa in the
hh linux-2.4 kernel cvs.

Keep plugging away! I will provide as much support as I can. Bluetooth
is the one major non-working piece of the h5400 port.

E

> --- 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
> _______________________________________________
> H5400-port mailing list
> H5400-port_at_handhelds.org
> https://www.handhelds.org/mailman/listinfo/h5400-port

-- 
Erik Hovland
mail: erik AT hovland DOT org
web: http://hovland.org/
PGP/GPG public key available on request