What is the difference between conidx and conhdl in SDK 6


I'm developing an app using the SDK 6 and DA14531 and I'm having trouble understanding a few things. There is an array app_env in app.c of structures of type app_env_tag, like this:

struct app_env_tag
    /// Connection handle
    uint16_t conhdl;

    /// Connection Id
    uint8_t conidx; // Should be used only with KE_BUILD_ID()

    /// Connection active flag
    bool connection_active;

    /// Last initialized profile
    //uint8_t next_prf_init;

    /// Last paired peer address type
    uint8_t peer_addr_type;

    /// Last paired peer address
    struct bd_addr peer_addr;

    /// Pairing in progress
    bool pairing_in_progress;

struct app_env_tag app_env[APP_EASY_MAX_ACTIVE_CONNECTION];


  1. What is the difference between conhdl and conidx?
  2. From looking at the SDK (like the function default_app_on_connection), I understand that the app_env is to be accessed by conidx. Is this correct?

If 2 is correct, the very same default_app_on_connection has the following code:

if (app_env[conidx].conidx != GAP_INVALID_CONIDX){...}

3. Why could the conidx stored within the app_env_tag be different from the conidx used to access them? Under what conditions can this happen? Is it normal opperation?

4. What is the point of storing conidx inside the app_env if I have to know it to get access to the app_env_tag? The only reason I can think of is passing it as a pointer to app_env_tag but I don't see the SDK doing this.

5. Is there any information resource that explains the way these should be handled and what they're? I've been reading through the documentation but it doesn't have anything useful.



  • Hi Federico,

    Thanks for your question online. The app_env defines an array of structures and its type is the app_env_tag. Each of the entries in the array holds all application information for all the supported connections, active or inactive. The array size is defined by APP_EASY_MAX_ACTIVE_CONNECTION. Default SDK configuration is single connection. The BLE stack which is in the ROM code keeps a record for the supported connection. The conidx is embedded in the message id when the message is created. For instance, KE_BUILD_ID(TASK_GAPC, conidx)). The conhdl is the corresponding handler of the connection.  It is not mandatory to keep a record for uint16_t conhdl and uint8_t conidx fields. 

    With regards to the if-statement in default_app_on_connection, it’s also not needed, as the connection index cannot be equal to GAP_INVALID_CONIDX. The conhdl and conidx can be removed from app_env_tag struct data type and I have also raised a internal ticket for that.

    The following document aims to demonstrate all the SDK architecture: http://lpccs-docs.dialog-semiconductor.com/UM-B-119_DA14585-DA14531_SW_Platform_Reference/Introduction/Introduction.html

    PS : Thanks for your feedback with regards to our SDK implementation. As mentioned, it’s already escalated internally and will try to improve it.

    Best regards,