After bonding, I receive write events from the central, but after reconnecting, the write events no longer come through.

[keigo.imaizumi]

Nice to meet you.

I'm looking to embark on BLE development using nrf52840.
The requirements include one-to-one communication with one central and one peripheral, and pairing using LE Secure Connection is necessary (just works).
I will be developing the peripheral side of this. The BLE requirements are based on the specifications of the central side.

Now, initially, I tried implementing it myself based on various online information and samples.
I have successfully paired, and I can receive write events from the central side.
However, when I turn off the power on the central side, then turn it back on and perform a reconnection, I no longer receive write events from the central side.

Specifically, I am manipulating the central device to perform a write operation on the peripheral.
However, I only receive BLE_GAP_EVT_CONN_PARAM_UPDATE, and no other events.

First, let me share the logs!
If there's anything suspicious, please let me know. I can also provide the code.
Thank you.

SEGGER J-Link V7.88j - Real time terminal output
SEGGER J-Link (unknown) V1.0, SN=1050228242
Process: JLinkGDBServerCLExe
<info> app_timer: RTC: initialized.
<info> app: ble_stack__init
<info> app: Service UUID:0000, UUID Type: 2
<info> app: Erase bonds.
<info> peer_manager_handler: All peers deleted.
<info> app: PM_EVT_PEERS_DELETE_SUCCEEDED
<info> app_timer: RTC: initialized.
<info> app: ble_stack__init
<info> app: Service UUID:0000, UUID Type: 2
<info> app: Erase bonds.
<info> peer_manager_handler: All peers deleted.
<info> app: PM_EVT_PEERS_DELETE_SUCCEEDED
<info> app: PM_EVT_CONN_CONFIG_REQ
<info> app: BLE_GAP_EVT_CONNECTED
<info> app: PM_EVT_CONN_SEC_START
<info> app: PM_EVT_CONN_SEC_PARAMS_REQ
<info> app: BLE_GAP_EVT_SEC_PARAMS_REQUEST
<info> app: BLE_GAP_EVT_LESC_DHKEY_REQUEST
<info> nrf_ble_lesc: Calling sd_ble_gap_lesc_dhkey_reply on conn_handle: 0
<info> app: BLE_GAP_EVT_CONN_SEC_UPDATE
<info> app: Security mode: 1. Security level: 2
<info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Bonding
<warning> app: PM_EVT_CONN_SEC_SUCCEEDED
<info> app: BLE_GAP_EVT_AUTH_STATUS: status=0x0, bond=0x1, kdist_own:0x3 kdist_peer:0x2
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bonding data, action: Update
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash changed.
<info> app: New Bond, add the peer to the whitelist if possible
<info> app: whitelist_peer_cnt 1, MAX_PEERS_WLIST 8
<info> app: Bonded to a new peer, add it to the whitelist.
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash changed.
<info> app: PM_PEER_DATA_ID_PEER_RANK
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Flash changed.
<info> app: PM_PEER_DATA_ID_GATT_LOCAL
<warning> app: ble_evt_handler:53
<info> app: BLE_GATTS_EVT_WRITE
<info> app: Notification enabled
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Central address resolution, action: Update
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash changed.
<info> app: PM_PEER_DATA_ID_CENTRAL_ADDR_RES
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash changed.
<info> app: PM_PEER_DATA_ID_GATT_LOCAL
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 00 02 00 1E 00 1A 00|........
<info> app:  01 61 C6 00 54 53 11 00|.a..TS..
<info> app:  A5 16 FF 00            |....    
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 01 FF FF 00 00 A7 0B|........
<info> app:  AF 16 00 01 00 00 00 52|.......R
<info> app:  7C 07                  ||.      
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 00 02 00 1E 00 1A 00|........
<info> app:  01 61 C6 00 54 53 11 00|.a..TS..
<info> app:  A5 16 FF 00            |....    
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 01 FF FF 00 00 A7 0B|........
<info> app:  AF 16 00 01 00 00 00 52|.......R
<info> app:  7C 07                  ||.      
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 00 02 00 1E 00 1A 00|........
<info> app:  01 61 C6 00 54 53 11 00|.a..TS..
<info> app:  A5 16 FF 00            |....    
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 01 FF FF 00 00 A7 0B|........
<info> app:  AF 16 00 01 00 00 00 52|.......R
<info> app:  7C 07                  ||.      
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 00 02 00 1E 00 1A 00|........
<info> app:  01 61 C6 00 54 53 11 00|.a..TS..
<info> app:  A5 16 FF 00            |....    
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 01 FF FF 00 00 A7 0B|........
<info> app:  AF 16 00 01 00 00 00 52|.......R
<info> app:  7C 07                  ||.     

======
Here, intentionally turning the power of the central device OFF/ON to trigger a reconnection.
======

<info> app: Disconnected, reason 8.
<info> app: PM_EVT_CONN_CONFIG_REQ
<info> app: PM_EVT_CONN_SEC_PARAMS_REQ
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update, no change
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash not changed.
<info> app: PM_PEER_DATA_ID_PEER_RANK
<warning> app: PM_EVT_BONDED_PEER_CONNECTED
<info> app: PM_EVT_LOCAL_DB_CACHE_APPLIED
<info> app: BLE_GAP_EVT_CONNECTED
<info> app: PM_EVT_CONN_SEC_START
<info> app: BLE_GAP_EVT_SEC_INFO_REQUEST
<info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Encryption
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update, no change
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash not changed.
<info> app: PM_PEER_DATA_ID_PEER_RANK
<warning> app: PM_EVT_CONN_SEC_SUCCEEDED
<info> app: BLE_GAP_EVT_CONN_SEC_UPDATE
<info> app: BLE_GAP_EVT_CONN_PARAM_UPDATE
<info> app: connection parameters updated. min_interval:160, max_interval:160, latency:0, timeout:810
<info> app: BLE_GAP_EVT_CONN_PARAM_UPDATE
<info> app: connection parameters updated. min_interval:80, max_interval:80, latency:0, timeout:810
<info> app: BLE_GAP_EVT_CONN_PARAM_UPDATE
<info> app: connection parameters updated. min_interval:160, max_interval:160, latency:0, timeout:810
<info> app: BLE_GAP_EVT_CONN_PARAM_UPDATE
<info> app: connection parameters updated. min_interval:80, max_interval:80, latency:0, timeout:810
<info> app: BLE_GAP_EVT_CONN_PARAM_UPDATE
<info> app: connection parameters updated. min_interval:160, max_interval:160, latency:0, timeout:810

[Hung Bui]

Hi Keigo, 

It's strange the lower case alphabet worked for you. As you can find in my screenshot, I used uppercase and it also worked.
I suspect that it could be something wrong with the uppercase in your setting, can be something with different alphabet keyboard setting ? I assume you have Japanese keyboard. For example if the keyboard use a similar character but not the same as in the default keyboard.

Anyway, it's good that you have the sniffer working now :) 

Regarding your question, a common practice for securing the connection is to let the central handling it. The peripheral should instead set the security level of the characteristic/service to the level that it desired. 
For example you can find the instruction in the Apple Bluetooth design guideline here at section 49.10: 
https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf

I think what you are implementing is fine, giving the central time to secure the connection, if it doesn't (after 4 seconds) you can start requesting. You can choose to request or not, but as long as you set the security level for the service when you declare it, then it's fine.