CC2340R5: Implementation advice for intercepting BLE Pairing Request on TI CC2340

Hi,

Thank you for reaching out. The F3 SDK provides a few ways to handle pairing requests at the application level. You can reject all pairing vs start processing all pairing requests via the following APIs:

// To REJECT all incoming pairing requests:
uint8_t noPairing = GAPBOND_PAIRING_MODE_NO_PAIRING;  // 0x00
GAPBondMgr_SetParameter(GAPBOND_PAIRING_MODE, sizeof(uint8_t), &noPairing);

// To ACCEPT incoming pairing requests again:
uint8_t waitForReq = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;  // 0x01
GAPBondMgr_SetParameter(GAPBOND_PAIRING_MODE, sizeof(uint8_t), &waitForReq);

The BLEAPPUtil framework does handle a lot of this for you. As pairing requests ar received, you will receive specific events in which you can decide to accept or reject the pairing attempt. This can be done via the GAP_TerminateAuth() function within the BLEAPPUTIL_PAIRING_STATE_STARTED event. The BLEAPPUTIL_PAIRING_STATE_STARTED event is received when a pairing requests comes in so you can then handle each requests individually. 

I dont foresee any specific issues with this approach.

I recommend starting with basic_ble and taking a look at the app_pairing.c file. Something like the following code snippet could be a good starting point (App_isSystemReadyForPairing would be your custom function for checking state)

        case BLEAPPUTIL_PAIRING_STATE_STARTED:
        {
            // Pairing request received — evaluate system state now
            if (!App_isSystemReadyForPairing())
            {
                // Abort the pairing with a spec-compliant error code
                GAP_TerminateAuth(pData->connHandle,
                                  SMP_PAIRING_FAILED_NOT_SUPPORTED);
            }
            break;
        }

Best Regards,

Jan

Hi,

Apologies for the delay. See below for some information regarding the questions asked:

Mike Wu1 said:

The Interception Point: Within the GapBondMgr (e.g., via pairStateCB), which event allows the application to intercept the pairing request before any bonding data is generated or committed to the NV memory?

BLEAPPUTIL_PAIRING_STATE_STARTED is the correct event. It is dispatched from gapbondmgr.c before the Pairing Response is sent, which is the earliest possible interception point where nothing has been written to NV. For reference, NV is committed only when BLEAPPUTIL_PAIRING_STATE_BOND_SAVED fires, which is the last event in the pairing sequence

Mike Wu1 said:

Holding the SMP Process: What is the recommended approach to "pause" the pairing process while waiting for a physical button press? It is essential that the connection remains stable during this period (before the SMP timeout).

The correct mechanism for a wait-and-confirm flow is the passcode callback (BLEAPPUTIL_PASSCODE_TYPE handler). The stack invokes this callback during the key-exchange phase which is after Pairing Request/Response but before pairing completes and before any NV write. Critically, the stack waits indefinitely at this point until GAPBondMgr_PasscodeRsp() is called, so the connection stays up while the user interacts.

To trigger the passcode callback, configure IO capabilities to a mode that requires user interaction. For a simple button-confirm flow on the peripheral, GAPBOND_IO_CAP_DISPLAY_YES_NO negotiates Numeric Comparison with iOS (LE Secure Connections), which is the recommended approach for a medical product. GAPBOND_IO_CAP_KEYBOARD_ONLY is an alternative (Passkey Entry).

In SysCfg, make sure to set your IO capabilities to allow for inputs and display. In the passcode callback: do not call GAPBondMgr_PasscodeRsp() directly. Post an event to your application task and return. The app task then waits for the GPIO button event before calling GAPBondMgr_PasscodeRsp(). The SMP protocol has a 30-second timeout (GAP_PARAM_SM_TIMEOUT, default 30,000 ms), so the button press must occur within that window.

Mike Wu1 said:

Correct API Usage: Once the user provides manual confirmation via a button press, which API should be used to resume and either "Accept" or "Reject" the process? For the F3 Stack, is GAPBondMgr_PasscodeRsp the intended way to handle this?

Yes, GAPBondMgr_PasscodeRsp() is the intended API for this flow.

• Accept (user presses confirm): GAPBondMgr_PasscodeRsp(connHandle, SUCCESS, numComparison) — pass pData->numComparison if Numeric Comparison is active; pass 0 if Passkey Entry with a fixed code.
• Reject (user presses reject, or SMP timeout): GAPBondMgr_PasscodeRsp(connHandle, SMP_PAIRING_FAILED_PASSKEY_ENTRY_FAILED, 0

When you reject via GAPBondMgr_PasscodeRsp with a failure status, the stack sends an SMP Pairing Failed PDU to the iPhone. The iPhone should not save any bond record. This directly addresses Baboo's synchronization concern: since pairing never completes, neither side has bonding data.