BTstack Pairing issue

[Lakshmi Kant]

Hello All,

I ported BTStack onto my custom FPGA running ARM processor on it. I am able to initialize the module successfully(I am seeing Bt stack up and running message for example spp counter). 

But when I try to connect with my android or any other phone, My device is getting listed but unable to establish the connection. 

I dont have the formatted printfs for my BSP. I am attaching PTS logs ( TC_COS_CED_BV_05_C) for your reference. It gets stuck at information response.

I haven't implemented timers yet in my code . So I am not using HAVE_TICK. could this be the problem?? 

I am using RTL8761AT as BT module. 

Any help would be highly appreciated. 

Regards

Lakshmikanth. 

[Matthias Ringwald]

Hi Lakshmikanth

Never heard of the RTL8761AT before. Do you have more info on it, where did you get it?

In the PTS Logs, there's no answer to an L2CAP Information Request. From the outside, it's hard to say what's causing it.

From experience, the most likely problem is that CTS/RTS is not implemented/working and packets from the Bluetooth get lost.

You could look at the UART (RX,TX,RTS,CTS) with a logic analyzer and check that BTstack raises RTS after each received packet until it has processed it.

BTstack will usually report "h4: invalid packet type". So, implementing a minimal printf would help, too.

The timers are only used for timeouts like abort stuff if the other side didn't respond on time, so don't worry about them yet.

Best

 Matthias

--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
To post to this group, send email to btsta...@googlegroups.com.
Visit this group at https://groups.google.com/group/btstack-dev.
For more options, visit https://groups.google.com/d/optout.
<Report_L2CAP_2016_01_17_00_35_49.zip>

[Lakshmi Kant]

Hello Matthias,

I haven't implemented CTS/RTS. Please let me know if it is mandatory to implement? I will start it in my FPGA IP. 

I have basic print log attached for your reference. it shows event and command packets. I don't see any invalid packet in h4 packet process. 

And the success rate is random. Sometimes all commands get through perfect. Sometimes not. 

I have attached the datasheet of BT module. Please check. 

Regards

Lakshmikanth. 

[Matthias Ringwald]

Hi

RTS to pause Bluetooth is mandatory.  - pausing the UART is part of the design. It's mentioned in the docs (
http://bluekitchen-gmbh.com/btstack/porting/#hci-transport-implementation) but it should be made more prominent. 

Sent from my iPhone

<RTL8761AT_Datasheet.pdf>

<BTStack-Pairing-issue.txt>

[Lakshmi Kant]

Hello Matthias, 

Unfortunately our UART doesn't support CTS/RTS functionality.Is it mandated by spec itself? I thought, Bluetooth commands will be processed serially, after receive response for the previous command. Please correct me if I am wrong. 

Pausing uart may effect data throughput isn't it? Is there any chance we can avoid RTS/CTS  signalling?  

Regards

Lakshmikanth. 

[Matthias Ringwald]

HI Lakshmikanth

Bluetooth HCI offers multiple transport options. The H4 transport (regular UART) requires CTS/RTS flow control. There's also an H5 transport that wraps every HCI packet into a SLIP header and can use CTS/RTS if available. In that case, I would recommend to have some buffers anyway, as resending packets also reduces throughput.

RTS is required for receiving data, so, that's HCI Events and ACL Data packets. BTstack processes both types quickly, but then notifies the app about it. Depending on the app, there's now a delay before hal_uart_dma_receive is called again. With RTS, even set manually in the hal_uart_dma, this is not a problem, as the Bluetooth waits. Without it, there's a chance to loose the first byte of the next event/data packet. On top of that, BTstack implements L2CAP flow control via the RTS too. If data arrives to fast, the Bluetooth module cannot deliver the ACL packets and has to signal to the other side to slow down.

If your UART has a minimal FIFO and your MCU is fast, you can just raise RTS in the hal_dma_uart implementation. I do this in the MSP430 implementation that don't have hardware RTS/CTS support.

If you have a DMA unit that supports ring buffers, that's even better as your FIFO is then rather large, and you can enable reading all the time and raise RTS only after half the ring buffer is full.

