Re: [Bluez-devel] CSR firmware question...

[Carl Orsborn <cjo@csr.com>]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

Jean Tourrilhes wrote:

>>Can you reveal what you're doing with the CSR device when
>>you suffer deadlock?  We may recognise the symptoms, and possibly
>>know of a workaround or of fixed firmware.
>>    
>>
>	Trivial deadlock :
>	initiating a connection to a device within 80ms of receiving
>incomming connection from same device. Unknown if bug is in fw or
>stack, but firmware deadlock.
>
Is the incoming connection a connection request from the remote device, or a
connection complete?

If the latter, is it from an auto-accept filter, or from your host 
accepting the connection?

This feels as though it might be from an LMP collision - one of the 
nastier elements
of the baseband specification.  When collisions occur (two devices 
initiate LMP
transactions at the "same" time) the firmware sometimes defends itself 
with lengthy
timeouts, but I'm unaware of any resulting deadlocks in current firmware.

>	Intermitent failure :
>	Initiating connection (page) within 20ms of bringing HCI
>device up. Sometime it works, sometime it doesn't.
>  
>
I assume "bringing HCI device up" means your local BT device.  The CSR
device should be ready for a single HCI command as soon as the host 
transport
is established, though to signal readiness, the device sends a NOP 
command_complete
to the host when it starts.  I don't know if your host code waits for this.

It's fairly common for host stacks to use an HCI Reset command after a 
device
has started.  I don't know if your host code does so, but this shouldn't 
matter.

You say the device sometimes doesn't work.  How does the host perceive
the command doesn't work?  Failure to respond, or command rejected?

Carl

[-- Attachment #2: Type: text/html, Size: 2290 bytes --]