• State Verified Answer
  • Replies 28 replies
  • Subscribers 67 subscribers
  • Views 10850 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 127065
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE Central disconnect after exactly 65.5 sec

Gordon

Hi,

I'm having a problem at the moment with code based on Espruino on nrf52.

I connect as follows:

  ble_gap_scan_params_t     m_scan_param;
  memset(&m_scan_param, 0, sizeof(m_scan_param));
  m_scan_param.active       = 1;            // Active scanning set.
  m_scan_param.interval     = MSEC_TO_UNITS(100, UNIT_0_625_MS); // Scan interval.
  m_scan_param.window       = MSEC_TO_UNITS(90, UNIT_0_625_MS); // Scan window.
  m_scan_param.timeout      = 4;            // 4 second timeout.

  ble_gap_conn_params_t   gap_conn_params;
  memset(&gap_conn_params, 0, sizeof(gap_conn_params));
  gap_conn_params.min_conn_interval = MSEC_TO_UNITS(7.5, UNIT_1_25_MS);
  gap_conn_params.max_conn_interval = MSEC_TO_UNITS(500, UNIT_1_25_MS);
  gap_conn_params.slave_latency     = 0;
  gap_conn_params.conn_sup_timeout  = MSEC_TO_UNITS(4000, UNIT_10_MS);

  ble_gap_addr_t addr;
  addr = peer_addr;

  err_code = sd_ble_gap_connect(&addr, &m_scan_param, &gap_conn_params);

Connecting from one device running Espruino to another (both nRF52832DK), and 65.5 seconds after getting a BLE_GAP_EVT_CONNECTED the DK acting as central Espruino gets a BLE_GAP_EVT_DISCONNECTED event. Every time it disconnects, and every time it takes 65.5 seconds.

This doesn't happen when a PC/Android phone acts as Central connecting to a DK, and it doesn't happen when a DK acting as central connects to something else. It's only when one DK connects to another.

Any idea what might be the problem?

If needed I can supply a hex file and the sample code to reproduce this.

thanks!

Original Sniffer trace (sniffingbroken?): nrf52dk_disconnect.pcapng

Connected, start notifications, send one notification, then it exits

These traces I just connected it and didn't do anything else:

Android nRF Connect -> DK trace (disconnected by me after 70s) : nrf52dk_android.pcapng

iOS nRF Connect -> DK trace (disconnected by me after 70s) : nrf52dk_ios_nrfconnect.pcapng

DK -> DK trace (disconnected itself after 65.5s) : nrf52dk_espruino.pcapng

Parents
  • 0

    Thx. I'm not sure what is happening here, but from the sniffer trace it doesn't seem like the peripheral is disconnecting. From the trace it seems like there is no communication after 30.5s, and then 35s later the peripheral starts to advertise again? Do you start advertising again when you get the disconnection event? It also seems like the peripheral is sending a Connection Parameter Update request, are you calling sd_ble_gap_conn_param_update() somewhere? If you are, could you try not doing that? Please add the new sniffer trace as well.

  • 0 in reply to Petter Myhre

    The SoftDevice is disconnecting because the central is not responding to the CPU Request. By not responding it is breaking the specification, and this causes the disconnect after 60 seconds. So it is not a bug, it is expected behavior. The solution is to make the central respond, either with accept or reject. You are ending up in variant #3 in this MSC, but it is incorrect, because you don't get BLE_GAP_EVT_CONN_PARAM_UPDATE. Instead the SoftDevice disconnects, and you receive BLE_GAP_EVT_DISCONNECTED. I have reported this.

Reply
  • 0 in reply to Petter Myhre

    The SoftDevice is disconnecting because the central is not responding to the CPU Request. By not responding it is breaking the specification, and this causes the disconnect after 60 seconds. So it is not a bug, it is expected behavior. The solution is to make the central respond, either with accept or reject. You are ending up in variant #3 in this MSC, but it is incorrect, because you don't get BLE_GAP_EVT_CONN_PARAM_UPDATE. Instead the SoftDevice disconnects, and you receive BLE_GAP_EVT_DISCONNECTED. I have reported this.

Children
Related