Re: [patch] HWUART instead of BTUART on the h5550 (workaround for Bluetooth UART overruns)

Hi,

The Bluetooth troubles are not (completely) gone on the h5550. I
wrote a message to Jamey Hicks (which as I understand works for HP so
maybe he has access to more information) about these remaining problems
which you can find attached.

I'd be willing to bet that this is an internal problem of the Bluetooth
module on the iPaq which probably does not show under typical use in
Windows (transfering photos from the digital camera, sending stuff to the
printer, etc). To test my theory I'll try to reproduce the problem on
Windows.

Any ideas or suggestions are welcome. Especially maybe people with more
hardware experience can explain how the value of a byte while it gets
moved around in a computer can get corrupted. I can understand how it can
get overwritten as a whole (for example, in the case of UART overruns).
But how can only some of the bits within be corrupted is beyond me. I mean
I assume that even if the UARTs perform serial transmission (bit by bit),
they do have a buffer were bytes are reconstructed before being moved
further, don't they?

Catalin

---------- Forwarded message ----------
Date: Thu, 10 Mar 2005 19:59:58 +0100 (CET)
From: Catalin Drula <catalind_at_horus.imag.fr>
To: jamey_at_handhelds.org
Cc: jamey_at_crl.dec.com
Subject: Bluetooth on the h5550 (wrote patch, made progress,
     some problems remain)

Hi Jamey,

I recently wrote a patch so that the HWUART is used for communicating
to the Bluetooth module (instead of the BTUART) on the iPAQ h5550.
You can see at these addresses:

http://www-lsr.imag.fr/Les.Personnes/Catalin.Drula/bluetooth.html
http://www.handhelds.org/moin/moin.cgi/HpIpaqH5400

Before there used to be overruns at the BTUART. With this patch they
seem to be gone. This improves the general stability of Bluetooth on this
model.

However, there seems to be an even more difficult problem. This time on
the sending side, there seem to be some kind of overruns at the UART in
the Bluetooth module, or transmission errors, something of that sort.

The problem shows up especially when using small packets. Thus it seems
to be related to the packet rate, rather than the byte rate. What happens
is that after some use, the BT module receives a sequence of bytes that
is corrupted (not what was sent).

Here's an example:

This is what's sent (the payload of an L2CAP packet):
7B 01 00 00 0C 00 7F 7F 7F 7F 7F 7F

This is what's received at the other host:
7B 01 00 00 0C 00 7F 7F FD FD 01 20

The following frame (we are talking about the HCI over UART frames that
consist of a one byte header and then the HCI command with the L2CAP
packet) has a corrupted header (a valid header is only 0x00 to 0x04). The
BT module notices this, and since it assumes it's lost synchronization
with the host, it sends a "Hardware Error" event back to the host.

In the example above the full HCI frames on the sending side were:

< 02 01 20 10 00 0C 00 40 00 7B 01 00 00 0C 00 7F 7F 7F 7F 7F
  7F
< 02 01 20 10 00 0C 00 40 00 7C 01 00 00 0C 00 7F 7F 7F 7F 7F
  7F

As you can see the 0x01 and 0x20 at the end of the first corrupted frame
seem to come from the second HCI frame that was sent to the controller.
That would mean some overruns occured, or somehow some bytes got lost.
What's worse is that there are some altogether corrupted bytes in there
(the 0xFD instead of 0x7F).

I know this message contained quite a bit of Bluetooth-related information
which you might be unfamiliar with and I apologize for flooding you like
this. But the real point here is that this is not a Bluetooth/Bluetooth
stack related problem, but a problem either in the transmission between
the HWUART in the PXA 255 and the UART in the LMX9814, or some internal
problem of the LMX9814.

Please note that after applying my patch, the general stability of
Bluetooth is much improved. With larger packet sizes (for example, 672
bytes, which is the standard MTU size) I can transfer data for 12h
continously (at 80KB/sec) with no problem.

I am wondering if the same problem does not occur on Windows CE. I'd be
willing to write some test programs for it provided that there's a freely
available SDK for Bluetooth on WinCE.

I'd be very grateful for any help,

Catalin
Received on Mon Mar 14 2005 - 05:05:26 EST