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