As for H5, I plan to implement that rather soon (probably in the next 1-2 months) as it also allows for an efficient deep-sleep, where the MCU can disable the UART clock.

Best

 Matthias

[Lakshmi Kant]

Hi Matthias,

Thanks for the information. I am using H4 transport as of now. I understood the requirement of RTS/CTS control. 

Back to my original problem, I am not receiving any invalid packet after/before I receive L2CAP information request. Btstack is being able to parse the L2cap packet and display. but unable to reply back. 

And sometimes I observed even it reply back with L2CAP info response (0x0B) it is not being shown in PTS logs (i.e, not received at central) and going unnoticed. 

Please find attached log from BTSTack. 

If you observe the logs, the module getting command status event (0x0F) for some other command (0x2B,) which has been sent previously before L2CAP information request.  Could this be happened because of no RTS? 

Thanks.

Lakshmikanth.  

[Matthias Ringwald]

Hi again

Your logs improve. Where do the additional newlines come from? Could you try to fix it so that an HCI packet is printed on a single line? tools/tools/create_packet_log.py can then convert it and I can have a look at it without decoding individual hex bytes.

Yes, the logging of an HCI event could cause the next packet to go unnoticed without RTS and buffers. 

best

matthias

<bt-stack-androidPairing-2.TXT>

[Lakshmikanth]

Hello Matthias,

I will test by driving RTS pin with GPIO and get back. 

One more query is, I am implementing A2DP on BTstack. I already implemented AVDT profile till streaming channel open. I see BTStack L2CAP layer supports signalling channels. I am glad  I able to open AVDTP signalling channel.

Is there any modification needed for L2CAP or any other layer of BTstack to accommodate A2DP/AVDTP/AVCTP profiles from streaming the audio? Please let me know. 

Regards

Lakshmikanth. 

- Lakshmikanth

On Mon, Jan 18, 2016 at 7:33 PM, Matthias Ringwald <matthias...@gmail.com> wrote:

This message is eligible for Automatic Cleanup! (matthias...@gmail.com) Add cleanup rule | More info

Hi again

Your logs improve. Where do the additional newlines come from? Could you try to fix it so that an HCI packet is printed on a single line? tools/tools/create_packet_log.py can then convert it and I can have a look at it without decoding individual hex bytes.

Yes, the logging of an HCI event could cause the next packet to go unnoticed without RTS and buffers. 

best

matthias

On 18.01.2016, at 14:55, Lakshmi Kant <laxmi...@gmail.com> wrote:

<bt-stack-androidPairing-2.TXT>

--
You received this message because you are subscribed to a topic in the Google Groups "btstack-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/btstack-dev/mUfoJLUwzfk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to btstack-dev...@googlegroups.com.

[Matthias Ringwald]

Hello Lakshmikanth

> I will test by driving RTS pin with GPIO and get back.

I'm sure this will help.

> One more query is, I am implementing A2DP on BTstack. I already implemented AVDT profile till streaming channel open. I see BTStack L2CAP layer supports signalling channels. I am glad I able to open AVDTP signalling channel.

Wow! What project are you working on? Using BTstack to deliver compressed audio data to test it with your own SBC / AAC FPGA decoder ? :)

> Is there any modification needed for L2CAP or any other layer of BTstack to accommodate A2DP/AVDTP/AVCTP profiles from streaming the audio? Please let me know.

I don't now for sure, but I hope everything is in place for that - BTstack passes all tests for basic L2CAP which is sufficient for A2DP. So far, we deferred implementing A2DP as there are so many specs (A2DP/AVDTP/AVCTP) and the need to implement at least the SBC codec, but we will take a shot at it later this year, too.

Good luck
Matthias

>
> Regards
> Lakshmikanth.
>
> - Lakshmikanth

[Lakshmi Kant]

Hi Matthias, 

Unfortunately, my module design doesn't allow me to drive its RTS/CTS pins in any way. those were connected together in the design. Any way we can use them? 

