nRF52840 random disconnection

[Dani]

Good morning,

We have a new equipment based on the nRF52840 and s140.

                Just now, a new problem has appeared and it is very strange, as it seems to be a ‘random’ error:

 

                We have already assembled tens of equipment, and most of them are perfectly working with any smartphone (using both your ‘nRF Connect’ application or our own application).

                But, we have a few smartphones that show a strange behavior: they are able to perfectly connect to some of our nRF52840-based equipment, and in a few ones, they are able to connect but they get disconnected after a few seconds. Same equipment is connecting to other smartphones without problems (without disconnecting).

                This is (step by step) what it is happening a few times:

• Equipment (nRF52840) is advertising.
• Smartphone stablish connection with equipment using pin number
• First time, the connection is perfectly working.
• If smartphone is disconnected and connected back again with same equipment (Already bonded), then connection is stablished but smartphone disconnects after 30”, approximately. Same behavior is happening with both nRF connect application and our own application. Looking at log in nRF application we see: ‘Connection terminated by peer (status 19)’or ‘GATT_CONN_TIMEOUT’

 

Why is it happening?

Which is the reason?

How can we solve this?

 

 Could you help us? (For your information, we have set MIN_CONN_INTERVAL to 7.5m and MAX_CONN_INTERVAL to 100ms)

Thank you

[Hung Bui]

Hi Daniel, 

I got the update from Brian Kim about your email discussion. I agree with Brian that the sniffer trace would play a very important role here to solve the issue. I have some comments: 

- Regarding the sniffer trace, I could see the communication because the link was encrypted. What you need to do is to either do Legacy pairing and use the sniffer to follow the initial bonding. Or use LESC but in debug mode. 

- Another option you can try is to turn off bonding and encryption requirement to see if the issue is related to bonding or not. If the issue remain, please capture a sniffer trace. 

- The disconnection happened at second 26th into the connection so it may not related to the 30seconds GAP/GATT timeout.

- Please try to do a chip erase on the defected board and test again.

- Please try to test using one of our example in the SDK, ble_app_proximity for example. 

[Dani]

Hi again,

I have programmed one equipment turning bonding off, and then it is imposssible to connect (please, look at the attached screenshot with nRF Connect).

In order to set it off, I set my variable 'BONDING_WITH_NO_CODE' to 1, and I have implement this in 'peer_manager_init' function:

static void peer_manager_init(void)
{
    ble_gap_sec_params_t sec_param;
    ret_code_t           err_code;

    err_code = pm_init();
    APP_ERROR_CHECK(err_code);

    memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));

    // Security parameters to be used for all security procedures.
		if(BONDING_WITH_NO_CODE)
		{
			sec_param.bond         = 0;    
			sec_param.oob          = 0;
			sec_param.mitm         = 0; 
			sec_param.io_caps      = BLE_GAP_IO_CAPS_NONE;
			sec_param.kdist_own.enc  = 0;
			sec_param.kdist_own.id   = 0;
			sec_param.kdist_peer.enc = 0;
			sec_param.kdist_peer.id  = 0;
		}
		else
		{
			sec_param.bond           = SEC_PARAM_BOND;
			sec_param.oob            = SEC_PARAM_OOB;
			sec_param.mitm           = SEC_PARAM_MITM; //Static Key
			sec_param.io_caps        = SEC_PARAM_IO_CAPABILITIES;    
			sec_param.kdist_own.enc  = 1;
			sec_param.kdist_own.id   = 1;
			sec_param.kdist_peer.enc = 1;
			sec_param.kdist_peer.id  = 1;
		}
		
        
    sec_param.lesc           = SEC_PARAM_LESC;
    sec_param.keypress       = SEC_PARAM_KEYPRESS;    
    sec_param.min_key_size   = SEC_PARAM_MIN_KEY_SIZE;
    sec_param.max_key_size   = SEC_PARAM_MAX_KEY_SIZE;
    

    err_code = pm_sec_params_set(&sec_param);
    APP_ERROR_CHECK(err_code);

    err_code = pm_register(pm_evt_handler);
    APP_ERROR_CHECK(err_code);
}

Furthermore, in this case, in all services, I proceed in the following way:

if(BONDING_WITH_NO_CODE)
{
	BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm);
	BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);			
}		
else
{
	BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&attr_md.read_perm);
	BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&attr_md.write_perm);
}

