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]

@Martin: Thank you so much. I adjusted the RAM size at the central and peripheral because both sides were showing up warnings. However, the actual problem is not yet solved. As usual, disconnection occurred during transmission, I just got a message at the transmitter as "Overflow" but I'm not sure from where this message is fired. "Disconnected" at the central.

[MartinBL]

Can you take a screenshot of this Overflow message? Is this shown in your debug IDE? Do see a stack trace or anything?

[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.

[MartinBL]

The "Overflow" message is printed when the log buffer is full. It could be interesting to see what potential messages we are missing out on due to full buffers. The solution is to increase NRF_LOG_BUFSIZE or trigger log processing more frequently.

[Nivetha]

OMG! this overflow message is due to log buffer being full! I was thinking that my stack is filled because of samples etc.. Should I increase this?NRF_LOG_BACKEND_RTT_OUTPUT_BUFFER_SIZE