[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bluetooth-dev] correction: Re: Minor suggestion - hci.c and other things
a small correction, to a previous mail, (mixed with sizes):
in btd.c in function hci_receive_data line 2467:
int len = read(phys_fd, &databuf, 4096);
if (len > 0)
the read_thread tries to read up to 4K, but that not enough yet !!
because the max size of data that ericsson units may keeps, in the RX
buffers, and then package into one HCI/ACL packet,
is up to 800*10 = 8000 chars !!!
in that case the stack gets pieces of HCI packets, and get confused.
this problem may be discover only when TX large files.
in general, a protocol stack should be able to retrieve
up to 64K frame of HCI data packet, altogether.
because theoretically some firmware may package this (2 bytes length
field), and the HCI state machine parses data by HCI-frames.
so, our suggestion is to change the 4K at the read function, into 64K.
Oren & Roman
On Sat, 9 Dec 2000, Oren Hagai CN20W01 Roman Zoltsman wrote:
> I Think we found something, check it out:
> When working in user mode on top of ericsson P9A, with Axis stack:
> Ericcson buffers size is 10 packets ACL at 800 chars each, for TX buffers.
> If the case is the same for RX buffers, the Firmware can collect up to 800
> chars before sending one HCI packet, of data (implementation specific).
> at btd.c the read_thread try to read only up to 400 chars from the uart,
> and maybe that causes to lost sync of HCI data ACL frames, when TX lots of
> data on the air-line.
> notice that that can't hurt the event packets, because they are limited to
> 256 bytes.
> we suggest to raise the amount that the read_thread should read to 1000
> bytes, or more, instead of 400.
> Oren & Roman
> Technion, Israel.
> On Tue, 14 Nov 2000, Mark Corner wrote:
> > I don't know about the firmware crash. That sounds bad :)
> > As for the NUMBER_OF_COMPLETED_PACKETS, I have seen this. It is listed in
> > the list of Axis/USB/BT bugs that I sent out. This is a serious
> > showstopper bug. Unfortuntely I am not sure what causes it!
> > A long shot but: In the USB bluetooth driver there is a section for
> > inserting a delay in the sending of URBs. Try turning just that section
> > of code on and see if it works.
> > > Within the src/hci.c file, there is a constant macro for "DIGI_EVENT"
> > > defined to be 0xFF. An event code of 0xFF is really not DigiAnswer
> > > specific. It is a manufacturer-specific error code.
> > > In an Ericsson chipset, an HCI event code of 0xFF and Event_id of 0x1 means
> > > the firmware OS has crashed. The only reason I bring this up
> > > is because I am getting a crash on my BT device. For some reason,
> > > if I send/recv alot of data with an Ericsson BT P9A device, it will stop
> > > sending ACL data - either because the firmware crashed, or because there
> > > are no available ACL slots (acl_num == 0 and BT device isn't sending
> > > NUMBER_OF_COMPLETED_PACKETS events anymore to the host controller). Has
> > > anybody else seen this? Do these problems go away with later
> > > Ericsson BT firmware?
> > >
> > > I know I need updated BT hardware. Just doing the best I can with what I
> > > got for now...
> > >
> > > Thanks,
> > > Craig Gwydir
> > > email@example.com
> > >
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
> > > the body of a message to firstname.lastname@example.org
> > >
> > ----
> > Mark Corner
> > email@example.com
> > -
> > To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
> > the body of a message to firstname.lastname@example.org
> To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
> the body of a message to email@example.com
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org