Yes I am planning to have a SBC decoder running on top of A2DP. I stuck up in L2CAP configuration request for AVDTP signalling channel. I realized, below are the sequence of steps what is causing this issue . 

1. In l2cap_run(), L2CAP_STATE_WILL_SEND_CONNECTION_RESPONSE_ACCEPT handler sets the flag L2CAP_CHANNEL_STATE_VAR_SEND_CONF_REQ.(why is it being set here??)

2. Before stack sends CONFIGURE_REQUEST in L2CAP_STATE_CONFIG handler, my module receiving CONFIGURE_REQUEST from the central device. 

3. btstack first sending CONFIGURE_REQUEST  to the central and then attends central's request with CONFIGURE_RESPONSE. (some how this response is not being reached to the central but being seen in Btstack logs).

4. Central sends CONFIGURE_RESPONSE to the request made by BTStack in step 3 and waits forever for CONFIGURE_RESPONSE for its own request. 

Please check pts screenshot attached. I have attached BTstack log too which is evidence for BTstack configure response.  

I am clueless, why the configure response from the BTSTack in step-3 is not reaching to the central. sometimes same thing happens with L2CAP information request too.

Can you please help me debugging this as this is the only gating issue to move further? 

Regards

Lakshmikanth.

[Matthias Ringwald]

Hello Lakshmi

I never really tried to run BTstack without CTS/RTS. If you're processing incoming data fast enough and have a decent size ring-buffer to queue incoming data, you might be ok without.
In theory, Bluetooth HCI supports flow control between Controller and Host for ACL/L2CAP data, but not for events. Using that would be another way to slow down the Controller - but if you cannot process audio data fast enough, you're out anyway. :)

Thanks for your analysis of your situation. After an L2CAP Connection Request and an Connection Response, both sides have to send a Configuration Request and also respond to the request from the peer. That's why L2CAP_CHANNEL_STATE_VAR_SEND_CONF_REQ is set at the same time as L2CAP_STATE_WILL_SEND_CONNECTION_RESPONSE_ACCEPT. The conf req is guaranteed to be sent after the connect response.

So, in the PTS log, the missing thing is the L2CAP Configure Response message that BTstack tries to send - as it is logged - but does not show up on the other side.
There are basically three options:
- BTstack calls hci_transport->send_packet (or whatever it is called), but the code there looses the packet. This should not happen if "can send now" is implemented in the transport and the transport sends the DAEMON_PACKET_SENT event only after it sends an ACL to the Bluetooth module
- It gets lost in the Bluetooth module. Possible, but unlikely
- It is received in the PTS module, but lost on the way to the PTS Packet Logger.

I would suggest to double check if the Configure Response reaches the Bluetooth module, either by checking code and/or also looking at the UART with a Logic Analyzer.

Best
Matthias

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
> To post to this group, send email to btsta...@googlegroups.com.
> Visit this group at https://groups.google.com/group/btstack-dev.
> For more options, visit https://groups.google.com/d/optout.

> <L2CAP_confg_issue_MSc.png><L2CAP_config_req_issue_Btstack_log.txt>

[Lakshmi Kant]

Hello Matthias,

Thanks for explanation. 

Could this be a timing issue? I have observed when I pause my code before BTstack sends the CONFIGURE_RESPONSE , and resume after a while I see the command processing perfectly. 

Regards

Lakshmi

[Matthias Ringwald]

Hi

It's not a timing issue in the sense that there are rules to obey. If the local transport and the remote side work correctly, any timing is correct.

It may be that different timing can cause a bug to be revealed or hidden, so I'd suggest to keep the failing behavior and try to find the actual bug.

Best

 Matthias

[Lakshmi Kant]

Hi Matthias,

I have attached the terminal output created by my printf. It is not getting recognized by wireshark after I converted into .pklg with pythong script you provided. 

Can you please let me know what is wrong with this log??

Regards

Lakshmikanth. 

[Matthias Ringwald]

Hello Lakshmikanth

The log still contains newlines within individual packets. The Python converter tool cannot handle that.

Please try to change the code to not have line breaks within a single packet.

How do you get the line breaks at all? BTstack prints the whole packet at once.

