On Thu, Jun 30, 2016 at 12:39:00PM -0700, Simon Ratner wrote:
> Hi devs,
>
> I've been looking at the reasons I get in BLE_GAP_EVENT_DISCONNECT to make
> sure I cover all edge cases, and this is what I see (on an nrf51-based
> board):
>
> switch (ctxt->disconnect.reason) {
> case
On Thu, Jun 30, 2016 at 01:31:00PM -0700, Simon Ratner wrote:
> It is sometimes hard to tell if they are "expected", but below are a couple
> of sample traces.
>
> Based on the timestamps, I would say the first two are expected (device was
> slow to respond), while the last one is unexpected. In
> Based on the timestamps, I would say the first two are expected
>
...
> 896096:[ts=875093696ssb, mod=4 level=1] GATT procedure initiated: read by
> uuid; start_handle=40 end_handle=65535 uuid=0304
> 906398:[ts=885154208ssb, mod=64 level=2] gatt_cli: failed to read chr;
> conn_handle=1
Just following up on the BLE_HS_ENOMEM, the most obvious place where
ble_gattc_disc_svc_by_uuid
returns that is when it doesn't have a free gattc_proc.
I have max_gattc_procs set to NIMBLE_OPT(MAX_CONNECTIONS), any reason why
that would not be enough? Is it possible procs are not being returned
It is sometimes hard to tell if they are "expected", but below are a couple
of sample traces.
Based on the timestamps, I would say the first two are expected (device was
slow to respond), while the last one is unexpected. In the last trace, the
gatt op failed for another reason (rc=6 i.e.
Hi devs,
I've been looking at the reasons I get in BLE_GAP_EVENT_DISCONNECT to make
sure I cover all edge cases, and this is what I see (on an nrf51-based
board):
switch (ctxt->disconnect.reason) {
case BLE_HS_ENOTCONN:
/* I see this when the local host has terminated the
