• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 51 subscribers
  • Views 186 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.

LAUNCHXL-CC26X2R1: Extremely slow OAD update with newest SIMPLELINK-CC13XX-CC26XX-SDK 6.20.00.29 SDK

SPEEDBIRD
Intellectual 721 points
Part Number: LAUNCHXL-CC26X2R1
Other Parts Discussed in Thread: SIMPLELINK-CC13XX-CC26XX-SDK

Hello,

I have noticed that OAD updates from iOS apps (ti app or our own iOS app) are extremely slow with the newest  SIMPLELINK-CC13XX-CC26XX-SDK 6.20.00.29 SDK. However updates are quick when using BTOOL and a Launchpad as a distributor. This seems to be an issue caused by the SDK, because we did not experience such slow speeds on the previous SDKs.

I made the following observations:

  1. Performing an OAD update from an iOS device on a fresh simple_peripheral_oad_offchip_CC26X2R1_LAUNCHXL_tirtos7_ticlang project is extremely slow.
  2. Performing an OAD update from an iOS device on a multi_role_CC26X2R1_LAUNCHXL_tirtos7_ticlang project (added OAD by following the BLE Enhanced OAD Advanced guide) is extremely slow.
  3. Performing an OAD update from BTOOL on a fresh simple_peripheral_oad_offchip_CC26X2R1_LAUNCHXL_tirtos7_ticlang  project is fast. 


The MTU size does not seem to be the issue, because the packages have a size of about 240 bytes. But there seems to be a large delay between each package sent.

Any help is appreciated.

Thanks in advance!

  • +1
    TI__Guru* 94078 points

    Hi,

    Thank you for the well detailed question.

    Everything seems to point to a too large connection interval. Could you please verify the connection interval used when initiating the OAD process? I recommend you use the smallest connection interval supported by the phone during the OAD process. If needed, initiate a connection interval update right before and right after the OAD process (you can review this lab if needed).

    One reason that may explain the introduction of this behavior in the newest SDK is a slightly modification of the timing. The examples are configured to send a connection parameters update shortly after a connection is formed. If this connection update occur before or after the OAD, the duration will significantly be modified (side note, you could verify if disabling or modifying the connection parameters update could help your problem).

    I hope all this will help,

    Please let us know in case you need further assistance.

    Best regards,