Best

 Matthias

<ghd.TXT>

[Lakshmi Kant]

Hi Matthias,

I have implemented formatted printf for my BSP. It is putting unnecessary newlines. I will look into it. 

I have one more query; Have you implemented controller to host command and data flow-control into BTStack?? 

Regards

Lakshmikanth. 

[Matthias Ringwald]

Hello Lakshmikanth

Flow control from Host to Controller for commands and data is fully implemented by BTstack.

Controller to host flow control is realized implicitly via the RTS UART control as BTstack does not buffer packets on the way to the application. BTstack immediately hands the packet to the application which is free to do whatever it needs to do. I didn't see a need (or use) for Controller to Host flow control. It does not help with events btw. Do you think you need it?

Best

 Matthias

[Lakshmikanth]

Hi Matthias,

As my implementation does not have RTS/CTS, I would like to control the audio packets flow from remote using controller to host flow control. Please let me know if it is possible or not. 

I have already added init commands HCI_Set_Controller_To_Host_Flow_Control, HCI_Host_Buffer_Size (already there in btstack) and HCI_Host_Number_Of_Completed_Packets. 

I have no clue; from where to send HCI_Host_Number_Of_Completed_Packets command and how to handle it. Can you please help ?

- Lakshmikanth

--
You received this message because you are subscribed to a topic in the Google Groups "btstack-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/btstack-dev/mUfoJLUwzfk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to btstack-dev...@googlegroups.com.

[Matthias Ringwald]

Hi

I didn't read up on A2DP myself. Is there an flow control in the A2..Transport protocol that would control the speed?

I think it should be possible to add Controller to Host flow control to BTstack.

Assuming you got Controller to Host flow control properly initialized, you then have to acknowledge each ACL packet that gets handled. You could do this right from HCI for each received packet, but it would also be useless as the Controller would never stop sending. I guess you should send HCI_Host_Number_of_Complete_Packets for all L2CAP Signaling Packets and also send it from your app - as your app is the one that handles the data - when you have free buffers. 

Best

 Matthias 

[Lakshmikanth]

Hi Matthias,

Thanks for information. 

If flow control doesn't mean to control data over the Transport channel, what else could it be used?? 

Regards

Lakshmikanth

Sent from my iPhone

[Matthias Ringwald]

Hi Fazal and Lakshmikanth

Are you evaluating BTstack for a commercial project?

I'll help out on the dev list either way, although I still don't understand why you cannot manually control RTS/CTS - even if RTS is a wire that goes from the MCU/FPGA to the module through the air.

Best

 Matthias

[Lakshmikanth]

Hello Matthias,

It is too early for us to talk about commercials as it is our in-house project so far. I will get back to you on commercials later. 

I able to fix the flow control issue by using controller to host flow control.  I can only confirm once I able to play audio. Now I am able to receive media packets without missing any packets. 

I have a query about hci_stack->num_cmd_packets. 

I observed in hci_run() whenever hci_can_send_command_packet_now() routine is called, this routine returns always zero as hci_stack->num_cmd_packets > 0; is fails. Hence stack unable to respond for some commands from remote. 

example:- when I received HCI_EVENT_USER_CONFIRMATION_REQUEST, stack needs to reply with user confirmation reply, but because of num_cmd_packets = 0, it never sends and the pairing fails. 

What is the purpose of num_cmd_packets?? I did not find it in documentation. Please let me know. should i make it 1 before sending any command?? 

- Lakshmikanth

--
You received this message because you are subscribed to a topic in the Google Groups "btstack-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/btstack-dev/mUfoJLUwzfk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to btstack-dev...@googlegroups.com.

[Matthias Ringwald]

Hello Lakshmikanth

The Num_Cmd_Packets is part of the Host to Controller Flow control. Whenever a HCI Command is sent, it is reduced by one. It is increased by Command Complete or Command Status Events. So, it mainly blocks sending of a new command until the initial processing of the HCI Command is over by the Controller. (e.g. a create connection command will not stop sending commands until the connection is made, only up to the point where the connection has been initiate).

