default_app_on_connection() question

I'm using SDK 6.0.18.1182.1. The start of default_app_on_connection() looks like this

void default_app_on_connection(uint8_t conidx, struct gapc_connection_req_ind const *param)
{
    if (app_env[conidx].conidx != GAP_INVALID_CONIDX)
    {
        ...

GAP_INVALID_CONIDX is defined as 0xFF in gap.h

So if default_app_on_connection is called with conidx == GAP_INVALID_CONIDX then this would read app_env[0xff] right? Or am I misunderstanding?

Should it say if(conidx != GAP_INVALID_CONIDX) instead? Or should we do our own checking before calling default_app_on_connection()?

Parents
  • Hi There,

    Thank you for posting your question online.
    Have you encounter any errors regarding the connection index?
    The conidx is the connection index. One task instance is created for each established link. Each instance of the task is related to a connection index with a valid value range: [0...BLE_CONNECTION_MAX].
    When you try to connect from a central first the gapc_connection_req_ind_handler will be invoked. We get the conidx value from the src_id and then we have an ASSERT_WARNING if the conidx value is not under the APP_EASY_MAX_ACTIVE_CONNECTION macro. So we would know if the conidx was equal to GAP_INVALID_CONIDX.
    At the end of the gapc_connection_req_ind_handler we call the on-connection callback function, which will end up calling the default_app_on_connection, there we check again the value of the conidx but we already know that it is not equal to GAP_INVALID_CONIDX.
    We just make sure that the value had not changed, and we can handle different connections if we are working with multi-threading or as a central device.

    Kind Regards,
    OV_Renesas

Reply
  • Hi There,

    Thank you for posting your question online.
    Have you encounter any errors regarding the connection index?
    The conidx is the connection index. One task instance is created for each established link. Each instance of the task is related to a connection index with a valid value range: [0...BLE_CONNECTION_MAX].
    When you try to connect from a central first the gapc_connection_req_ind_handler will be invoked. We get the conidx value from the src_id and then we have an ASSERT_WARNING if the conidx value is not under the APP_EASY_MAX_ACTIVE_CONNECTION macro. So we would know if the conidx was equal to GAP_INVALID_CONIDX.
    At the end of the gapc_connection_req_ind_handler we call the on-connection callback function, which will end up calling the default_app_on_connection, there we check again the value of the conidx but we already know that it is not equal to GAP_INVALID_CONIDX.
    We just make sure that the value had not changed, and we can handle different connections if we are working with multi-threading or as a central device.

    Kind Regards,
    OV_Renesas

Children
  • No, I haven't had any errors, I just came across this when I was debugging.

    ASSERT_WARNING does nothing if DEVELOPMENT_DEBUG is FALSE so the potential for a problem is still there but if you're confident that the check is redundant then... ok I guess.

  • Hi There,

    If you feel that there is this possibility of error you could modify the gapc_connection_req_ind_handler:

    static int gapc_connection_req_ind_handler(ke_msg_id_t const msgid,
                                               struct gapc_connection_req_ind const *param,
                                               ke_task_id_t const dest_id,
                                               ke_task_id_t const src_id)
    {
        // Connection Index
        if (ke_state_get(dest_id) == APP_CONNECTABLE)
        {
            uint8_t conidx = KE_IDX_GET(src_id);
            ASSERT_WARNING(conidx < APP_EASY_MAX_ACTIVE_CONNECTION);
    
            if (conidx != GAP_INVALID_CONIDX)
            {
                app_env[conidx].conidx = conidx;
                app_env[conidx].connection_active = true;
                ke_state_set(TASK_APP, APP_CONNECTED);
                // Retrieve the connection info from the parameters
                app_env[conidx].conhdl = param->conhdl;
                app_env[conidx].peer_addr_type = param->peer_addr_type;
                memcpy(app_env[conidx].peer_addr.addr, param->peer_addr.addr, BD_ADDR_LEN);
                #if (BLE_APP_SEC)
                    // send connection confirmation
                    app_easy_gap_confirm(conidx, (enum gap_auth) app_sec_env[conidx].auth, 1);
                #else
                    app_easy_gap_confirm(conidx, GAP_AUTH_REQ_NO_MITM_NO_BOND, 1);
                #endif
            }
            CALLBACK_ARGS_2(user_app_callbacks.app_on_connection, conidx, param)
        }
        else
        {
            // APP_CONNECTABLE state is used to wait the GAP_LE_CREATE_CONN_REQ_CMP_EVT message
            ASSERT_ERROR(0);
        }
    
        return (KE_MSG_CONSUMED);
    }
    


    But personally, I have not faced any issue with conidx in any project so far.

    Kind Regards,
    OV_Renesas