• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 435 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2640R2F: Pairing iPhone8 (iOS13.6) with multi role fails

Niranjan Hegde
Intellectual 650 points
Part Number: CC2640R2F

Hello Team,

Our project has the following properties

SDK

simplelink_cc2640r2_sdk_5_30_00_03

IDE

IAR8.32.2

Reference Project

MultiRole

1. We are using bonding with just works pairing mode, 1 SNV page used.
    pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;
    mitm = FALSE;
    ioCap = GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT;
    bonding = TRUE;
    replaceBonds = TRUE;

2. We have encrypted the write property to simpleProfilechar3UUID as GATT_PERMIT_ENCRYPT_WRITE

After starting up the multi role(Peripheral) and connecting it to the iPhone nrf/LightBlue App(Client), on writing to the characteristic 3 we get the pairing request pop up on the iPhone.
On selecting 'pair', we observed that the pairing has failed.

I have attached the captured pairing request and response as well.


Could you guide us as to what could be the cause for this?

Regards,
Niranjan

  • 0
    TI__Mastermind 39470 points

    Hi Niranjan,

    I have assigned an expert to help with your query. In the meantime, could you provide some additional information. Are there any additional modifications present in the multi_role example? Is this behavior only seen on that specific device with that specific os version? Is the issue reproduceable with a newer device or a newer os version?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Intellectual 650 points

    Hello Jan,

    I did run a few more tests:
    1. I tested the above multi role software with the new iOS v16 and saw the same behavior.
       a. Here the only changes are the ones mentioned above, i.e, the gapbond manager init setup and the encrypted characteristic 3,
    2. I flashed my device with the original simple peripheral example project(without any modifications) and did not see the pairing failure for iOS 13.6 or 16.
    3. I took the original example multi_role.c into my project and flashed the hex into my device - The pairing failure was observed again on the iOS devices

    I hope these observations help. Please let me know if there's anything else I'll need to check.

    Regards,
    Niranjan

  • 0 in reply to Niranjan Hegde
    TI__Mastermind 25810 points

    Hey Niranjan,

    Thanks for the information, allow me some time to reproduce this issue.

    To be clear, is the expected behavior that the device is able to successfully pair and read the encrypted characteristic? It looks like you've configured the device in a Just Works configuration, which is unauthenticated. Have you configured Secure Connections? If you have not, I believe that the default is set to GAPBOND_SECURE_CONNECTION_ALLOW. Perhaps these are connected to the behavior we are seeing. I recall running into something similar in the past, but let me double check that this is the same scenario by reproducing the issue first.

  • 0 in reply to Ammar N
    Intellectual 650 points

    Hello Ammar,

    I would have expected a successful pair with the iOS devices.
    In the same scenario I do not see any issues with the Android devices, I'm able to successfully pair/bond with the android devices.

    I have not configured anything for the Secure Connections.

    Since this is critical for our product release, I hope we can find the cause for this behavior as early as possible. Thanks.

    Regards,
    Niranjan

  • 0 in reply to Niranjan Hegde
    TI__Mastermind 25810 points

    Hey Niranjan,

    Thanks for clarifying, I will update this thread by latest tomorrow afternoon. I apologize for the delay, I have not been in the office to test this.

  • 0 in reply to Ammar N
    Intellectual 650 points

    Hey Ammar,

    Alright, no worries! Hope to hear from you on this, soon Slight smile

  • 0 in reply to Niranjan Hegde
    TI__Mastermind 25810 points

    Hey Niranjan,

    I'm still working on this. I've been able to reproduce the issue using multi_role. It seems the pairing fails for an Unspecified Reason. Shockingly, this issue is not reproducible using simple_peripheral. As a second data point, are you able to verify if this issue occurs on simple_peripheral?

    I will continue to look into this and let you know when I have more information.

  • 0 in reply to Ammar N
    Intellectual 650 points

    Hello Ammar,

    As mentioned earlier, I did not see the pairing issue with the simple peripheral.

    Regards,
    Niranjan

  • 0 in reply to Niranjan Hegde
    TI__Mastermind 25810 points

    Hey Niranjan,

    I appreciate your patience. I've root caused the behavior described. The device is running out of usable heap. When the issue is seen, a memory allocation failure occurs causing the device to throw the pairing failure Unspecified Reason code. As iOS usually defaults to a higher PDU size, this issue was not seen on my Android device.

    To work around this issue, I recommend optimizing the memory consumption of the stack/application to allow enough heap to avoid a mem allocation failure. There are some tips in our User's Guide here. By optimizing the stack configuration, I was able to pair while encrypting Char3. I was able to do this by lowering the MAX_PDU_SIZE.

    Hope this helps.

  • 0 in reply to Ammar N
    Intellectual 650 points

    Hello Ammar,

    Thank you for  the analysis Slight smile

    I have some more questions:
    1. Since the iOS negotiates for a higher PDU, how would this impact the heap? In the regular communication(without pairing), there's no issue with the higher PDU payload. Is it the additional encryption in that case?
    2. What is the PDU size that worked for you?

    Regards,
    Niranjan

  • 0 in reply to Niranjan Hegde
    TI__Mastermind 25810 points

    Hey Niranjan,

    Niranjan Hegde said:
    Is it the additional encryption in that case?

    Correct. Since the higher PDU size uses more heap, the encryption is unable to complete successfully. I would not expect this to be seen if the devices don't pair.

    Niranjan Hegde said:
    2. What is the PDU size that worked for you?

    I tested by lowering the PDU size to the minimum size of 27 bytes. You may be able to go higher, depending on the application.

  • 0 in reply to Ammar N
    Intellectual 650 points

    Hello Ammar,

    Unfortunately, keeping a low PDU size will not fit our application requirements. Especially when we are doing FOTA transfers using the mobile. A solution conflicting this would not suffice.

    We are optimizing our flash usage, but even in the best case scenario we might run into the same issue again with the iOS if heap is the issue.
    Could you suggest any other way we could resolve this?

    And since it is a critical topic for our product release, I would appreciate it if this is looked into as soon as possible.

    Regards,
    Niranjan

  • 0 in reply to Niranjan Hegde
    TI__Mastermind 25810 points

    Hey Niranjan,

    Niranjan Hegde said:
    We are optimizing our flash usage, but even in the best case scenario we might run into the same issue again with the iOS if heap is the issue.
    Could you suggest any other way we could resolve this?

    This is true. Unfortunately, the best path forward here is to free enough heap to avoid the memory failure. You can try to enable cache as RAM and also Aux as RAM to free up more memory.