Writing BT stack to connect with Wiimote - problems connecting

I swapped out the troublesome wiimote for another one. I am now back to where I started: I am able to inquire and connect to the (different) wiimote - but it disconnects almost immediately. (Error code==0x16 "Connection Terminated by Local Host")

I'm using the exact sequence to establish the L2CAP channel as in the log you provided (with the exception that the connection handle is different). I'm using:


02 2A20 0C00 0800 0100 02 01 0400 1100 4300

HCI trasport - ACL data
Connection handle 0x002A, PB 0b10, BC 0b00
Packet length 0x000C
L2CAP header - length 0x0008
L2CAP header - channelID 0x0001 (signaling channel)
signal command 0x02 (connection request)
id 0x01
data length 0x0004
PSM 0x0011
source channel ID 0x0043

Is is possible to conduct an experiment with a working wiimote connection? I'm wondering if the wiimote behaves differently (than the BT dongle I was using) in that it will accept a connection but will drop that connection if the HID channels (PSM 11 and 13) are not established within a timeout period. I could understand this behavior since in normal operation the wiimote is always using those channels and does not need to support any others (although from the log I can see it also supports PSM 1 for SDP). (The BT dongle accepted a connection and it was not dropped even though I did not establish any L2CAP channels) I'm trying to break this down into smaller pieces and look for a way to understand what is happening.