Given your RTS-free setup, the most likely cause is that the Controller sends two events and you miss the second one completely and the second one is a Command Complete or a Command Status.

I see two options here:
a) implement H5 as it does not require RTS. (Well, it's on my list rather high, but I didn't start on it yet either)
b) place a ring buffer between BTstacks H4 Transport and your module. So an IRQ/DMA driver would just put all bytes from UART in a ring buffer and the H4 Transport would take them out of the ring buffer. If this buffer is large enough, e.g. 1 kB, it should be large enough to buffer all incoming events while the Controller to Host Flow control takes care of the heavy (ACL data) stuff.

Best
Matthias

[Lakshmikanth]

Hello Matthias,

What is the criteria to get discovered by Apple and Android phones?? For Apple ios my device not hetting discovered. For android it takes multiple attempts to get discovered.  

Sent from my iPhone

On 29-Jan-2016, at 3:17 pm, Matthias Ringwald <matthias...@gmail.com> wrote:

This message is eligible for Automatic Cleanup! (matthias...@gmail.com) Add cleanup rule | More info

Hello Lakshmikanth

The Num_Cmd_Packets is part of the Host to Controller Flow control. Whenever a HCI Command is sent, it is reduced by one. It is increased by Command Complete or Command Status Events. So, it mainly blocks sending of a new command until the initial processing of the HCI Command is over by the Controller. (e.g. a create connection command will not stop sending commands until the connection is made, only up to the point where the connection has been initiate).

Given your RTS-free setup, the most likely cause is that the Controller sends two events and you miss the second one completely and the second one is a Command Complete or a Command Status.

I see two options here:
a) implement H5 as it does not require RTS. (Well, it's on my list rather high, but I didn't start on it yet either)
b) place a ring buffer between BTstacks H4 Transport and your module. So an IRQ/DMA driver would just put all bytes from UART in a ring buffer and the H4 Transport would take them out of the ring buffer. If this buffer is large enough, e.g. 1 kB, it should be large enough to buffer all incoming events while the Controller to Host Flow control takes care of the heavy (ACL data) stuff.

Best
Matthias

On 29.01.2016, at 08:06, Lakshmikanth <laxmi...@gmail.com> wrote:

[Lakshmikanth]

In addition to my previous mail, I have attached the log for pairing up with Android device. Below are my observations. 

After Android device sent the connection request for PSM 0x0001 (SDP), BTstack trying to send the connection response. But Android device always trying  to send connection requests for the same PSM number again and again. Hence after sometime connection getting rejected. below are the Android requests for connection. 

ACL <= 0x02, 0x20, 0x0C, 0x00, 0x08, 0x00, 0x01, 0x00, 0x02, 0x04, 0x04, 0x00, 0x01, 0x00, 0x42, 0x00,

ACL => 0x02, 0x00, 0x10, 0x00, 0x0C, 0x00, 0x01, 0x00, 0x03, 0x04, 0x08, 0x00, 0x41, 0x00, 0x42, 0x00, 0x00, 0x00, 0x00, 0x00,

BTstack trying to send configuration request here, Android ignores it any way and try to send connection requests continuously. 

ACL => 0x02, 0x00, 0x10, 0x00, 0x0C, 0x00, 0x01, 0x00, 0x04, 0x01, 0x08, 0x00, 0x42, 0x00, 0x00, 0x00, 0x01, 0x02, 0x30, 0x00,

ACL <= 0x02, 0x20, 0x0C, 0x00, 0x08, 0x00, 0x01, 0x00, 0x02, 0x05, 0x04, 0x00, 0x01, 0x00, 0x42, 0x00,

ACL => 0x02, 0x00, 0x10, 0x00, 0x0C, 0x00, 0x01, 0x00, 0x03, 0x05, 0x08, 0x00, 0x42, 0x00, 0x42, 0x00, 0x04, 0x00, 0x00, 0x00,

ACL <= 0x02, 0x20, 0x0C, 0x00, 0x08, 0x00, 0x01, 0x00, 0x02, 0x06, 0x04, 0x00, 0x01, 0x00, 0x43, 0x00,

