Ok, so those two sound like they might be have the same cause. Perhaps related to that, I also stop receiving incoming connections after a short while, possibly for the same reason, although there is no indication in the logs or anywhere else on the mynewt side - the connecting central justsees a failed connection.
I am able to process all the advertisement reports just fine when I don't attempt to cancel discovery / connect to those discovered peripherals. Is it possible that cancellation is somehow causing or exacerbating this; for example some reports have already been received but are still being handled by the stack at the time discovery is cancelled, they are never reported to the app and corresponding buffers never freed? Just guessing here. I'll try increasing hci buffers, too. Do you have a recommended value for max_hci_buf? What about the mbuf size passed to ble_ll - is it at all correlated with host bufs, should they be allocated in certain ratios? On Mon, Jun 20, 2016 at 5:55 PM, chris collins <ch...@runtime.io> wrote: > Hi Simon, > > Unfortunately I am not able to reproduce that behavior. However, I think I > can answer one of your questions. Hopefully that will lead to a full > solution. > > That -1 return code is generated when the stack runs out of HCI command / > event buffers. The actual return code is a bug; BLE_HS_ENOMEM should > probably be returned instead. I am a bit puzzled about the cause of the > buffer shortage. You are probably receiving a lot of advertisement reports > from the controller, but I wouldn't expect them to be coming in faster than > you can handle them, but I suppose that depends on the particulars of your > application. You can try increasing the number of HCI buffers at host > initializtion time. This setting is in the host configuration struct, and > it is called max_hci_bufs. > > Regarding the second problem (ble_gap_conn_initiate() returns > BLE_HS_ETIMEOUT): I have a guess. The return code indicates that the > controller did not respond to an HCI command in a timely manner. My guess > is that the controller is unable to allocate an HCI buffer due to the > shortage. From looking at the code, it appears we don't have any > statistics indicating the number of times an HCI buffer failed to > allocate... this is definitely something that should be added. > > Chris > > On Mon, Jun 20, 2016 at 5:07 PM, Simon Ratner <si...@proxy.co> wrote: > > > Thanks Chris, just tried it out and it seems to do the trick -- half of > the > > time. > > > > I see two occasional errors: > > > > 1. Sometimes, ble_gap_disc_cancel returns (-1); any idea under what > > circumstances that might happen? > > > > 2. Sometimes, ble_gap_disc_cancel returns 0 but ble_gap_conn_initiate > > immediately afterwards fails with code 14 (ETIMEOUT? unless it's an hci > > error?). Is it possible that this is timing-related somehow and the link > > layer hasn't switched to the right state yet? Should i delay connect > > attempt for a tick? > > > > Both of these occur inconsistently; about half the time it just works. > > > > > > On Sat, Jun 18, 2016 at 10:21 PM, chris collins <ch...@runtime.io> > wrote: > > > > > Hi Simon, > > > > > > Thanks for the heads up; this is definitely an omission. You should be > > > able to cancel a scan in progress. > > > > > > Barring any unforeseen complications, the cancel functionality should > be > > > implemented in the develop branch tomorrow. This will allow the app > > cancel > > > the scan and initiate a connect procedure from within the advertising > > event > > > callback. > > > > > > Chris > > > > > > > > > On Sat, Jun 18, 2016 at 7:38 PM, Simon Ratner <si...@proxy.co> wrote: > > > > > > > Hi devs, > > > > > > > > Having initiated an undirected scan with ble_gap_disc(), I would like > > to > > > > connect to my peripheral as soon as I spot it in the scan callback. > > > > However, calling ble_gap_conn_initiate() at this point fails with > > > > BLE_HS_EALREADY, as ble_gap_master is still in discovery mode. I need > > to > > > > stash the discovered peripheral, wait for the scan to finish, and > then > > > try > > > > to connect, which is unnecessary state management. Additionally, > there > > > > doesn't seem to be a way to cancel the scan, so this becomes > especially > > > > problematic if the scan is long-running. > > > > > > > > For comparison, while advertising, an incoming connection > automatically > > > > drops the slave out of advertising mode (which can be resumed > > immediately > > > > if you have enough connection resources). > > > > > > > > Is this an omission, or by design? > > > > > > > > Cheers, > > > > simon > > > > > > > > > >
