[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] Large file transfert with CSR and BCSP

Olivier Bornet wrote:
>> Check that you are using CRCs with BCSP.
> it seems the CRCs was disabled :
> Values for pskey 0x0191:
> 0x00EC 0x0006 0x00FA 0x0014 0x0004 0x0000 0x0004 0x001E 0x0064 0x000A
> I will try Monday with CRCs enabled (I have only one BT module usable
> now for making large transfert).

Ok. It may also be worth changing the fourth word from 0x0014 to 0x0000.
This word controls how many times the host controller will attempt to
talk to the host before it gives up and assumes the host has crashed.
Setting it to 0x0000 will turn off this feature. This may help with
debugging as if you stop the host stack, the host controller will keep
retransmitting indefinitely. This should give you enough time to
come in to the stack, examine variables, set breakpoints and restart
without losing the link.

>> The host controller can be configured to send them or omit them.
> When you say "the host controler", this mean the PC where I have my BT
> device connected to ?

Sorry, confusing Bluetooth terminology. The PC is the host and the
Bluetooth device it's connected to is the host controller.

>> Obviously, this will make a difference only if the host stack is
>> checking the CRCs. You should also make sure that the host stack is
>> appending the CRCs when it sends data to the host controller.
> OK. So the question is : Is OpenBT adding CRCs ? This is the point I
> must control if I understand correctly.

Well, the question is two fold. For maximum benefit, OpenBT must add
CRCs on data it sends. Actually errors are less likely this way as
UART reception on the CSR chip is handled by a variant of DMA rather
than by FIFOs - this makes FIFO overrun impossible.

However, much more importantly, in order for reconfiguring the host
controller to make any difference, the OpenBT stack must calculate and
check CRCs on reception. Obviously if the OpenBT stack were to just
throw away the CRCs then adding them on the host controller will have no
effect on reliability.

>> My guess is it's the framing errors (probably due to the host UART
>> discarding bytes due to FIFO overruns or parity errors) that are
>> giving the 'Incorrect length, discarding data' error message.
> It's also my impression. I have try to enable hardware flow control
> (with bti, I just don't have passed the -f flag). stty -a -F /dev/ttyS0
> give the flow control enabled (crtscts and not -crtscts). But I'm not
> really sure this is enough : I have see a compilation flag in OpenBT :
> HOST_FLOW_CTRL. This is disabled by default. I have try to enable it,
> but this cause my T68 can't no more send a picture to my OpenBT/OpenObex
> powered PC. Without HOST_FLOW_CTRL, all is OK (seem the ObexClient on
> ttyBT0 is no more answering, but other things, like the SDP server are
> OK).

I'm not sure of what's going on in the OpenBT stack with flow control.
Someone else will have to answer that. It's possible that flag is
affecting the interpretation of the virtual flow control lines in

Note that by default BCSP on the host controller runs without flow
control (that is, it will not generate flow control signals and it will
ignore those sent by the host).

Since BCSP is essentially a reliable protocol and can cope with
errors on the UART path, flow control shouldn't be necessary as
long as most of the time bytes are transferred cleanly. For
embedded systems, this can make a big difference as the RTS and
CTS lines do not need to be connected between the host and
host controller. This saves complexity on the host as it reduces
the number of pins needed to control the host controller.

If you can't guarantee to empty your PC's UART FIFO most of the time
before it overflows then you may need to turn on flow control. An
occasionally overrun (say, at most once every 100 kB) should be coped
with reasonably by the BCSP retransmission mechanism. Be aware that
this is not the mode in which BCSP was designed to run.

If you want to try BCSP with flow control, then set the second word
of PSKEY_HOSTIO_UART_PS_BLOCK (currently 0x0006) to 0x002e.

	- Steven

The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
If you received this in error, please contact the sender and 
delete the material from any computer.
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com