[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:
>>> 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).
> I have now do my tests with CRCs enabled. OpenBT dynamically test if the
> module is doing CRC checking and use it if the CSR to it.
> This correct some more errors, but not all. Sometime, the data transfert
> stops. I don't know if this is normal : my opinion is there is lot of
> errors. See the attached log : about 958 packet completed, 48
> out-of-order packet, 5 incorrect length and 8 incorrect CRC. This mean
> an error of 6%. Just for information, this is a transfer of 1.3 MB via
> OpenObex over RFCOMM. This log if for a "good" file transfert. File
> transfert is OK about 2 times for 3. (1 transfert stops during the
> transfert).

The log information you enclosed is not really that helpful for
determining the problem. What would be useful is a log of all the bytes
received at the UART. If you could arrange for the host stack to put a
copy of every byte it receives into a file, then we could analyse that
and look at the types of errors to see what's the limiting factor. This
may require modifying the host stack.

Ideally, we'd like an independent log of the bytes going over the UART.
However, this would require extra hardware.

For example, suppose we received:

  c0 00 00 c0

We could presume that the actual packet was:

  c0 00 00 00 ff c0

and that 2 bytes were lost. This would indicate either a FIFO overrun
on the receiver or parity errors (causing bytes to be discarded). To
distinguish the two we could look at the precise pattern of omissions.

If the ommissions tend to be runs of consecutive bytes then we'd favour
receiver FIFO overrun as the explanation. If they appeared to be
scattered randomly and rarely then parity errors due to to single bit
corruption would seem more likely.

If, on the other hand, we received:

  c0 00 04 00 ff c0

We'd suspect single bit corruption (00 corrupted to 04). If this were
the dominant mode then we'd also expect parity errors (if we didn't
get parity errors then we'd suspect that parity checking were disabled).

If we suspect FIFO overruns are the dominant cause of failure then we'd
need to look at boosting the priority of the kernel UART interrupt
handler that's handling emptying the FIFO. Or maybe we'd want to lower
the trigger point so that the FIFO is emptied earlier. We could also
look at enabling CTS/RTS flow control on the transport to allow the
FIFO to tell the host controller that its buffer is full. If it's
possible we could try adjusting the threshold at which the FIFO 
asserts and deasserts flow control.

If we suspect single bit corruption then we'd be looking at electrical
noise as the most likely explanation. In this case, playing with the
FIFO and the interrupt handler isn't going to help. The exact solutions
we'd try would depend on the setup you have, but we could, for example,
try replacing the UART cables with higher quality shielded cables. 

It would be even more useful to log the bytes going in both directions.
That way we can check what was happening when the file transfer stops.
This would allow us to diagnose a wide variety of errors such as a
leak of HCI flow control tokens, a leak of RFCOMM flow control credits,
incorrect SLIP decoding, incorrect calculation of the BCSP windows and
several others. For this to work you need an interleaved log where the
bytes going in both directions go into one file with the correct timing
relationship. This can make for very big files.

>> 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.
> Do you say if we have FIFO overrun, this is in the reception end, not
> in the transmition end ?

Not quite. Only receive FIFOs are sensitive to FIFO overrun. The
equivalent problem on transmit just causes data to go slowly. What I
was saying is that there is no receive FIFO on the CSR end. We use
a different technique, essentially the UART data is DMA'd into memory.

This means I'd expect FIFO overrun errors only for packets going from
the host controller to the host, not from the host to the host

	- 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