Bonding information issue when only one side the bonding is delete

RE: Bonding information issue when only one side the bonding is delete

annapalu — Wed, 12 Jul 2017 07:59:02 GMT

Hi Petter, i can share in private. I update the question. Thank you, Anna

RE: Bonding information issue when only one side the bonding is delete

Petter Myhre — Wed, 12 Jul 2017 07:21:33 GMT

Can you please edit your question and upload your complete project so I can test it here?

RE: Bonding information issue when only one side the bonding is delete

annapalu — Tue, 11 Jul 2017 15:55:34 GMT

Hi Petter,

now i can reproduce the assert sistematically. I try to explain the flow:

I need to have a bonding one to one (every device can bonding with one phone) so i have added a whitelist. After i have needed to delete the bonding information if the user lose your phone for example and need to bonding with an other phone

I have three scenario now, that i need to consider:

User delete bonding information on both side ( APP and phone) ALL WORKS OK
User delete bonding on device side and forgot to delete on phone side, the device disconnect as long as the user don't delete the bonding information, also on phone side. ALL WORKS OK
User delete bonding information on phone side and forgot on device side. In this case i have need to change in the peer menager the case:

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_t conn_sec_config = {.allow_repairing = false}; pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config); } break;//PM_EVT_CONN_SEC_CONFIG_REQ

because if i don't change it the nrf52 cotinue to reject the pairing, also if i delete the bonding information. So i have set the allow_pairing= true; Note that this think it was necessary only after i have add to whitelist on mi FW design. Before add whitelist, i can bonding with a device already bondend, ( do you see any reason?)

Meanwhile, the step that reset my device is:

Bonding parinig first times
Delete bonding only on phone side, set the allow_pairing = true, i can pairing and bonding again without a problem
Delete bonding and pairing on both side cause a reset.

Have you any idea, about this strange bahaviour?

regards, Anna

RE: Bonding information issue when only one side the bonding is delete

Petter Myhre — Mon, 19 Jun 2017 16:23:04 GMT

If there is no peer data in flash no event is sent, see the documentation for pm_peers_delete():

** @note No event is sent when there is no peer data in flash.*

RE: Bonding information issue when only one side the bonding is delete

annapalu — Mon, 19 Jun 2017 16:05:14 GMT

Yes, it returns NRF_SUCCESS. One question, what happens if i delete the bonding information if i don't have a peer id memorize? Before the first bonding and connection i call the pm_peers_delete(), can be it a problem?

RE: Bonding information issue when only one side the bonding is delete

Petter Myhre — Mon, 19 Jun 2017 15:48:20 GMT

Is pm_peers_delete(); called successfully? Does it return 0x00000000 (NRF_SUCCESS)?

I can test your project, but then you need to upload the project that actually exhibits the behavior.

RE: Bonding information issue when only one side the bonding is delete

annapalu — Wed, 14 Jun 2017 11:51:29 GMT

i'll try with the flow:

err_code = pm_peers_delete();
wait the event PM_EVT_PEERS_DELETE_SUCCEEDED;
after delete bonding information

the problem is not resolved :(

someone can be tell me what means "peer_id is free, or the module is not initialized."?

RE: Bonding information issue when only one side the bonding is delete

annapalu — Wed, 14 Jun 2017 11:31:35 GMT

The only question that i have is:

/*note no event is sent when there is no peer data in flash.

So in the case the advertising not starting?

RE: Bonding information issue when only one side the bonding is delete

annapalu — Wed, 14 Jun 2017 08:23:15 GMT

Ok, i'll try. Thanks a lot

RE: Bonding information issue when only one side the bonding is delete

Hung Bui — Tue, 13 Jun 2017 08:06:09 GMT

@annapalu: You should not start advertising when there is flash operation in progress. My suggestion is, delete bond information, wait for PM_EVT_PEERS_DELETE_SUCCEEDED then disconnect, and when you disconnected (wait for the event) you can start advertising.

RE: Bonding information issue when only one side the bonding is delete

annapalu — Mon, 12 Jun 2017 08:59:22 GMT

Hi Petter,

yes i have commented it. Sorry maybe in the project i have forget to commit it. But in my project it is commented and the error occurs. My question is: can be a problem delete the bonding information and after disconnect the device, without waiting for the PM_EVT_SUCCESS?

RE: Bonding information issue when only one side the bonding is delete

Petter Myhre — Thu, 08 Jun 2017 08:44:45 GMT

So you removed it? It is there in the project you sent me:

    case PM_EVT_PEERS_DELETE_SUCCEEDED:
        advertising_start();
        break;

RE: Bonding information issue when only one side the bonding is delete

annapalu — Wed, 07 Jun 2017 15:25:22 GMT

i don't have advertising start with the DELETE_SUCCEDED.

this is my case:

  case  (PM_EVT_PEERS_DELETE_SUCCEEDED):
        break;

Complete below:

    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. */
          
         switch (p_evt->params.conn_sec_failed.error)
         {
            case PM_CONN_SEC_ERROR_DISCONNECT :
            NRF_LOG_PRINTF_DEBUG("error: PM_CONN_SEC_ERROR_DISCONNECT ");
            break;//PM_CONN_SEC_ERROR_DISCONNECT

            case PM_CONN_SEC_ERROR_SMP_TIMEOUT:
            NRF_LOG_PRINTF_DEBUG("error: PM_CONN_SEC_ERROR_SMP_TIMEOUT");
            break;//PM_CONN_SEC_ERROR_SMP_TIMEOUT
            
            case PM_CONN_SEC_ERROR_PIN_OR_KEY_MISSING:
               // Rebond if one party has lost its keys.
               err_code = pm_conn_secure(p_evt->conn_handle, true);
               if (err_code != NRF_ERROR_INVALID_STATE)
               {
               APP_ERROR_CHECK(err_code);
               }
               break;
           
            default:
            NRF_LOG_PRINTF_DEBUG("unknown error");
            break;
         }
            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_SUCCEEDED):
            break;
     
      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: Bonding information issue when only one side the bonding is delete

