central stops receiving after sometime

[Nivetha]

Hi,

Central: nrf52840

peripheral: nrf52840

Connection interval (both min & max) = 10ms

ATT_MTU size: 52 bytes

Dle: 52+4 bytes

Connection event extension: enabled

Slave latency: 0

Connection supervision timeout: 4s

PHY: 1MBps

softdevice: 140

I'm transmitting 10 samples wrapped to 48 bytes as notification and hence set the ATT_MTU size to 52 bytes considering the overhead for notification to 3 bytes + 1 extra safe side. The issue is suddenly after 30 mins there is a disconnection and I get to see only EMPTY DATA PDU through nrf sniffer. However, I didn't notice anything as Connection Disconnection timeout or so. It's just after the last notification, I get to see only EMPTY DATA PDU and no samples at the UART(which is logged at the central) This is for a medical application. So I need to maintain this throughput with very low/0 latency and no potential disconnection. Your valuable suggestions will help me fix the problem.

LOG

Thanks, Nivetha

[Nivetha]

No, I saw this message using JLink RTT viewer. When the disconnection occurs, as I said in my previous comments, i see the debugger is stuck at app_error_fault_handler(app_error_weak.c) which is invoked from the soft_device_fault_handler. Ths id is 4097, pc = 147256 or the address varies sometimes. The below message is logged at the peripheral device. it goes to # SEGGER J-Link RTT Viewer V6.16g Terminal Log File

# Compiled: 16:41:19 on Jul 10 2017
# Logging started @ 02 Oct 2017 14:00:54
SDH:DEBUG:RAM start at 0x200021b0.
 0> APP:DEBUG:Softdevice enabled
 0> TIMER:INFO:Function: nrf_drv_timer_init, error code: NRF_SUCCESS.
 0> TIMER:INFO:Timer id: 3, capture value set: 24, channel: 0.
 0> TIMER:INFO:Timer id: 3, capture value set: 32, channel: 1.
 0> TIMER:INFO:Timer id: 3, capture value set: 37, channel: 2.
 0> TIMER:INFO:Timer id: 3, capture value set: 40, channel: 3.
 0> TIMER:INFO:Timer id: 3, capture value set: 40, channel: 3.
 0> TIMER:INFO:Function: nrf_drv_timer_init, error code: NRF_SUCCESS.
 0> Overflow

Besides this information, I tried testing the peripheral device using the oscilloscope at the LEDs on which are enabled when the samples are available. To my surprise, I could see the signals in the oscilloscope but something is preventing it from being transmitted as notifications. Hence I'm adding more logs to the err_code = sd_ble_gatts_hvx(p_semg->conn_handle, &hvx_params); to see if something returned other than NRF_SUCCESS.