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

On Mon, 14 Mar 2005, Erik Hovland wrote:

> On Mon, Mar 14, 2005 at 11:02:50AM +0100, Catalin Drula wrote:
> > 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?
>
> Yes, both the uart on the lmx9814 and the hwuart have a fifo for storing
> values and a scratch buffer for reconstructing bytes.
>
> Does changing the speed of the hwuart cause any change in behavior? I
> noticed in your previous post that you were using 921kbps. This is
> optimal from both a bandwidth and power situation. But maybe there is
> something up with the uart at certain speeds.

I do not think the speed can be changed. The LMX9814 UART is set at
921kbps. I've looked at the datasheet for LMX9820 (as there is not one
available for 9814, but 9820 seems similar enough), and that one has two
lines for selecting the speed (when both lines are set to 1 the 921kbps,
8N1 communication mode is set). I don't know if those lines are connected
to the PXA255 in the h5550, but I think not (the wiring is in
include/asm-arm/arch-pxa/h5400-gpio.h; it looks pretty complete and
there's no mention of these pins).

> Also, do you know what the value is in the uart fifo before it makes it
> to bluez? drivers/char/serial.c still has a chance at fudging the
> values.

I thought about that and I instrumented drivers/char/serial.c to see what
happens. I am about 99% sure the right values get in the FIFO and the FIFO
does not overflow, etc (anyway that would explain missed bytes, but not
corrupted ones).

> I like your diagnosis though. I am willing to blame the lmx9814 for
> this.

I'm getting close to writing a test program on Windows CE on the h5550 to
try to reproduce the problem. That would be the definitive argument that
9814 is the culprit. We could also then raise the problem with HP. I think
the 9814's firmware could be updated. The specs for 9820 say that there
are two lines called ENV1 and ENV2. When they're both up "normal
operation" is selected; however if one is 0 (I forget which), then some
mode is selected in which the firmware could be updated as far as I
understood. Those two lines, ENV1 and ENV2, _are_ connected to the PXA255
in the iPAQ (as h5400-gpio.h and h5400.c proves it).

> Maybe there is a way to recover more gracefully with bluez such
> that it doesn't make the hw out of sync assumption on the bad packet.

Yes, there is. I had written a patch for Bluez a while ago such that when
a "Hardware Error" event is sent, a "Reset" command is sent back to the
controller. By the way, this was what the "hcitool cmd 0x03 0x0003"
command that I've recommended to people does, it sends a "Reset" command).
Now this works most of the time for restoring the device useable, at the
price of broken connections. I do have the impression from my tests that
it does not always work though.

> Could you give us an idea of how many transmission errors per second
> show up on small packets and big packets?

I'll try to post some statistics. From what I remember with small packets
(12 byte payload; total size of HCI frame: 20 bytes), after a few tens of
such packets (or frames, one frame for one packet when packets are small)
the first error occured.

Catalin

ps I am subscribed to the h5400-port mailing list now so no need to cc: me
Received on Mon Mar 14 2005 - 14:28:58 EST