ACL => 0x02, 0x00, 0x10, 0x00, 0x0C, 0x00, 0x01, 0x00, 0x03, 0x06, 0x08, 0x00, 0x43, 0x00, 0x43, 0x00, 0x04, 0x00, 0x00, 0x00,

EVT <= 0x05, 0x04, 0x00, 0x02, 0x00, 0x13,

Any clue what is going on here?? 

- Lakshmikanth

[Matthias Ringwald]

Hi

iOS filters devices a bit by Class of Device. In theory, one could wait for extended inquiry responses before "discovering" devices, but I'm not aware iOS or Android would do that.

If your devices is not seen, maybe your HF hardware is not working properly or not properly configured

Matthias

[Lakshmikanth]

It is not happening always, sometimes devices are being discovered. 

And any idea about my recent mail? Android sends back to back connection requests. 

I need your help in resolving this. Please look into it. 

- Lakshmikanth

[Matthias Ringwald]

Hi Lakshmikanth

The logs are from SDP queries and not from discovery. Did you ask about discovery (receiving an inquiry response so the device shows up on the device screen),

or from the pairing and subsequent SDP queries?

I don't see anything wrong in the packets below. The full log still has additional newlines and cannot be converted using tools/create_packet_log.py

The most obvious reason for an Android device to re-send the l2cap connection request would be if it did not received the connection request from BTstack.

Could you try to get a packet log on Android? I think there's something called BTSnoop or so. Or try on a Mac with Packet Logger. Or on Linux with hci_dump.

Maybe the log on the other side has some indication about what's going wrong.

best

matthias

<SDP_BREAKpOINT_LOG.txt>

[Lakshmikanth]

Hello Matthias,

Problem persists both the cases. After multiple attempts, device is getting discovered. Once discovered, I am seeing issues in SDP queries.

Thanks for your advice. I ll try and update.

Best

Lakshmikanth.

--

- Lakshmikanth

[Lakshmikanth]

Hello Matthias,

I have observed one thing. When remote sends ACL connection request, BTstack sends the response with same CID which remote sends. Please have a look below. 

ACL <= 0x02, 0x20, 0x0C, 0x00, 0x08, 0x00, 0x01, 0x00, 0x02, 0x0F, 0x04, 0x00, 0x19, 0x00, 0x44, 0x00, 

ACL => 0x02, 0x00, 0x10, 0x00, 0x0C, 0x00, 0x01, 0x00, 0x03, 0x0F, 0x08, 0x00, 0x44, 0x00, 0x44, 0x00, 0x00, 0x00, 0x00, 0x00, 

Is it OK to have source and Destination CID's same?? 

- Lakshmikanth

On Thu, Feb 4, 2016 at 9:06 PM, Matthias Ringwald <matthias...@gmail.com> wrote:

This message is eligible for Automatic Cleanup! (matthias...@gmail.com) Add cleanup rule | More info

Hi Lakshmikanth

The logs are from SDP queries and not from discovery. Did you ask about discovery (receiving an inquiry response so the device shows up on the device screen),

or from the pairing and subsequent SDP queries?

I don't see anything wrong in the packets below. The full log still has additional newlines and cannot be converted using tools/create_packet_log.py

The most obvious reason for an Android device to re-send the l2cap connection request would be if it did not received the connection request from BTstack.

Could you try to get a packet log on Android? I think there's something called BTSnoop or so. Or try on a Mac with Packet Logger. Or on Linux with hci_dump.

Maybe the log on the other side has some indication about what's going wrong.

best

matthias

On 04.02.2016, at 15:58, Lakshmikanth <laxmi...@gmail.com> wrote:

<SDP_BREAKpOINT_LOG.txt>

[Matthias Ringwald]

Hi Lakshmikanth

The L2CAP Channel IDs only have to be >= 0x0040 and locally unique. There's no relation between local and remote CID, so it is ok to have source and destination cid the same.

Btw, I would recommend to run BTstack with an USB Bluetooth dongle on OS X/Linux first to get everything working, and also to have a system to compare.

Best

 Matthias