Hope to go ahead with the solution.

Best regards,

Dani.

[Hung Bui]

Hi again Daniel, 

It still can't decode the connection. Note that the empty packet is not encrypted. 

Please click the arrow button before starting the connection, basically the sniffer need to have the keys before the LL_START_ENC_REQ (0x05) packet. And the key need to be correct key (reversed byte order). 

[Dani]

Hi Hung,

I've tried many times, and no good results.

Look at the attached screenshot: it shows debug values (LTK is seen) and Wireshark tool (LTK is introduced).

I have proceeded in the way you have told me:

- Device already bonded to my smartphone

- I disconnect device from smartphone

- I set Wireshark to save trace, introduce LTK and push the right arrow

- I connect device to smartphone

But not expected results are seen: "bad MIC" is also shown. I have also tried with LTK upside down, but same result...

Maybe we can talk and meet using remote connection with my computer? Any other idea?

Dani

[Hung Bui]

Hi Daniel, 

I tested again here and facing the same problem as you. I couldn't decrypt the connection even with the LTK. It's really strange that just a few days ago it worked for me. 

I'm checking with the team if I'm missing something. 
In the mean time I would suggest to try testing with the nRF Connect app on the phone, make sure it's only re-bonding happens and no other activity just to check if the disconnection still happen. 

Also please try to print out in the log any BLE event when you connect.

Do you store any information in flash ? If you do I would suggest to skip them, just in case they cause issue with the bond information. 

One approach to debug is to step by step removing the functionalities of the application. Until it's get very similar to one of our example in the SDK.  I assume that when you test with the example in the SDK with LESC you didn't have the issue ? Have you tried with the ble_app_gls example ? 

[Dani]

Hi Hung,

I have already checked with nRF Connect: as I told you at the beginning, the same is happening --> I get '‘Connection terminated by peer (status 19)’' after about 30". I have proceed as follows: having the device bonded, I go to bonded tab, and I select my device to connect again. I have even tried to reset the device, but once bonded, it is always happening same situation when reconnecting (only the first time -when introducing pin number- the device remains connected). Please, look at attached screenshot.

