Hi,
I was trying to debug the Bluetooth subsystem on an HP iPAQ h5550 running
Linux:
root@h3900:~# hciconfig -a
hci0: Type: UART
BD Address: 08:00:17:1A:EB:76 ACL MTU: 339:4 SCO MTU: 60:9
UP RUNNING PSCAN ISCAN
RX bytes:-2117082264 acl:19904935 sco:0 events:4940395 errors:0
TX bytes:386017560 acl:9879838 sco:0 commands:430 errors:0
Features: 0xff 0x3b 0x05 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: 'POCKET_PC'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Ver: 1.1 (0x1) HCI Rev: 0x180 LMP Ver: 1.1 (0x1) LMP Subver: 0x180
Manufacturer: RTX Telecom A/S (21)
The problem I am facing on this machine is that it seems that the UART
communication is sometimes unreliable. What happens is that while sending
data, there sometimes seems to be corruption between the host and the
controller. For example, doing an l2test where the iPAQ is sending to a
PC, every once in a while on the receiving side there are data or sequence
or size mismatches. After a while, the corrupted bytes happen to be in the
H4 header, and the controller assumes it has lost synchronization with the
host, thus sending a "Hardware Error" event. It then expects a "Reset"
command to resynchronize.
Since a lot of digging has not found the root cause of these errors in the
UART communication, I wanted to hack the Bluez stack to better handle when
these loss of synchronization events occur (I am not refering to patching
the main Bluez stack, but rather make a hack for our own purposes here,
and perhaps share it with other iPAQ h5550 users).
It is easy enough to add the sending of a "Reset" command after a
"Hardware Error" event is received, but I get the impression that there's
more needed, such as tearing down the established connections somehow. The
point is to get a "clean" stack to start with after such an event (and of
course, propagate the error up the stack so that the application gets a
"broken connection"). Any advice on how hard it is to do that, and what
needs to be done?
Currently, what happens is that after sending "Reset", we resynchronize
with the controller, but the previous connections still show:
root@h3900:~# hcitool con
Connections:
< ACL 00:10:DC:57:C9:79 handle 1 state 8 lm MASTER
> ACL 08:00:17:1A:E6:02 handle 2 state 8 lm SLAVE
Thanks in advance for your help,
Catalin
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Peter,
> I'm not that familiar with the architecture of BlueZ but with the
> experiences for our own stack I can tell you this is not trivial. The main
> problem here is that the Bluetooth Stack is not stateless. One possible
> solution is to feed the reset done event to the higher layers (l2cap). But
> than L2cap must be modified to correctly shut down all connections. It
> would be easier if the HCI layer tracks the state of all ACL and SCO
> connections (Marcel ??). Than a reset done event can be handled like a
> unexpected link loss on all active connections and the higher layers do
> not need any modifications (hopefully).
we can do this and actually calling "hcitool cc" does this already, but
it waits indeed for a timeout of the HCI_Disconnect.
> It may be much simpler trying to find the cause of the data corruption.
This is really the best thing to do, because H:4 is a stupid protocol if
you run it over hardware. For stack internal use it is perfect.
Hopefully 3-Wire UART will come at some time and make the H:4 obsolete.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Catalin,
I'm not that familiar with the architecture of BlueZ but with the
experiences for our own stack I can tell you this is not trivial. The main
problem here is that the Bluetooth Stack is not stateless. One possible
solution is to feed the reset done event to the higher layers (l2cap). But
than L2cap must be modified to correctly shut down all connections. It
would be easier if the HCI layer tracks the state of all ACL and SCO
connections (Marcel ??). Than a reset done event can be handled like a
unexpected link loss on all active connections and the higher layers do
not need any modifications (hopefully).
Anyway, I'm pretty sure there is no way to solve this with a simple hack.
It may be much simpler trying to find the cause of the data corruption.
Do you have hardware handshake enabled ??
Have you tried different baud rates ??
Do you get any errors from the UART driver (like FiFo overruns) ??
Have you tried to modify the UART FiFo settings ??
Good luck,
Peter
On Thu, 17 Mar 2005, Catalin Drula wrote:
> Hi,
>
> I was trying to debug the Bluetooth subsystem on an HP iPAQ h5550 running
> Linux:
>
> root@h3900:~# hciconfig -a
> hci0: Type: UART
> BD Address: 08:00:17:1A:EB:76 ACL MTU: 339:4 SCO MTU: 60:9
> UP RUNNING PSCAN ISCAN
> RX bytes:-2117082264 acl:19904935 sco:0 events:4940395 errors:0
> TX bytes:386017560 acl:9879838 sco:0 commands:430 errors:0
> Features: 0xff 0x3b 0x05 0x00 0x00 0x00 0x00 0x00
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy:
> Link mode: SLAVE ACCEPT
> Name: 'POCKET_PC'
> Class: 0x000000
> Service Classes: Unspecified
> Device Class: Miscellaneous,
> HCI Ver: 1.1 (0x1) HCI Rev: 0x180 LMP Ver: 1.1 (0x1) LMP Subver: 0x180
> Manufacturer: RTX Telecom A/S (21)
>
> The problem I am facing on this machine is that it seems that the UART
> communication is sometimes unreliable. What happens is that while sending
> data, there sometimes seems to be corruption between the host and the
> controller. For example, doing an l2test where the iPAQ is sending to a
> PC, every once in a while on the receiving side there are data or sequence
> or size mismatches. After a while, the corrupted bytes happen to be in the
> H4 header, and the controller assumes it has lost synchronization with the
> host, thus sending a "Hardware Error" event. It then expects a "Reset"
> command to resynchronize.
>
> Since a lot of digging has not found the root cause of these errors in the
> UART communication, I wanted to hack the Bluez stack to better handle when
> these loss of synchronization events occur (I am not refering to patching
> the main Bluez stack, but rather make a hack for our own purposes here,
> and perhaps share it with other iPAQ h5550 users).
>
> It is easy enough to add the sending of a "Reset" command after a
> "Hardware Error" event is received, but I get the impression that there's
> more needed, such as tearing down the established connections somehow. The
> point is to get a "clean" stack to start with after such an event (and of
> course, propagate the error up the stack so that the application gets a
> "broken connection"). Any advice on how hard it is to do that, and what
> needs to be done?
>
> Currently, what happens is that after sending "Reset", we resynchronize
> with the controller, but the previous connections still show:
>
> root@h3900:~# hcitool con
> Connections:
> < ACL 00:10:DC:57:C9:79 handle 1 state 8 lm MASTER
> > ACL 08:00:17:1A:E6:02 handle 2 state 8 lm SLAVE
>
> Thanks in advance for your help,
>
> Catalin
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
| Peter Wippich Voice: +49 30 46776411 |
| G&W Instruments GmbH fax: +49 30 46776419 |
| Gustav-Meyer-Allee 25, Geb. 12 Email: [email protected] |
| D-13355 Berlin / Germany |
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel