The 573 is interesting also as my application has nothing to do with a mic.
I'm writing and receiving notifications.
I'm doing a
gatt-write conn=2 no_rsp=1 attr=25 value=10:01:00:00:01:10:02:10:03:53:56
then waiting for a response
notification rx event; attr_handle=25 indication=0 len=13
data=0x10:0x01:0x00:0x00:0x01:0x10:0x02:0x00:0x00:0x10:0x03:0xa6:0x03
These are the config values I built with. I disabled debug and logging and
enabled all the BLE feature sets. I found these out looking over a webpage
about how to test all the code paths in NimBLE. I figured out where they
are documented now and should revisit. I have a large list of errors or
documentation items that need added that I plan to take on.
syscfg.vals:
BLE_EDDYSTONE: 1
BLE_EXT_ADV: 1
BLE_EXT_ADV_MAX_SIZE: 1650
BLE_HCI_EVT_BUF_SIZE: 257
BLE_HS_DEBUG: 0
BLE_L2CAP_COC_MAX_NUM: 2
BLE_LL_CFG_FEAT_LE_2M_PHY: 1
BLE_LL_CFG_FEAT_LE_CODED_PHY: 1
BLE_LL_CFG_FEAT_LL_PRIVACY: 1
BLE_LL_CONN_INIT_MAX_TX_BYTES: 251
BLE_LL_DIRECT_TEST_MODE: 1
BLE_MAX_CONNECTIONS: 32
BLE_MONITOR_RTT: 1
BLE_MONITOR_RTT_BUFFER_SIZE: 2048
BLE_MULTI_ADV_INSTANCES: 5
BLE_SM_BONDING: 1
BLE_SM_LEGACY: 1
BLE_SM_SC: 1
BLE_STORE_MAX_BONDS: 32
CONSOLE_UART_BAUD: 460800
CONSOLE_MAX_INPUT_LEN: 4096
CONSOLE_UART_TX_BUF_SIZE: 1024
CONSOLE_UART_RX_BUF_SIZE: 1024
CONSOLE_ECHO: 0
CONSOLE_RTT_INPUT_POLL_INTERVAL_MAX: 10
CONSOLE_TICKS: 0
LOG_LEVEL: 255
LOG_CLI: 0
CONFIG_CLI: 0
CONFIG_CLI_DEBUG: 0
METRICS_CLI: 0
STATS_CLI: 0
STATS_NAMES: 0
On Tue, Feb 5, 2019 at 3:02 PM Christopher Collins <ch...@runtime.io> wrote:
> Hi Fred,
>
> On Tue, Feb 05, 2019 at 02:25:43PM -0500, Copper Dr wrote:
> > I'm trying to figure out how to decode these disconnections.
> >
> > Reason 688 (0x02B0) and 573 (0x023D)
> >
> > I checked
> >
> http://mynewt.apache.org/latest/network/docs/ble_hs/ble_hs_return_codes.html
> > and the disconnect code does not make any sense.
> >
> > The 573 is the one I'm really interested in it happened just before
> 65,535
> > commands were sent and is repeatable.
>
> I agree - 688 (0x2b0) does not make sense. This is not a valid error
> code, so there must be some memory corruption or some other bug at play
> here.
>
> As you noticed, 573 (0x23d) is a legitimate error code:
> BLE_ERR_CONN_TERM_MIC. I don't know if there is a relation to the
> number 65535, but that would be an interesting bug! I will let one of
> the controller experts chime in.
>
> Chris
>
> >
> >
> > disconnect; reason=688 handle=1 our_ota_addr_type=0
> > our_ota_addr=01:02:03:04:05:06 our_id_addr_type=0
> > our_id_addr=01:02:03:04:05:06 peer_ota_addr_type=1
> > peer_ota_addr=cb:a9:46:52:45:44 peer_id_addr_type=1
> > peer_id_addr=cb:a9:46:52:45:44 conn_itvl=40 conn_latency=0
> > supervision_timeout=256 encrypted=1 authenticated=1 bonded=1
> >
> > disconnect; reason=573 handle=2 our_ota_addr_type=0
> > our_ota_addr=01:02:03:04:05:06 our_id_addr_type=0
> > our_id_addr=01:02:03:04:05:06 peer_ota_addr_type=1
> > peer_ota_addr=cb:a9:42:31:30:30 peer_id_addr_type=1
> > peer_id_addr=cb:a9:42:31:30:30 conn_itvl=40 conn_latency=0
> > supervision_timeout=256 encrypted=1 authenticated=1 bonded=1
> >
> >
> > Thanks,
> >
> > Fred Angstadt
>