Petter Myhre — Wed, 07 Jun 2017 15:21:43 GMT

After you have called pm_peers_delete() you will get the PM_EVT_PEERS_DELETE_SUCCEEDED event, which will trigger advertising_start(). If you are in a connection this will probably lead to an error and a reset. Does it help if you uncomment advertising_start()?

RE: Bonding information issue when only one side the bonding is delete

annapalu — Wed, 07 Jun 2017 13:13:51 GMT

Hi Petter, sorry for the delete.

I delete the bonding information with err_code = pm_peers_delete();

maybe can be the problem that i delete the bonding information when i am connected? i after the delete peer call the

  uint32_t err_code;
      
err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
  return err_code;

Thanks, Anna

RE: Bonding information issue when only one side the bonding is delete

Petter Myhre — Mon, 29 May 2017 13:10:28 GMT

How are you deleting the bonding on the nordic board?

RE: Bonding information issue when only one side the bonding is delete

annapalu — Mon, 29 May 2017 09:56:41 GMT

I have understood that have this problem when the m_pi.active_peer_ids is all 0. This can help you to understood the problems? To me "No" :(

RE: Bonding information issue when only one side the bonding is delete

annapalu — Mon, 29 May 2017 08:12:26 GMT

Any suggestions?

RE: Bonding information issue when only one side the bonding is delete

annapalu — Fri, 26 May 2017 12:50:11 GMT

ble_app_gls.7z

RE: Bonding information issue when only one side the bonding is delete

annapalu — Fri, 26 May 2017 12:49:20 GMT

Yes i do. i have understood that the problem there is when i have add the whitelist. I load the gls_example modify with the withelist and you can reproduce the issue. Load the project, do pairing and bonding. After if delete before the bonding information on phone side before and after on nordic board, i have a reset.

RE: Bonding information issue when only one side the bonding is delete

Petter Myhre — Tue, 23 May 2017 13:36:49 GMT

Ok. Can you please edit your question and include your complete project or a project that reproduces this behavior so I can test it here?

RE: Bonding information issue when only one side the bonding is delete

annapalu — Mon, 22 May 2017 13:54:20 GMT

The problem is here:

ret_code_t pdb_write_buf_get(pm_peer_id_t       peer_id,
                             pm_peer_data_id_t  data_id,
                             uint32_t           n_bufs,
                             pm_peer_data_t   * p_peer_data)
{
    VERIFY_MODULE_INITIALIZED();
    VERIFY_PARAM_NOT_NULL(p_peer_data);
    VERIFY_DATA_ID_WRITE_BUF(data_id);
    if (   (n_bufs == 0)
        || (n_bufs > N_WRITE_BUFFERS)
        || !pds_peer_id_is_allocated(peer_id))
    {
        return NRF_ERROR_INVALID_PARAM;
    }

the function pds_peer_id_is_allocated(peer_id) return false. But this happens after i delete the bonding information.

If i read the comment says:

/**@brief Function for finding out whether a peer ID is in use.
 *
 * @param[in]  peer_id  The peer ID to inquire about.
 *
 * @retval  true   peer_id is in use.
 * @retval  false  peer_id is free, or the module is not initialized.
 */
bool pds_peer_id_is_allocated(pm_peer_id_t peer_id);

RE: Bonding information issue when only one side the bonding is delete

annapalu — Mon, 22 May 2017 09:22:56 GMT

No, it doesn't. This happens when i delete bonding information first from phone side, and after on nordic evaluation board. But not always, only sometimes. But this cause the reset of device so can be a problem

RE: Bonding information issue when only one side the bonding is delete

Petter Myhre — Sun, 21 May 2017 18:52:06 GMT

If pdb_write_buf_get() returns NRF_ERROR_INVALID_PARAM this should be the reason:

 * @retval NRF_ERROR_INVALID_PARAM  Data ID or Peer ID was invalid or unallocated, or n_bufs was 0
 *                                  or more than the total available buffers.

Does this give you any useful hints to why you get this error? If not I think you need to include some more code, or maybe even your complete project, so I can try to reproduce.

RE: Bonding information issue when only one side the bonding is delete

annapalu — Thu, 18 May 2017 14:32:55 GMT

Hi petter, sdk 11