Change Bluetooth HCI commands/Sequence according to firmware requirements RRS feed

  • Question

  • Hello all,

    We have developed HCI transport driver for a module.

    But we are facing an issue, that sometimes pairing is not happening, as stack is sending

        a. 0x0C1A - Write Scan Command
        b. 0x0401 - Inquiry Command

    commands even after the connection (0x0405) is initiated. This is not accepted by firmware and goes to deadlock, resulting in pairing fail.

    Is it possible to do something in HCI transport driver, so that the stack should not send these commands once the connection is initiated?



    • Edited by Keshava GN Friday, May 22, 2015 9:57 AM
    Friday, May 22, 2015 8:06 AM

All replies

  • I got the following input from firmware team:

    During Failure case, while the BT Module is trying to pair (0x0405) with Mobile, Below  commands are being sent from Bluetooth stack to BT Module Firmware before BT Stack receives connection completion event.

        a. 0x0C1A - Write Scan Command     b. 0x0401 - Inquiry Command.

    Firmware Cannot handle the above commands while the it is in Connecting phase and hence its in deadlock, doesn’t respond with connection complete event.

    So, In order to solve the above issue, I need to change the WEC driver (preferably in USB/SDIO HCI transport driver) such that, while the firmware is in connecting phase, driver should not send any commands to the firmware unless Connection complete event is received from the firmware.

    Is there any way to indicate to the stack, that BT firmware is busy or wait for Connection completion event and then proceed sending other commands?

    Request you to help us to resolving the above issue.

    Tuesday, May 26, 2015 11:36 AM
  • No, the solution is always to modify your driver, not the system drivers. Your transport driver should detect the potential problem and do the right thing (probably report OK for write scan and inquiry but not do anything with them until Connect is complete). It's also quite possible that something you are doing in your driver is triggering the unexpected Bluetooth stack behavior. I'm not an expert in Bluetooth but can almost guarantee that trying to modify the Windows CE code will result in significant issues.

    Paul T.

    Wednesday, May 27, 2015 7:01 PM
  • Hey Paul,

    Thanks for the reply.

    I know that I should handle this in my HCI transport driver.

    But the problem is, in this case, I can't just return TRUE (write success) to stack in HCI_WritePacket function, because, that indicates the stack that the command is written to the chip (firmware) and hence, the stack expects a valid event read for that command. (But we can not write these commands actually, as this will run into deadlock. So there will not be events read)

    So, my doubt is:

    Is there any way to indicate to the stack, that BT module (firmware) is busy or wait for Connection completion event (or, wait for some time) and then proceed sending other commands?  (In HCI_WritePacket (or in any other) function of my HCI transport driver).

    • Edited by Keshava GN Friday, May 29, 2015 6:46 AM
    Friday, May 29, 2015 6:45 AM
  • Just to be sure I understand: you ARE blocking in HCI_OpenConnection, right? You're saying that during that blocked call you are getting writes? My first thought is "you're returning from HCI_OpenConnection before the connection is complete so all bets are off".

    Paul T.

    Friday, May 29, 2015 7:48 PM
  • According to the Compact 2013 docs, HCI_OpenConnection():

    This function is used to set up, initialize, and establish a connection to the hardware. This is a blocking function that does not return until the transport is active or the attempt to open the connection has failed.

    My question comes from whether your code is returning prematurely, before either a) the transport is active, or b) the connection has failed. That is, I'm wondering if you are causing HCI_OpenConnection() to do the wrong thing.

    Have you captured the sequence of calls your transport driver receives from the stack during this process (and your returns)? Maybe someone can identify a sequence issue that will point to the problem.

    Paul T.

    Monday, June 1, 2015 11:35 PM
  • Hi,

    HCI_ReadPacket and HCI_WritePacket are blocking calls. Why not wait for connection completion or other event(s) in either of these functions?.

    HCI commands and events can be decoded from within the driver to wait for specific sequences to get over.



    • Edited by balajitrv1 Tuesday, June 2, 2015 5:22 AM
    Tuesday, June 2, 2015 5:21 AM