• State Resolved
  • Replies 8 replies
  • Subscribers 51 subscribers
  • Views 125 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

Original question:

CC2340R2: Application Sending Response vs BLE Stack

CC2340R2: No Response from Stack

Luke
Intellectual 2950 points
Part Number: CC2340R2
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi team,

Following up on the related thread, we are trying to get the gap bond manager to respond as expected via BTool. Currently, they are getting no response from the stack. There doesn't seem to be anything set incorrectly in the pairing request but there must be something wrong... we tried sending the pairing request using 'Pair Bonding' and 'Advanced Commands -> GAP_Authenticate' (as below). The pairing request was sent but there was no response. 

Thanks,

Luke

  • 0
    TI__Genius 12815 points

    Hello Luke,

    Hope you are doing well.

    May I ask you to share more info of your current setup? Which device is the central and which the peripheral? Are both running BTool or is one executing basic_ble for instance?

    BR,


    David

  • 0 in reply to David
    TI__Intellectual 2950 points

    Hi David,

    They have the CC2340 flashed with their custom code as a peripheral. The sysconfig for the code is setup so that the stack (i.e., the gap bond manager) responds to all pairing requests. We have a TI USB dongle flashed with the ‘host_test_app.hex’. We are using Btool to send the pairing request via the USB dongle to our custom CC2340 hardware.

    Best,

    Luke

  • 0 in reply to Luke
    TI__Genius 12815 points

    Hello Luke,

    Could you also share the SysConfig GapBond manager configuration? Do you also have MITM enabled? In addition, any chance we can have a ble sniffer log?

    BR,

    David.

  • 0 in reply to David
    TI__Intellectual 2950 points

    Hi David,

    Here is the GapBond manager config (MITM is enabled):

    Here is a screenshot of the sniffer log I have:

    I am still waiting on the whole capture file.

    Best,

    Luke

  • 0 in reply to Luke
    TI__Intellectual 2950 points

    David,

    Capture file added:

    BTool pairing request.zip

    Best,

    Luke

  • 0 in reply to Luke
    TI__Genius 12815 points

    Hello Luke,

    Thanks. From the screenshot I don't see anything unusual, and I cannot seem to open the .cfa file (not sure what sw it requires). From the peripheral side, is it possible to debug it? Is it build on top of some of our examples, such as basic_ble? I think the next step is to see if the paring request is received and processed correctly.

    BR,

    David.

  • 0 in reply to David
    TI__Intellectual 2950 points

    David,

    Apologies in the delay getting back to you.

    David said:
    Is it build on top of some of our examples, such as basic_ble?

    They built their custom code on top of the basic_ble example project.

    David said:
    From the peripheral side, is it possible to debug it?

    They have debugged from the peripheral side. The pair state callback handler (in app_pairing.c) gets called when the pairing request is received from the USB dongle controlled by BTool. But there is no response sent by the BLE stack/gap bond manager. The event when the request is received is BLEAPPUTIL_PAIRING_STATE_STARTED. This is the same event that is received when we pair with a phone (and the pairing response is sent). So the pairing request is being received.

    They have been looking at the pairing requests sent by BTool and the phone and one thing I noticed was that BTool does not include the link key in its key distribution list while the phone does include it.

    Pairing request sent by BTool:

    Pairing request sent by the phone:

    Gap bond manager configuration:

    I couldn't figure out how to include the link key in BTool's key distribution list. Do you know how to do this?

    The other difference I noticed was that their USB dongle has a public Bluetooth address, while the phone has a random address. 

    So those are the 2 paths - key distribution list and address - we are investigating now. Let me know if you come across anything or have any other thoughts.

    Thanks,

    Luke

  • +1 in reply to Luke
    TI__Genius 12815 points

    Hello Luke,

    Apologies for the delay, do you mean the Long Term Key (LTK) - used for encrypting the connection between the devices? That one can be set through the Paring Bonding window. What I would suggest now is to get a better idea of where in the code the device is deciding not to answer the paring/bonding request. Could you please add the gapbondmgr.c file (found inside \source\ti\ble5stack_flash\host) inside the project, and set a break-point inside GAPBondMgr_Pair(), then execute in debug mode step by step to see where the decision is made. The device is not crashing correct? For reference I would use a basic_ble example you know works for paring purposes and follow the same process so you understand what is expected while doing a successful pairing.

    BR,

    David.