I store application information in flash (many time ago I managed it with your support in order to be sure it was correctly set: https://devzone.nordicsemi.com/f/nordic-q-a/56766/buttonless-dfu-with-bonding).

I have following setup:

- FDS_VIRTUAL_PAGES 6 (For bondings & garbage)

#define FLASH_ADR_FINAL_FLASH (u32) 0x000f2000 //Bootloader initial adress
#define FLASH_ADR_INI_PAGE_1 (u32)(FLASH_ADR_FINAL_FLASH-0x1000) //Page1(app)
#define FLASH_ADR_INI_PAGE_2 (u32)(FLASH_ADR_INI_PAGE_1-0x1000) //Page2(app)
#define FLASH_ADR_INI_PAGE_3 (u32)(FLASH_ADR_INI_PAGE_2-0x1000) //Page3(app)
#define FLASH_ADR_INI_PAGE_4 (u32)(FLASH_ADR_INI_PAGE_3-0x1000) //Page4(app=
#define FLASH_ADR_INICI_FLASH FLASH_ADR_INI_PAGE_4 //To use for NRF_FSTORAGE_DEF

NRF_FSTORAGE_DEF(nrf_fstorage_t fstorage) =
{
    /* Set a handler for fstorage events. */
    .evt_handler = fstorage_evt_handler,

    /* These below are the boundaries of the flash space assigned to this instance of fstorage.
     * You must set these manually, even at runtime, before nrf_fstorage_init() is called.
     * The function nrf5_flash_end_addr_get() can be used to retrieve the last address on the
     * last page of flash available to write data. */
    .start_addr = FLASH_ADR_INICI_FLASH,
    .end_addr   = FLASH_ADR_FINAL_FLASH,
};

Also note than in Bootloader I set :

NRF_DFU_APP_DATA_AREA_SIZE   40960 (10 pages: 6 VIRTUAL + 4 data)

I will try with other applications: But as I said, it is very strange, as with the same smartphone, some of my devices are correctly working. Some other, as described here, disconnect after 30".

Thank you again for your efficient and fast support: it is very important for us. But, do you think we could get with the solution soon? This equipment is in production, and similar problem is appearing in some customers!!

Dani.

[Hung Bui]

Hi Dani, 

It's hard to say how long it would take to get a solution. I think it's the best if we can narrow down the issue. 

You mentioned earlier that if you comment out the sd_ble_gap_disconnect() inside BLE_GATTC_EVT_TIMEOUT and BLE_GATTS_EVT_TIMEOUT you don't experience the disconnection. 

Please try to narrow down if it's BLE_GATTS_EVT_TIMEOUT  or BLE_GATTC_EVT_TIMEOUT event causing the issue ? The GATT timeout happens when a write/read request or indication doesn't get a reply form the peer. 

I think the approach to debug this is : 

- Make sure you can print out log from the nRF52 either by UART or by RTT 

- Try to strip down the functionality of the application until you don't see the error 

- If you test with legacy pairing just work the issue never happen ? It's pretty strange that the bonding process would be related to the GATT timeout.

- How many phones have you experienced the issue ?  Could you give the model number of the phones ? 

[Dani]

Hi Hung,

It's always BLE_GATTS_EVT_TIMEOUT the event that causes the issue --> In my application, we send a notification (we never send indication) once every 62.5ms. Which reply must it receive from the peer when sending notifications?? Which can be the reason to not receive that reply?

Furthermore, does it has sens to implement a counter in this event, and just disconnect when it is received a few times? In this case, which will be the most suitable event to implement the reset of this counter?

To print out log by RTT (I guess this is info to be observed using nRFConnect), I guess I should use NRF_LOG_DEBUG calls, right?

And yes, without bonding, the problem does not appear.

I'm working on it, trying to find out the solution. We will also test example applications.

In what regards phones experiencing this issue:

- Xiaomi Mi8

- Huawei 20 Pro

- Oppo A74

- Tablet Galaxy Tab A SM-T580

Dani

PD: The problem with the BLE_GATTS_EVT_TIMEOUT event seems to be related to anything set to the limit. Now, I'm debugging my application (Without having modified nothing) being connected to a Xiaomi Mi8, and now is working fine most of the times (no disconnections): still disconnects some of them. 

[Dani]

Hi Hung,

I have implemented an event counter to count BLE_GATTS_EVT_TIMEOUT, and now I'm not disconnecting the device when this event is given.

What I have observed:

- The event is received only once

- But after being received:

                  - If the application (smartphone) wants to write into a characteristic, it is not possible and then the device is disconnected (an other event is given, but I do not know still which one)

                  - The device is able to continue sending notifications to the smartphone without problems

Hope it helps a bit more

Dani

[Hung Bui]

Hi Dani, 

Notification doesn't require any reply from the peer, so it should not cause any problem with BLE_GATTS_EVT_TIMEOUT . 

What you can try is to remove any BLE activity from your service /characteristic just to see if it was from your service/characteristic or not. 

The problem with the workaround that you are doing is that according to spec there shouldn't be any further ATT packet after the time out hence the disconnection: 

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v7.3.0/group___b_l_e___g_a_t_t_s___t_i_m_e_o_u_t___m_s_c.html?cp=4_7_3_1_2_4_3_18

Could you try to capture a sniffer trace with Legacy bonding just work ? I want to see how a normal operation would work with your device (the notifications and other BLE activities when re-connect to the phone) 

Regarding logging,it's not the same log as on nRF Connect. 
To be able to send the log to RTT, you need to select  NRF_LOG_BACKEND_RTT_ENABLED = 1 and select NRF_LOG_BACKEND_UART_ENABLED=0.  (NRF_LOG_ENABLED need to be set to 1 as well) 

Also the SEGGER_RTT files need to be included. I would suggest to have a look at our ble_app_* example see how it works. 

[Dani]

Hi Hung,

With SEC_PARAM_LESC=1 and no bonding, the smartphone is only able to connect the first time. The second time I receive:

- Error 8 (0x8): GATT INSUF AUTHORIZATION

This is the setup of the main parameters (Which definition concerning these parameters do you want in order to register the sniffer trace?):

sec_param.bond           = 0;
sec_param.oob            = 0;
sec_param.mitm           = 0;
sec_param.io_caps        = BLE_GAP_IO_CAPS_NONE;    						
sec_param.kdist_own.enc  = 1;
sec_param.kdist_own.id   = 1;
sec_param.kdist_peer.enc = 1;
sec_param.kdist_peer.id  = 1;

		
        
sec_param.lesc           = 1;
sec_param.keypress       = SEC_PARAM_KEYPRESS;     ('0')
sec_param.min_key_size   = SEC_PARAM_MIN_KEY_SIZE; ('7')
sec_param.max_key_size   = SEC_PARAM_MAX_KEY_SIZE; ('16')

If I set SEC_PARAM_LESC=0, then it connects perfect all the times with different devices of the 'wrong' list I have sent to you. But all the times I'm asked if I want to pair with the device --> If I set 'yes' --> it connects perfectly.

I have done same tests with following setup considering also both values for SEC_PARAM_LESC, and the disconnection problem appears again:

sec_param.bond           = 1;
sec_param.oob            = 0;
sec_param.mitm           = 1; //Static Key
sec_param.io_caps        = SEC_PARAM_IO_CAPABILITIES;    						
sec_param.kdist_own.enc  = 1;
sec_param.kdist_own.id   = 1;
sec_param.kdist_peer.enc = 1;
sec_param.kdist_peer.id  = 1;

		
        
sec_param.lesc           = 1; //Also testes with 0
sec_param.keypress       = SEC_PARAM_KEYPRESS;     ('0')
sec_param.min_key_size   = SEC_PARAM_MIN_KEY_SIZE; ('7')
sec_param.max_key_size   = SEC_PARAM_MAX_KEY_SIZE; ('16')

On the other hand, I have read a ticket (https://devzone.nordicsemi.com/f/nordic-q-a/61691/reject-non-lesc-pairing-not-allowing-legacy-pairing) where it appears the PM_EVT_CONN_SEC_PARAMS_REQ. I didn't have this event implemented. Now, I have it implemented in the following way inside 'pm_evt_handler' function. Although problem is not solved, this implementation, is it correct?:

static void pm_evt_handler(pm_evt_t const * p_evt)
{
    ret_code_t err_code;
	
		pm_conn_sec_config_t config; 
		pm_conn_sec_status_t conn_sec_status;							   
 
		pm_handler_on_pm_evt(p_evt);
		pm_handler_disconnect_on_sec_failure(p_evt);									  
    pm_handler_flash_clean(p_evt);

    switch (p_evt->evt_id)
    {
			
				case PM_EVT_CONN_SEC_SUCCEEDED:						

          // Check if the link is authenticated (meaning at least MITM).
          err_code = pm_conn_sec_status_get(p_evt->conn_handle, &conn_sec_status);
          APP_ERROR_CHECK(err_code);
					
					break;
				
				case PM_EVT_CONN_SEC_FAILED:
						m_ble_general.ble_conn_handle = BLE_CONN_HANDLE_INVALID;						
					break;

//        case PM_EVT_PEERS_DELETE_SUCCEEDED:
//            advertising_start();
//            break;
				
				case PM_EVT_CONN_SEC_CONFIG_REQ:
					config.allow_repairing = true;
					pm_conn_sec_config_reply(p_evt->conn_handle, &config);
						break;
				
				case PM_EVT_BONDED_PEER_CONNECTED:
					pm_local_database_has_changed(); 
			
						break;
				
				
				case PM_EVT_CONN_SEC_PARAMS_REQ:
					pm_conn_sec_params_reply(p_evt->conn_handle,NULL,NULL);
						break;
				
	

        default:
            break;
    }
}

Apart of this. As you suggested, I have setup my application to not send any notification and I have tested it with nRF Connect (with bonding and passkey and SEC_PARAM_LESC to 0:

- I have connected first time without problems with Xiaomi Mi8

- I have disconnected it after some time and I have connected again. I have repeated this many times (15-20) and it seemed to work fine.

- Then I have bonded the device to a different smartphone, and it has correctly connected (also many times)

- Then I have connected back to first smartphone (Xiaomi Mi8) and in the first trial, the message "Connection terminated by peer (Status 19)" has appeared again. And now, it appears all the times I try to connect.

This is quite confusing...

Continuing with testing....

Dani

[Dani]

Hi Hung,

Could you also check my 'ble_evt_handler' function:

static void delete_bonds(void)
{
    ret_code_t err_code;   
	
		if(pm_peer_count()>8)
		{
			pm_peer_id_t peer_id_to_delete;
			err_code = pm_peer_ranks_get(NULL,NULL,&peer_id_to_delete,NULL); //Bond més vell que no s'utilitza
			APP_ERROR_CHECK(err_code);
			err_code = pm_peer_delete(peer_id_to_delete);
			APP_ERROR_CHECK(err_code);
		}
}

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    ret_code_t err_code;
		u8 *p_ch_index;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
					
            m_ble_general.ble_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;				
						err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_ble_general.ble_conn_handle);
            APP_ERROR_CHECK(err_code);
				
						//Long Range: 8dBm (Long Range)
						err_code = sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_CONN, m_ble_general.ble_conn_handle, 8);
				
						//App management
						T_equip.Estat_canvi_PIN=AGR_PIN_NO_CHANGE;
						T_equip.xTempsGestioPIN=0;	

						//RSSI		
						err_code = sd_ble_gap_rssi_start(p_ble_evt->evt.gap_evt.conn_handle, 10, 0);
            APP_ERROR_CHECK(err_code);
						
            
            
            break;

        case BLE_GAP_EVT_DISCONNECTED:					
					
						NRF_LOG_INFO("Disconnected reason: %d.",p_ble_evt->evt.gap_evt.params.disconnected.reason);
				
						//Stop RSSI
						sd_ble_gap_rssi_stop(p_ble_evt->evt.gap_evt.conn_handle);
				
            
                        m_ble_general.ble_conn_handle = BLE_CONN_HANDLE_INVALID;
						
						//App management
						m_ble_general.T_advertising.busy=NO;						
				
						//App management
						if(T_equip.Estat_canvi_PIN==AGR_PIN_USER_CHANGE)
						{
							T_equip.Estat_canvi_PIN=AGR_PIN_NO_CHANGE;
							u8 passkey[]="000000";
							u32_to_ascii(ble_installer_configuracio_sortides_psw.password_app,passkey,XIFRES_PASSKEY); //Convertim el valor del password disponible a cadena de caràcters
							m_static_pin_option.gap_opt.passkey.p_passkey = passkey;
							err_code =  sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &m_static_pin_option);
							APP_ERROR_CHECK(err_code);
							T_equip.PIN_actual=ble_installer_configuracio_sortides_psw.password_app;
						}
						
						else if(T_equip.Estat_canvi_PIN==AGR_PIN_FACTORY_CHANGE)
						{
							T_equip.Estat_canvi_PIN=AGR_PIN_WAITING_FACTORY_CONNECTION;
							u8 passkey[]="000000";
							u32_to_ascii(CodisActivacio(ID_CODI_PIN_APP),passkey,XIFRES_PASSKEY); //Convertim el valor del password DE FÀBRICA a cadena de caràcters
							m_static_pin_option.gap_opt.passkey.p_passkey = passkey;
							err_code =  sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &m_static_pin_option);
							APP_ERROR_CHECK(err_code);
							T_equip.PIN_actual=CodisActivacio(ID_CODI_PIN_APP);
							T_equip.xTempsGestioPIN=TEMPS_MAXIM_CANVI_PIN;
						}
						
						
						else
						{
							if(T_equip.PIN_actual==CodisActivacio(ID_CODI_PIN_APP))
							{
					
								if(T_equip.PIN_actual!=ble_installer_configuracio_sortides_psw.password_app)
								{
									u8 passkey[]="000000";
									u32_to_ascii(ble_installer_configuracio_sortides_psw.password_app,passkey,XIFRES_PASSKEY); //Convertim el valor del password disponible a cadena de caràcters
									m_static_pin_option.gap_opt.passkey.p_passkey = passkey;
									err_code =  sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &m_static_pin_option);
									APP_ERROR_CHECK(err_code);
									T_equip.PIN_actual=ble_installer_configuracio_sortides_psw.password_app;	
								}
							}
							
							//Erase bonds if more than 8 are saved
							delete_bonds();
							
						}
							
            
            break;

						
				case BLE_GAP_EVT_TIMEOUT:
            
					              

            m_ble_general.ble_conn_handle               = BLE_CONN_HANDLE_INVALID; //Això ens permetrà fer l'Advertising de forma periòdica mentre estem desconnectats.
								
						//App management
						m_ble_general.T_advertising.busy=NO;								
								
								
						
            
        break;
						
				case BLE_GATTS_EVT_SYS_ATTR_MISSING:
            
						err_code = sd_ble_gatts_sys_attr_set(p_ble_evt->evt.gap_evt.conn_handle, NULL, 0, 0);
            APP_ERROR_CHECK(err_code);
        break;
						
        case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_AUTO,
                .tx_phys = BLE_GAP_PHY_AUTO,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;
				
				
				case BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:
					//sd_ble_gap_data_length_update(&(p_ble_evt->evt.gattc_evt));
					sd_ble_gap_conn_param_update(p_ble_evt->evt.gap_evt.conn_handle, &p_ble_evt->evt.gap_evt.params.conn_param_update_request.conn_params);
					break;

        case BLE_GATTC_EVT_TIMEOUT:
            // Disconnect on GATT Client timeout event.            
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
			m_ble_general.T_advertising.busy=SI; //App management
            break;

        case BLE_GATTS_EVT_TIMEOUT:						            
						// Disconnect on GATT Server timeout event.            
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gatts_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
						m_ble_general.T_advertising.busy=SI; //App management
						
            break;
    
        case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
            
            break;
        
        case BLE_GAP_EVT_AUTH_KEY_REQUEST:					
            
            break;

        case BLE_GAP_EVT_LESC_DHKEY_REQUEST:
					
            
            break;

         case BLE_GAP_EVT_AUTH_STATUS:
            //App management
						if(p_ble_evt->evt.gap_evt.params.auth_status.auth_status!= BLE_GAP_SEC_STATUS_SUCCESS)
						{								
							sd_ble_gap_disconnect(m_ble_general.ble_conn_handle,BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
							m_ble_general.T_advertising.busy=SI; //Per evitar que faci advertising fins que estigui desconnectat
						}
            break;
						
						
				 case BLE_GAP_SEC_STATUS_CONFIRM_VALUE:
						//App management
						sd_ble_gap_disconnect(m_ble_general.ble_conn_handle,BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
						m_ble_general.T_advertising.busy=SI; //Per evitar que faci advertising fins que estigui desconnectat
				 
					 break;
				
				 //Guardem el valor de RSSI registrat		
				 case BLE_GAP_EVT_RSSI_CHANGED:
						C_equip.Nivell_RSSI = p_ble_evt->evt.gap_evt.params.rssi_changed.rssi;
					  //sd_ble_gap_rssi_get(p_ble_evt->evt.gap_evt.conn_handle,&(C_equip.Nivell_RSSI),p_ch_index);
						
					 break;
				 
				 case BLE_GATTC_EVT_HVX:
					 sd_ble_gattc_hv_confirm(p_ble_evt->evt.gap_evt.conn_handle, p_ble_evt->evt.gattc_evt.params.hvx.handle);
						break;

        default:
            // No implementation needed.
            break;
    }
}

