• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 685 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2541: CC2541 Pairing Error

Garret Holt
Intellectual 1050 points

Part Number: CC2541
Other Parts Discussed in Thread: BLE-STACK

Hi Team,

We are using the Laird TiWi-UB1 module, which is based on the CC2541 TI chip. It is configured to support both Central and Peripheral roles.

The pairing process uses a PIN that each side must enter. Each side uses the IO capability of GAPBOND_IO_CAP_KEYBOARD_ONLY, so that authenticated pairing can be performed (with both sides entering in their key). I believe this results in Security Mode 1, Level 3 (authenticated and encrypted).

When a connection occurs, both sides try to start the pairing process. The peripheral will send the SlaveSecurityRequest, and the central will try to start pairing (each side sends their respective message on their own timing, which doesn’t seem to be a problem since the central will ignore the SlaveSecurityRequest if it’s already starting the pairing process).

 Then, normally, pairing is initiated, and they send their PINs, exchange keys and link is secured and they continue on in the application (we receive the GAPBOND_PAIRING_STATE_STARTED and GAPBOND_PAIRING_STATE_COMPLETE event).

 We did implement 2 timeouts during the connection. One 30-second timer is started upon connection, and is stopped when pairing is started. The 2nd 30-second timer is started when pairing starts (GAPBOND_PAIRING_STATE_STARTED event). If either of these time outs expire, then the firmware will disconnect.

 In the error cases we’ve seen, the pairing process doesn’t seem to complete. I’ve used a TI dongle (with BTool) to simulate a central device. I’ve connected to the end device and I don’t see the expected SlaveSecurityRequest come from the end device. When I try to initiate pairing with GAP_Authenticate, it seems to be successfully sent but after 30 seconds I receive GAP_AuthenticationComplete with bleTimeout status (and a disconnect, which is likely from the end device timing out and disconnecting). I did sniff the BLE traffic of these devices and do see the Pairing Request packet is sent over the air but no other packets are sent (other than the EMPTY ones which probably for keeping the connection up).

 I did notice that even in the error cases, that the end device seems to be getting the GAPBOND_PAIRING_STATE_STARTED event, because after a connection with BTool, if I wait 20 seconds, then initiate pairing with GAP_Authenticate, the link doesn’t go down until an additional 30 seconds elapses. That indicates that the 2nd 30-second time was started after the GAPBOND_PAIRING_STATE_STARTED was received. But the pairing process doesn’t seem to continue after that.

 One last troubleshooting item I did was just record the status results of the API functions GAP_SendSlaveSecurityRequest

And GAP_Authenticate. The unknown error status we were seeing was from the GAP_SendSlaveSecurityRequest function, where it was returning 0x04. This doesn’t seem to be one of the documented return statuses:

 

   * @return      SUCCESS, <BR>

   *              bleIncorrectMode: Not correct profile role,<BR>

   *              INVALIDPARAMETER, <BR>

   *              bleNotConnected,<BR>

   *              FAILURE: not workable.<BR>

 

I was wondering if it was MSG_BUFFER_NOT_AVAIL, but wasn’t sure. Is that a possible return value from this command? If this is a valid return value, does that mean that there’s a memory issue?

Just FYI, the snippet of code for this is just:

 

  bStatus_t stat = GAP_SendSlaveSecurityRequest( connHandle, authReq );

  LOG_WRN(16, "SlaveSecurityReq stat %d", stat); //this command also saves the status to NV memory so that we can check it later.

 

The GAP_Authenticate did not seem to return any failures though, the return values were always 0x00.

Regards,

Garret

  • 0
    TI__Guru* 83011 points

    Hi Garret,

    What version of the BLE-Stack and BTool are you using?

    Is MITM set for any of the device?

    What is the status of the GAPBOND_PAIRING_STATE_COMPLETE event?

    Can you post the sniffer log?

    Did you try using the GAPBondMgr command to initiate pairing from BTool?

    I think you're correct that 0x04 is MSG_BUFFER_NOT_AVAIL (defined in comdef.h). Could you try increasing the number of packets in your Rx/Tx buffer?

  • 0
    TI__Guru 56590 points

    0) please answer the questions from Marie.

    1)

    - MSG_BUFFER_NOT_AVAIL (0x04): No HCI buffer is available (Retry later.)

    In the context of GAP_SendSlaveSecurityRequest this seems to be relate to exhausted LL_MAX_NUM_DATA_BUFFERS. You can retry the call to see if that works.

    2)

    What are the connection parameters?

    3)

    Is the device effectively operating in peripheral mode only when this occurs? What else could fill up the TX buffers at the same time?

    Can you try enable overlapped processing to be able to send more than 4 packets per connection event;

    // Enable Overlap Processing
