Here's a config. It does not make bletiny crash, but it does return
corrupted adv data on scan (with BLE_EXT_ADV=1, more of the adv packet is
corrupted, which is probably why I was seeing crashes in my main app, while
without BLE_EXT_ADV i was only seeing data errors).

(simon/mynewt-1_2_0_rc1) ~>
$ newt target show bletiny
targets/bletiny
    app=@apache-mynewt-core/apps/bletiny
    bsp=@apache-mynewt-core/hw/bsp/rb-nano2
    build_profile=optimized

syscfg=BLE_EXT_ADV=1:BLE_MAX_CONNECTIONS=32:MSYS_1_BLOCK_COUNT=96:MSYS_1_BLOCK_SIZE=80

So it is likely the same problem as what is being discussed in the other
parallel thread.




On Wed, Sep 6, 2017 at 3:31 PM, Łukasz Rymanowski <
[email protected]> wrote:

> Hi Simon
>
> On 6 September 2017 at 23:27, Simon Ratner <[email protected]> wrote:
> > This doesn't seem to be the case.
> >
> > With hci event size of 70 and msys1 block size of 80, I get segfaults.
>
> I think we need some more information on your target and scenario
> because I just set same values (70, 80) for my bletiny app and don't
> get any crashes when doing scan or adv. Here is what I use:
>  app=@apache-mynewt-core/apps/bletiny
>     bsp=@apache-mynewt-core/hw/bsp/nrf52840pdk
>     build_profile=debug
>     syscfg=BLE_EXT_ADV=1:BLE_HCI_EVT_BUF_SIZE=70:BLE_HS_DEBUG=
> 1:BLE_L2CAP_COC_MAX_NUM=1:BLE_LL_CFG_FEAT_LE_2M_PHY=1:BLE_
> LL_CFG_FEAT_LE_CODED_PHY=1:BLE_MONITOR_DEBUG=0:BLE_
> MONITOR_RTT=1:BLE_SM_LEGACY=1:BLE_SM_SC=1:LOG_LEVEL=1:MSYS_
> 1_BLOCK_SIZE=80:STATS_CLI=1:STATS_NAMES=1
>
> > Increasing both to 274 works ok -- I'll try to track down the actual
> > minimum, but someone more familiar with the changes that went in may have
> > an easier time with that.
>
> Imho there should not be required any special minimum for the block
> size. I mean 80 should be fine to start with.
> When it comes to HCI event size, I believe in transport syscfg, there
> is dependency done on BLE_EXT_ADV flag and BLE_HCI_EVT_BUF_SIZE is
> reconfigured to the max size of extended advertising allowed as per
> BT5 spec.
>
> >
> >
> > On 6 Sep. 2017 08:52, "Łukasz Rymanowski" <[email protected]
> >
> > wrote:
> >
> >> Hi Simon
> >>
> >> On Sep 6, 2017 5:48 PM, "Simon Ratner" <[email protected]> wrote:
> >>
> >> Perfect, this will do.
> >>
> >> I assume I need to enable BLE_EXT_ADV for these. Is it safe to
> >> reduce BLE_HCI_EVT_BUF_SIZE back to 70 if I am not using large
> >> advertisements?
> >>
> >>
> >> It should be Ok.
> >>
> >>
> >>
> >> On 5 Sep. 2017 23:43, "Szymon Janc" <[email protected]> wrote:
> >>
> >> > Hi Simon,
> >> >
> >> > On 6 September 2017 at 05:33, Simon Ratner <[email protected]> wrote:
> >> > > Hi Szymon,
> >> > >
> >> > > I'd like to take you up on that offer of docs, or at least a
> pointer in
> >> > the
> >> > > right direction of where to find the new multi-adv hci commands.
> >> >
> >> > Those are standard HCI commands and events from Bluetooth Core Spec
> 5.0 :
> >> >  LE Set Advertising Set Random Address Command
> >> >  LE Set Extended Advertising Parameters Command
> >> >  LE Set Extended Advertising Data Command
> >> >  LE Set Extended Scan Response Data Command
> >> >  LE Set Extended Scan Response Data Command
> >> >  LE Advertising Set Terminated Event
> >> >  LE Scan Request Received Event
> >> >
> >> > All those have 'advertising handle' which allows to configure multiple
> >> > instances (with both legacy or Ext Advertising PDUs).
> >> > Note that spec seems to a bit unclear on what are allowed values for
> >> > advertising handle (as it seems to be configured from
> >> > host side) - currently in Mynewt allowed values for those are 0 to
> >> > MAX_ADVERTISING_INSTANCES.
> >> >
> >> > You can find helpers for constructing those from host in
> >> ble_hs_hci_priv.h
> >> >
> >> > --
> >> > pozdrawiam
> >> > Szymon K. Janc
> >> >
> >>
>

Reply via email to