• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 1071 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-Q1: Behavior when reaching MAX_NUM_BLE_CONNS

ROGERG
Mastermind 34870 points
Part Number: CC2640R2F-Q1

Dear Experts,

could You please let me know the behavior of the stack in the following case:

e.g.

- simplelink_cc2640r2_sdk_1_40_00_45

- peripheral role (either simple_peripheral or multi_role example)

- MAX_NUM_BLE_CONNS is set to 4

- Advertising would still be enabled after simultaneous 4th connection would be created

--> What happens now, if a 5th client would try to connect to the device, since the device is still advertising (connectable)?

I suppose a connection/link will not be able to be established, but will the client

- get any indication why? e.g. max amount of connections reached on peripheral side or not enough resource or any other kind of error message giving a hint why they connection failed?

Many thanks and best regards,

RogerG

  • 0
    TI__Mastermind 33460 points
    Hi RogerG,

    In the case you describe, the peer device would not be notified because there are not enough resources to create the connection (and thus to send a response OTA).

    In fact, if MAX_NUM_BLE_CONNS=4, and there are 4 active peers then I would not recommend sending connectable advertisements as your application knows at this point the stack doesn't have resources for another connection. You can see an example of this in the multi_role example where the linkDB is used to ensure that we don't advertise if we can't handle another connection.
  • 0 in reply to Sean2
    TI__Mastermind 34870 points
    Hi Sean,

    thank You very much for Your reply!
    In the case I described (advertising [connectable] despite reaching MAX_NUM_BLE_CONNS).
    Wouldn't the peripheral just accept the connection request from any initiator? Also I think in the normal case the peripheral would not notify the central, that it accepted the connection, it would just wait for the connection event to happen and continue from that point on ...

    Is my assumption correct, that the peripheral would decide to NOT accept the connection due to some internal checks of "MAX_NUM_BLE_CONNS" --> this is something the central would not be aware of at this point in time.
    This in turn would mean, that the central would not receive any replies from the peripheral during connection events and thus the central would run into Supervision Timeout at some point in time?

    Many thanks and best regards,
    RogerG
  • 0 in reply to ROGERG
    TI__Mastermind 33460 points

    RogerG,

    ROGERG said:
    Also I think in the normal case the peripheral would not notify the central, that it accepted the connection

    The peripheral would not notify the central, but it would know locally of the issue. There is always a callback to the application when the connection is established. See GAPROLE_CONNECTED (SDK 1.40 and earlier) and GAP_LINK_ESTABLISHED_EVENT (SDK 1.50 and later).

    The peripheral side will add connections until it runs out of heap, at which time bleNoResources will be returned. On the central side, bleNoResources will be returned immediately if you try to establish a connection > MAX_NUM_BLE_CONNS.

    ROGERG said:
    This in turn would mean, that the central would not receive any replies from the peripheral during connection events and thus the central would run into Supervision Timeout at some point in time

    This seems correct, but it depends really on when the peripheral runs out of memory. Again the recommended behavior is to NOT advertise connectable advertisements once you have reached MAX_NUM_BLE_CONNS. (most of our sample applications have guards against this, and will prevent you from doing so).