Not sure about the advertising interval part but you can update the connection parameters using ble_gap_update_params() function. bletiny does have an example in case you would want to check that out. Also, after reading a bit, it seems that it’s up to the central whether to accept the connection parameters update or not. I have not tried it myself but would be a good solution if the central does not allow you to update parameters on creating a connection.
Also, it seems that the nordic DFU is very tightly knit with radio events which is not particularly a good idea in my opinion if there are multiple types of transports you want the upgrade protocol to work on. Regards, Vipul Rahane > On Apr 20, 2017, at 2:21 PM, Jacob Rosenthal <[email protected]> wrote: > > I think the default intervals are here, which should be sufficiently over > 20ms > /** 30 ms. */ > #define BLE_GAP_ADV_FAST_INTERVAL1_MIN (30 * 1000 / BLE_HCI_ADV_ITVL) > //48 > > /** 60 ms. */ > #define BLE_GAP_ADV_FAST_INTERVAL1_MAX (60 * 1000 / BLE_HCI_ADV_ITVL). > //96 > > /** 100 ms. */ > #define BLE_GAP_ADV_FAST_INTERVAL2_MIN (100 * 1000 / BLE_HCI_ADV_ITVL) > //160 > > /** 150 ms. */ > #define BLE_GAP_ADV_FAST_INTERVAL2_MAX (150 * 1000 / BLE_HCI_ADV_ITVL) > //240 > > or I can even force to the higher ones in bleprph: > > adv_params.itvl_min = BLE_GAP_ADV_FAST_INTERVAL2_MIN; > adv_params.itvl_max = BLE_GAP_ADV_FAST_INTERVAL2_MAX; > > But something is accepting itvl=9 (decimal I think?) which would be 6ish ms > and would be too low... > > 3960:[ts=30937440ssb, mod=4 level=1] GAP procedure initiated: advertise; > disc_mode=2 adv_channel_map=0 own_addr_type=0 adv_filter_policy=0 > adv_itvl_min=160 adv_itvl_max=240 adv_data_len=0 > 3964:[ts=30968688ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 > ocf=0x0006 len=15 > 3966:[ts=30984312ssb, mod=4 level=0] 0x06 0x20 0x0f 0xa0 0x00 0xf0 0x00 > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x07 0x00 > 3967:[ts=30992124ssb, mod=4 level=0] Command complete: cmd_pkts=1 ogf=0x8 > ocf=0x6 status=0 > 3969:[ts=31007812ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 > ocf=0x000a len=1 > 3971:[ts=31023436ssb, mod=4 level=0] 0x0a 0x20 0x01 0x01 > 3971:[ts=31023436ssb, mod=4 level=0] Command complete: cmd_pkts=1 ogf=0x8 > ocf=0xa status=0 > 4745:[ts=37070308ssb, mod=4 level=0] LE connection complete. handle=1 > role=1 paddrtype=0 addr=b8.e8.56.3.d3.ed local_rpa=0.0.0.0.0.0 > peer_rpa=0.0.0.0.0.0 itvl=9 latency=0 spvn_tmo=200 mca=5 > > > On Thu, Apr 20, 2017 at 1:57 PM, Jacob Rosenthal <[email protected]> > wrote: > >> I took out the interrupts and it the disconnect still happens actually. >> Random googling found this: >> https://devzone.nordicsemi.com/question/1183/nrf51822- >> flash-erase-error/?answer=1281#post-id-1281 >> >> "If you need to also erase pages while in a connection, you need to make >> sure the connection interval is sufficiently long for this to be possible, >> i.e. > 21 ms (most likely > (21 ms + some processing time)), and do the >> erase right after the radio event. The ble_radio_notification module from >> the SDK can be used to get a software interrupt both some time before and >> right after an event. If you have further questions on this, or can't get >> it working, it might make sense to post it as a separate question." >> >> <https://devzone.nordicsemi.com/users/580/olha/> >> In logs, interval advertises as adv_itvl_min=0 adv_itvl_max=0, on >> connection logs ive seen both itvl=9 and itvl=12, not sure what that maps >> to yet though.. >> >> >> >> On Thu, Apr 20, 2017 at 1:40 PM, Jacob Rosenthal <[email protected]> >> wrote: >> >>> Is it actually necessary to disable interrupts during the flash erase? >>> Seems like most hals do it, though maybe not the STM? >>> >> >> >>