And the 'pm_evt_handler' function:

static void pm_evt_handler(pm_evt_t const * p_evt)
{
    ret_code_t err_code;
	
		pm_conn_sec_config_t config; 
		pm_conn_sec_status_t conn_sec_status;							   
 
		pm_handler_on_pm_evt(p_evt);
		pm_handler_disconnect_on_sec_failure(p_evt);									  
    pm_handler_flash_clean(p_evt);

    switch (p_evt->evt_id)
    {
			
				case PM_EVT_CONN_SEC_SUCCEEDED:						

          // Check if the link is authenticated (meaning at least MITM).
          err_code = pm_conn_sec_status_get(p_evt->conn_handle, &conn_sec_status);
          APP_ERROR_CHECK(err_code);
					
					break;
				
				case PM_EVT_CONN_SEC_FAILED:
						m_ble_general.ble_conn_handle = BLE_CONN_HANDLE_INVALID;						
					break;

                case PM_EVT_PEERS_DELETE_SUCCEEDED:

                    break;
				
				case PM_EVT_CONN_SEC_CONFIG_REQ:
					config.allow_repairing = true;
					pm_conn_sec_config_reply(p_evt->conn_handle, &config);
						break;
				
				case PM_EVT_BONDED_PEER_CONNECTED:
					pm_local_database_has_changed(); 
			
						break;
				
				
				case PM_EVT_CONN_SEC_PARAMS_REQ:
					pm_conn_sec_params_reply(p_evt->conn_handle,NULL,NULL);
						break;
				
	

        default:
            break;
    }
}

Dani