I have never received any ACL data. When experimenting with the USB dongle on my desktop, I did receive a Number of Competed Packets event when I sent ACL data to that device (attempting to establish an L2CAP connection but never ACL data back with the connection response.

Is there something that can be interfering with receipt of ACL data? I was wondering if flow control may be an issue.



Edited 1 time(s). Last edit at 06/11/2013 06:15PM by ags000.

Have you tested sending/receiving ACL data when connected to something other than a wiimote? Nearly every device supports SDP, for example.

That's what I was testing when I started using the BT dongle instead of the wiimote.

I was able to send ACL data (based on the "Number of Completed Packets Event" received) with the BT dongle. However, I never received any ACL data (there was never an acknowledgement of the connection request). This is how I got into the LLID and BT version issue. I observed that if I use the LLID (PB flag) of 11 (which appears to be correct for v4.0 but not v1.2 as you point out) with the BT dongle (which is v4.0) then I receive the "Number of Completed Packets Event" (but still no acknowledgment of the connection request). If I use the LLID (PB flag) of 0b10 (which is valid for v1.2 but not v4.0) then I get neither the "Number of Completed Packets Event" nor an acknowledgment of the connection request from the BT dongle.

My hypothesis is that with the BT dongle (v4.0) and an LLID/PB value of 0b11, that represents a complete L2CAP PDU and it is forwarded on by the remote controller (in this case as a signaling command on (fixed) channel 1). That is why I receive the "Number of Completed Packets Event". When I use the LLID/PB value of 0b10, that is a start packet, and the local controller is waiting for the continuation packet. While that may be plausible, that would imply that there is not backwards compatibility, which I find unusual. Also, while I'm clearly not an expert, it seems that the controller could easily recognize an L2CAP B-frame (complete L2CAP PDU) and know that the packet is complete. (if I understand correctly).

This is why I started wondering if there is some flow control setting (on my host controller - not the BT dongle or the wiimote) that is interfering with reception of the ACL data. Since I'm using a UART HCI transport, I only have RX and TX lines, and the RX path through my UART is working because that's the path to receive events from the controller.

Is it possible to validate that the wiimote will maintain a connection (link) with another BT device even if no L2CAP channel is established within some timeout period? I am only seeing the disconnect when using the wiimote, not the BT dongle. (but still, I can't establish an L2CAP channel on either)



Edited 1 time(s). Last edit at 06/11/2013 07:34PM by ags000.

Do you use the HCI_read_buffer_size and HCI_host_buffer_size commands as part of the controller initialization? Is flow control left off (by default) or explicitly enabled?

I do not use any of these commands. As a matter of fact, I do nothing to initialize the local controller, other than issuing a Reset Command. If there are critical initialization steps please point me towards them. I note from the spec regarding the Read Buffer Size Command:

Quote

The Read_Buffer_Size command must be issued by the Host before it sends any data to the Controller.

I can see this is good practice, but will violating it cause a problem? Since the data packets from the wiimote are so small, I was simply going to use buffers sized for the MTU size (48 bytes). I presume there would only be an issue if I attempted to send a data packet larger than the controller's buffer size. I will test it later just to be sure.

I also noted that upon power-up of the local controller (but not on reset) an event packet is sent by the controller. I presume this is some manufacturer-specific information (I will contact the manufacturer to verify) - have you heard of such a thing? I don't recognize the event code 0xFF. The byte sequence is:

04FF1FC302000F000D000010000037000100004E0100000000000000000000000000

A basic init sequence is:
- hci_reset
- hci_read_buffer_size
- hci_read_bd_addr
- hci_host_buffer_size
- hci_write_pin_type(0 = variable)
- hci_write_page_timeout
- hci_write_scan_enable(2 = page scanning enabled)
Additional optional commands (things the wiimote doesn't care about but are good practice):
- hci_write_cod
- hci_change_local_name


"The event code 0xFF is reserved for the event code used for vendor-specific debug events." Manufacturer specific stuff, for example the wii uses it to signal when the red sync button on the front panel has been pressed.

You may be onto something with setting the host buffer size. As I read the spec, it says that if not set, the controller will assume that it can send an unlimited number of data packets of any size it wants. Also, if controller-to-host flow control is not enabled (which is the default, and I am not enabling it) the number of packets is not used anyway. However, I'm more interested in making this work than interpreting the spec...

When I tried to set the host buffer size with the Host Buffer Size command, there was no response. It was as though the command I was sending was incorrect. Eventually, after sending other commands, I finally got a Hardware Error Event. This is what I sent to the controller:

01 330C 07 4000 20 0100 0100

Which I believe indicates:

UART HCI command; Host Buffer Size command opcode; parameter length; 64 bytes ACL data buffer size; 32 bytes synchronous data buffer size; 1 ACL data buffer; 1 synchronous data buffer

Is there something wrong with this? Some improper setting (or understanding on my part) may be why the controller never sends ACL data to the host.



Edited 1 time(s). Last edit at 06/12/2013 06:40PM by ags000.

Try increasing the ACL packet length to at least 256 and num_acl_data_packets to 16. The synchronous data parameters shouldn't matter.

I will try. It occurred to me that the parameters may be a problem, but the behavior was to just not respond at all - as if the command was never sent. Surely a reasonable expectation would be for a Command Complete event with a non-success result code. With nothing to guide me, I couldn't even attempt to guess at what would be "reasonable" parameter values.

With controller to host flow control disabled, wouldn't you expect the value of num_ACL_data_packets to be ignored and irrelevant? (I'll still try it, though). I did try values of 0 for both ACL data and synchronous data, thinking this would indicate unlimited buffers. It may be the buffer size that is the problem, even if 0 buffers is an acceptable parameter value.

Is there any way to test behavior of a working wiimote interface - to see what happens if a connection (link) is established but no L2CAP channels are established for a minute? I still don't understand why the successful connection is disconnected (every time) just seconds after the connection is established.

Wow. Not what I expected.

I tried setting the host buffer size to match the controller reported buffer sizes. This returned a success status.

Then I tried issuing the same command to establish an L2CAP channel - and same symptoms: no response at all.

In frustration (perhaps desperation) I decided to fiddle with the LLID bits. I'm still confused by the description in the spec, which seems self-contradictory to me.

As it turns out, if I issue the connection request (for an L2CAP channel) using PB of 00, I get a response! With PB=03 or 02, no response. This is really confusing. And, the response is sent with LLID = 20. I just don't understand this. (NOTE: to try to simplify, I'm testing using a USB BT dongle on my desktop, not the wiimote).

So once I send the (L2CAP) connection request (PSM==01), I receive an extended features request, then a configuration request (for MTU size). I do get a connection response with successful status. I wasn't prepared for all this traffic, so hadn't coded responses. Ultimately, the connection was terminated (reason==0x13, Remote User Terminated Connection).

So I still can't figure out the proper use of LLID, but I have successfully created my first L2CAP channel.

BTW, both the host and remote device report a version of 04, or BT 2.1 + EDR.

Still don't understand the LLID flag.

I have been successful in connecting to the wiimote with my "thin" BT stack. Thanks for all the help.

I still don't understand why I cannot send an ACL packet with PB=02. But I'm past that obstacle.