HCI_EXT_OverlappedProcessingCmd(HCI_EXT_ENABLE_OVERLAPPED_PROCESSING);
HCI_EXT_HaltDuringRfCmd(HCI_EXT_HALT_DURING_RF_DISABLE);

    4)

    Where did you get the combined role code (central+peripheral)?

  • 0 in reply to Eirik V
    TI__Intellectual 1050 points

    What version of the BLE-Stack and BTool are you using?

    BLE-stack 1.4.2.2

    On the PC side, I actually don’t use BTool, but created a PC application that was based off of BTool (an older version, not sure which one). There’s some necessary communication that the PC application needs to send to keep the connection up so we needed a custom tool.

    Is MITM set for any of the device?

    Yes, MITM is set for both devices. Bonding is set to false.

    What is the status of the GAPBOND_PAIRING_STATE_COMPLETE event?

    The application does not seem to be receiving this event. The GAPBOND_PAIRING_STATE_COMPLETE handler would stop a pairing time out timer that we implemented, but we are seeing this timer expire and cause a disconnect.

    Can you share the sniffer log?

    We used a Frontline Sodera BLE sniffer to capture the OTA packets. I’ve attached the log. I believe the software for viewing it is free, but I’m not 100% sure. If needed, you can download the software at http://www.fte.com/support/WPS-download.aspx?demo=Sodera&iid=CS

    Did you try using the GAPBondMgr command to initiate pairing from BTool?

    Yes, we sent the GAP_Authenticate command from our PC app (i.e. BTool based application) and our sniffer saw it over the air, but did not capture any responses to it. The link was still up for 30 more seconds until getting disconnected due to the pairing time out timer in the firmware.

    I think you're correct that 0x04 is MSG_BUFFER_NOT_AVAIL (defined in comdef.h). Could you try increasing the number of packets in your Rx/Tx buffer?

    I’m not quite sure which Rx/Tx buffer is being referred to? I didn’t’ think we had explicit control on the buffers used by the BLE stack. In terms of the heap, the INT_HEAP_LEN is set to 1960 and I don’t’ think we can increase that any more.

     

    1)- MSG_BUFFER_NOT_AVAIL (0x04): No HCI buffer is available (Retry later.)

     

    In the context of GAP_SendSlaveSecurityRequest this seems to be relate to exhausted LL_MAX_NUM_DATA_BUFFERS. You can retry the call to see if that works.

     

    On subsequent connections, this same command is sent and fails with the same error, so it doesn’t seem like the buffers are getting freed up. Do you know why that would happen? Are these buffers affected at all by application memory usage?

     

    2) What are the connection parameters?

    Min connection interval = 28 (35ms)

    Max connection interval = 28 (35ms)

    Slave latency = 0

    Supervision timeout = 56 (560ms)

     

    3) Is the device effectively operating in peripheral mode only when this occurs? What else could fill up the TX buffers at the same time?

     

    Yes, it should only be in peripheral mode at this point. I’m not sure what else would fill up the TX buffers. It would have been advertising only, and then gets connected to by the Central and they start the pairing process as the first action on startup.

     

    Can you try enable overlapped processing to be able to send more than 4 packets per connection event;

     

    We can see if this is possible. I believe we tried using this feature previously and had to take it out. I don’t recall why, but there may have been some problem with enabling it.

     

    4) Where did you get the combined role code (central+peripheral)?

    I don’t’ recall exactly. I’m not sure if there was an example from TI that we referenced, or if we just pulled in the files from a central example and a peripheral example. In terms of how our application runs, we generally stay in the peripheral mode, just advertising so that other devices can connect to us. At specific timings, we will switch to central mode by calling “GAPCentralRole_StartDevice” (which calls GAP_DeviceInit with flags GAP_PROFILE_CENTRAL | GAP_PROFILE_BROADCASTER) so that we can perform scanning. Once that is complete, we switch back to peripheral mode by call “GAPRole_StartDevice” (which calls GAP_DeviceInit with flags GAP_PROFILE_PERIPHERAL).

  • 0 in reply to Garret Holt
    TI__Guru 56590 points

    Hello Garret,

    You stated that both sides must use GAPBOND_IO_CAP_KEYBOARD_ONLY, but in the sniffer log the initiator use IO Capabilities: KeyboardDisplay. In that case another version of Passkey Entry is used: initiator displays, responder inputs Authenti-cated.