2 Replies Latest reply on Jan 31, 2017 8:22 AM by axel.lin_1746341

    WICED 3.7.0 - Bug in wiced_bt_smartbridge_deinit ?

    romain

      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