RE: NRF Connect Crash

Hung Bui — Mon, 08 May 2017 13:32:21 GMT

Please test again with GLS example in the SD and check if the same behaviour can be seen. This is to check if your firmware causes the issue.

RE: NRF Connect Crash

annapalu — Mon, 08 May 2017 09:35:58 GMT

I can'y use a NRFToolbox, beacuse i remove the UUID of gls and i'm using of custom UUID. From gls i use only the menage of peer

RE: NRF Connect Crash

Hung Bui — Fri, 05 May 2017 08:57:11 GMT

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

RE: NRF Connect Crash

annapalu — Thu, 04 May 2017 11:57:34 GMT

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.

RE: NRF Connect Crash

Hung Bui — Thu, 04 May 2017 11:39:48 GMT

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.

RE: NRF Connect Crash

annapalu — Thu, 04 May 2017 07:32:18 GMT

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;
   }
}

RE: NRF Connect Crash

Hung Bui — Wed, 03 May 2017 14:32:09 GMT

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.