This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF Connect Crash

Hi Nordic Team,

I saw some issue with Nrf connect on IOS.

  • First the App crash when i open it.

  • Second with IOS i can see some issue with pairing and bonding information that in Android side, i can't. For example sometimes i can see after the STATE_CONNECTED (ie: newState = 2) and right after (almost instantly), we receive a new “connection state change” event with status = 8 (I am not sure what it corresponds to, what I could read is that it can be GATT_CONN_TIMEOUT or GATT_INSUF_AUTHORIZATION) or sometimes occurs "Couldn’t pair with Nordic because of an incorrect PIN or passkey". I used a Glucose example to start with something that has a pairing and bonding information.

Can give me information about the reason of this problem? Is there a guide about the paring procedure? I use Peer_manager.

Anna

  • Hi, Could you provide the log when the issue occurred ? You say "sometimes" how often was that ? Does that mean there were also successful connection and pairing ? For glucose profile, please try to test using nRFToolbox and BGM profile inside.

  • Hi Hung Bui, This is the comment of App development for my product.

    • We experienced some issues to reconnect to the device in some cases after we closed the app, or powered OFF the device, or put the device out of range... Basically what happens is that the app successfully reconnects to the device, but right after it receives a disconnection event. Then the app automatically reconnects, and the disconnection events occurs again, and so on ... So we think this might be a connectivity issue from the device, or from the phone itself, but nothing we can handle from the app. Most of time when this happens, we have to reset the connection between the 2 devices. I would just like to precise that the issue does not only happen after we reset the bonding information on device.

    It also happens randomly, in the following cases:  after device is put out of range: then when we go back in range of phone, and try to trigger a synchronization, nothing happens on the app side.  after Bluetooth has been deactivated on phone: then when we activate Bluetooth on phone again, and try to trigger a synchronization, nothing happens on the app side.  after device has been switched OFF: then when we switch ON device again, and try to trigger a synchronization, nothing happens on the app side

    In all cases, what we could observe is that:

    •   Once the connection is lost with device for any of the reason listed above, the app repeatedly scans devices in background to try to connect to device again
      
    •   Once the device is available again (ie: device back in range, or device switched ON again, or Bluetooth on phone activated again) and advertising, the phone successfully detects the device and try to connect to it
      
    •   Each time the connection is successful: we receive a “connection state change” event with status GATT_SUCCESS (ie: status = 0), and the new connection state STATE_CONNECTED (ie: newState = 2)
      
    •   But right after (almost instantly), we receive a new “connection state change” event with status = 8 (I am not sure what it corresponds to, what I could read is that it can be GATT_CONN_TIMEOUT or GATT_INSUF_AUTHORIZATION), and the new connection state STATE_DISCONNECTED (ie: newState = 0).
      
    •   Then app repeats operations from point 1. again and again, until we reset connection on both devices.
      

    Note that this does not happen all the time. It even happens rarely, or happens more frequently on some specific devices.

    Also note that the behavior is the same when we just reset bonding information on device, but the status we receive on app is different. In case we reset bonding information, for point 4., instead of receiving status = 8, we receive status = 19 (as you were mentioning). So the case described above seems different than bonding information being reset on device.

      •     I would like to report one more issue. Sometimes after we reset the bonding information on device and unpair device from phone settings, then when we try to pair device again from app, we receive the following error message from OS: “Couldn’t pair with Nordic because of an incorrect PIN or passkey”. Sometimes the issue occurs repeatedly, but sometimes when we try to pair again, it is working fine. Do you have an idea of where the issue comes from?  
        

    My code to menage the peer, (I use a gls example) is:

    static void PR_MGR_EventHandler(pm_evt_t const * p_evt)
    {
       ret_code_t err_code;
       switch(p_evt->evt_id)
       {
          case PM_EVT_BONDED_PEER_CONNECTED:
          {
             APP_LOG("Connected to previously bonded device\r\n");                      
             err_code=TIMER_Start(TIMER_REQUEST,SECURITY_REQUEST_DELAY,NULL);
             APP_ERROR_CHECK(err_code);
             
             err_code = pm_peer_rank_highest(p_evt->peer_id);
             if (err_code != NRF_ERROR_BUSY)
             {
                     APP_ERROR_CHECK(err_code);
             }
          }
          break;//PM_EVT_BONDED_PEER_CONNECTED
    
          case PM_EVT_CONN_SEC_START:
             break;//PM_EVT_CONN_SEC_START
    
          case PM_EVT_CONN_SEC_SUCCEEDED:
             {
             pm_conn_sec_status_t conn_sec_status;
             err_code = pm_conn_sec_status_get(p_evt->conn_handle, &conn_sec_status);
             APP_ERROR_CHECK(err_code);
             err_code = pm_peer_rank_highest(p_evt->peer_id);
             APP_ERROR_CHECK(err_code);
                         
             break;//PM_EVT_CONN_SEC_SUCCEEDED
    
          case PM_EVT_CONN_SEC_FAILED:
             {
             /** In some cases, when securing fails, it can be restarted directly. Sometimes it can
              *  be restarted, but only after changing some Security Parameters. Sometimes, it cannot
              *  be restarted until the link is disconnected and reconnected. Sometimes it is
              *  impossible, to secure the link, or the peer device does not support it. How to
              *  handle this error is highly application dependent. */
              
                err_code = CNT_MGR_Disconnect();
                APP_ERROR_CHECK(err_code);
                lPeerMsg.msg = QUEUE_PEER_FAILED;
                QUEUE_Put(lPeerMsg );  
                CNT_MGR_SetConnStatus(BLE_CONN_HANDLE_INVALID);
             }
             break;//PM_EVT_CONN_SEC_FAILED
    
          case PM_EVT_CONN_SEC_CONFIG_REQ:
             {
             // Allow pairing request from an already bonded peer.
                pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true};
                pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
             }
             break;//PM_EVT_CONN_SEC_CONFIG_REQ
    
             case PM_EVT_STORAGE_FULL:
             {
             // Run garbage collection on the flash.
             err_code = fds_gc();
             if (err_code == FDS_ERR_BUSY || err_code == FDS_ERR_NO_SPACE_IN_QUEUES)
             {
                 // Retry.
             }
             else
             {
                 APP_ERROR_CHECK(err_code);
             }
             }
             break;//PM_EVT_STORAGE_FULL
    
          case PM_EVT_ERROR_UNEXPECTED:
             // Assert.
             APP_ERROR_CHECK(p_evt->params.error_unexpected.error);
             break;//PM_EVT_ERROR_UNEXPECTED
    
    
          case PM_EVT_PEER_DATA_UPDATE_FAILED:
             // Assert.
             APP_ERROR_CHECK_BOOL(false);
             break;//PM_EVT_PEER_DATA_UPDATE_FAILED
    
    
          case PM_EVT_PEER_DELETE_FAILED:
             // Assert.
             APP_ERROR_CHECK(p_evt->params.peer_delete_failed.error);
             break;//PM_EVT_PEER_DELETE_FAILED
    
    
          case PM_EVT_PEERS_DELETE_FAILED:
             // Assert.
             APP_ERROR_CHECK(p_evt->params.peers_delete_failed_evt.error);
             break;//PM_EVT_PEERS_DELETE_FAILED
    
    
          case PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED:
             // The local database has likely changed, send service changed indications.
             pm_local_database_has_changed();
             break;//PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED
    
          default:
             // No implementation needed.
             break;
       }
    }
    
  • Hi Annapalu,

    Thanks for detailed description.

    The NRFConnect just received an update today with version 1.7.5 .

    Please try to test with this version and let me know if the issue persists.

    Also please try to test using nRFToolbox for comparison. You can try to test with 3rd party app such as LightBlue. We need to find out if the issues are from the app itself or from the OS.

    Please test with unmodified GLS example as well.

  • Hi Hung Bui,

    thank you for the answer. I'll check with the new version of NrfConnect. Note that the problem that i have written above, is using the APP developments from our supplier.

  • @annapalu: Please also include the result of the test with NRFToolbox compare to your app.

Related