WICED 3.7.0 - Bug in wiced_bt_smartbridge_deinit ?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

As I am working with Smartbridge, I noticed that a call to wiced_bt_smartbridge_deinit() function makes my program crash. After few investigations, I have pointed out a bug in the sub-layers of this function.

Just to remind, here is the content of the function itself :

wiced_result_t wiced_bt_smartbridge_deinit( void )

{

    if ( initialised == WICED_FALSE )

    {

        return WICED_BT_SUCCESS;

    }

    /* Disable Attribute Cache (The function checks if it's enabled) */

    bt_smartbridge_att_cache_disable();

    /* Deinitialise socket manager */

    bt_smartbridge_socket_manager_deinit();

    /* Deinitialise GATT */

    smartbridge_bt_interface_deinitialize();

    initialised = WICED_FALSE;

    return WICED_BT_SUCCESS;

}

Then, in the call to smartbridge_bt_interface_deinitialize() :

wiced_result_t smartbridge_bt_interface_deinitialize( void )

{

    WPRINT_LIB_INFO( ( "[SmartBridge] Deinitializing Bluetooth Interface...\n" ) );

    wiced_rtos_deinit_mutex( &subprocedure.mutex );

    wiced_rtos_deinit_semaphore( &subprocedure.done_semaphore );

    subprocedure_reset();

    return WICED_BT_SUCCESS;

}

We continue in subprocedure_reset() :

wiced_result_t subprocedure_reset( void )

{

    subprocedure.subprocedure      = GATT_SUBPROCEDURE_NONE;

    subprocedure.attr_head         = NULL;

    subprocedure.attr_tail         = NULL;

    subprocedure.attr_count        = 0;

    subprocedure.result            = WICED_BT_SUCCESS;

    subprocedure.start_handle      = 0;

    subprocedure.end_handle        = 0;

    //subprocedure.pdu               = 0;

    subprocedure.length            = 0;

    subprocedure.offset            = 0;

    subprocedure.connection_handle = 0;

    memset( &subprocedure.uuid, 0, sizeof( subprocedure.uuid ) );

    subprocedure_wait_clear_semaphore();

    return WICED_BT_SUCCESS;

}

And finally in subprocedure_wait_for_completion() :

wiced_result_t subprocedure_wait_clear_semaphore( void )

{

    while ( wiced_rtos_get_semaphore( &subprocedure.done_semaphore, WICED_NO_WAIT ) == WICED_BT_SUCCESS )

    {

    }

    return WICED_BT_SUCCESS;

}

So, the problem is in smartbridge_bt_interface_deinitialize() function, in which there is a call to subprocedure_reset() which manipulates the semaphore after a call to  wiced_rtos_deinit_semaphore( &subprocedure.done_semaphore ) which removes the semaphore itself.

So the solution I found simply consists in switching those two calls :

wiced_result_t smartbridge_bt_interface_deinitialize( void )

{

    WPRINT_LIB_INFO( ( "[SmartBridge] Deinitializing Bluetooth Interface...\n" ) );

    wiced_rtos_deinit_mutex( &subprocedure.mutex );

    subprocedure_reset();

    wiced_rtos_deinit_semaphore( &subprocedure.done_semaphore );

    return WICED_BT_SUCCESS;

}

I just wanted to expose this so you can take it into consideration for next releases.

Regards

2 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Thanks for the feedback romain

I went ahead a created a bug tracking request internally so that the SW team could review and consider this fix for the next release of the SDK.

0 Likes

mifo wrote:

Thanks for the feedback romain

I went ahead a created a bug tracking request internally so that the SW team could review and consider this fix for the next release of the SDK.

No, the latest sdk does not fix this.

0 Likes