Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE Peer Manager dependency on BLE Connection State Library?

(nRF51 SDK v12.3.0)

The function gcm_init() in gatt_cache_manager.c (BLE Peer Manager Lib) calls ble_conn_state_user_flag_acquire() part of the BLE Connection State Lib in order to use User Flags.

If BLE is disabled and enabled again (one second time), and peer_manager is initialized once more, then, NRF_ERROR_INTERNAL is returned by gcm_init().

It happens that, on that second time, all user flags are already acquired. Therefore, it seems that one has to call ble_conn_state_init() -which has nothing to do with peer_manager- to reset all user flags.

This dependency -if confirmed by Nordic- does not show a clean architecture.   

Parents
  •  

     

     

    The problem is that the user flags are not tied to a connection in a strong way. The user flags are acquired without any connection handle, so it is hard to say when you want to mark them as released. In your use case, where you want to re-initialize the BLE, it would have helped if we could have marked the user flags as free with less overhead than to call ble_conn_state_init(). 

    But with the current design, your workaround seems safest as it resets the whole state machine.

     

Reply
  •  

     

     

    The problem is that the user flags are not tied to a connection in a strong way. The user flags are acquired without any connection handle, so it is hard to say when you want to mark them as released. In your use case, where you want to re-initialize the BLE, it would have helped if we could have marked the user flags as free with less overhead than to call ble_conn_state_init(). 

    But with the current design, your workaround seems safest as it resets the whole state machine.

     

Children
No Data
Related