Correct, the version of openocd in homebrew does not work with nRF52. There
used to be a link to pre-built binaries that do work, but that link is gone
in the latest version of the docs. I have just run into this myself - no
idea why/when the docs were changed.
Compare:
018 at 12:30 AM Simon Ratner wrote:
> Hi devs,
>
> At some point between 1.3.0 and 1.4.1, the `newt` tool switched from using
> a relative path for the built image when passing it to `openocd`, to using
> an absolute path.
>
> This can be a problem for anyone running a mixed L
Hi devs,
I upgraded newt tool to 1.4.1 using apt, and now wish to downgrade back to
1.3.0 because reasons. However, it seems the previous versions have
disappeared from the apt source repo:
$ cat /etc/apt/sources.list.d/mynewt.list
deb
Hi devs,
At some point between 1.3.0 and 1.4.1, the `newt` tool switched from using
a relative path for the built image when passing it to `openocd`, to using
an absolute path.
This can be a problem for anyone running a mixed Linux/Windows environment
like cygwin or WSL; relative paths are
Ah yes, that would make a lot of sense :)
Probably because "core/net" sorts before "nimble".
On Thu, Mar 22, 2018 at 2:00 AM, Andrzej Kaczmarek <
andrzej.kaczma...@codecoup.pl> wrote:
>
> Anyway, it's always good to do newt clean after some major upgrade ;-)
>
>
Indeed :)
Heads up - make sure you clean your targets after upgrading.
For some reason the newt tool is unable to detect that the files have
changed, perhaps because they are at a new path; had fun debugging
exceptions in the data segment because of mismatched compilation units
Cheers,
simon
On Mar 16,
Is there a list of backwards-incompatible changes since 1.3.0 somewhere?
Things I am aware of:
- adv data mbufs are now consumed by nimble
- bsp code structure changes
- nimble repo changes
But it is the things that I missed from the list/commit log that concern
me, especially subtle semantic
Old thread, but I just bumped into this myself so want to resurrect it.
Current api makes it very difficult to implement a long characteristic that
changes frequently (e.g. time- or sensor-based reading, or including a
random component). In the case where mtu exchange fails or does not
complete
Hey devs,
I am seeing the number of available ble_gattc_proc structs in
ble_gattc_proc_pool dwindling over time, suspect they are not always being
freed (see bottom of the email for mpool output).
This seems to be happening under heavy client load, where a significant
fraction of the clients may
bio Utzig
>
> On Mon, Oct 30, 2017, at 10:17 PM, Simon Ratner wrote:
> > Hi devs,
> >
> > Has anyone looked at building core for a 64-bit target?
> >
> > Obviously there is a lot of code right now that relies on the target
> > platform being 32-bit, including
Hi devs,
Has anyone looked at building core for a 64-bit target?
Obviously there is a lot of code right now that relies on the target
platform being 32-bit, including the sim target (e.g. `os_mempool`). Any
guesses at the amount of effort that would be involved, at least for the
sim compiler /
100% compliant is fine in my
> mind for some learning/experimenting/tinkering use cases.
> >>>
> >>> Automated tests should/could be setup to help cover some of the well
> trodden and the corner cases, if not done already, sorry not checked or
> aware if they are a
Hi devs,
Controller code size went from 20k -> 29k with 1_2_0 and BLE_EXT_ADV,
compared to the old BLE_MULTI_ADV_SUPPORT. This happens to be just a bit to
big for our nrf51-based target.
Any suggestions on trimming it?
Would be great to disable the scanner extensions but keep the advertiser,
or
ing discussed in the other
parallel thread.
On Wed, Sep 6, 2017 at 3:31 PM, Łukasz Rymanowski <
lukasz.rymanow...@codecoup.pl> wrote:
> Hi Simon
>
> On 6 September 2017 at 23:27, Simon Ratner <si...@proxy.co> wrote:
> > This doesn't seem to be the case.
> >
> >
> MSYS_1_BLOCK_SIZE=80 by itself is not sufficient
Actually, it is sufficient, I was just setting it wrong.
On Wed, Sep 6, 2017 at 4:49 PM, Simon Ratner <si...@proxy.co> wrote:
> This actually works correctly with the default bletiny sysconfig.
> After a bit more digging, thi
no2
build_profile=optimized
syscfg=BLE_MAX_CONNECTIONS=32:MSYS_1_BLOCK_COUNT=96:MSYS_1_BLOCK_SIZE=80
Note that MSYS_1_BLOCK_SIZE=80 by itself is not sufficient to trigger the
problem, the other two values are needed as well. Not sure what's going on.
On Wed, Sep 6, 2017 at 10:24 AM, Simon Ratner
, there should probably be an assert somewhere if the stack
implicitly relies on some minimum memblock size.
On 6 Sep. 2017 08:52, "Łukasz Rymanowski" <lukasz.rymanow...@codecoup.pl>
wrote:
> Hi Simon
>
> On Sep 6, 2017 5:48 PM, "Simon Ratner" <si...@proxy.co>
length_data=31 data=0x1e:0xff:0x06:0x00:0x01:
0x09:0x20:0x00:0xd5:0x27:0x09:0x02:0xe2:0x4b:0x7d:0xf0:0xd8:
0xa6:0x95:0xa1:0x46:0xde:0x09:0xde:0x71:0x94:0x38:0xe9:0x74:0x19:0x00
The last three bytes of that packet should be "2a a7 30":
[image: Inline image 1]
On Wed, Sep 6, 2017 at 9:55 AM, Si
03 62 ad 26 4d ae 2a 00 01 04 0c
On Wed, Sep 6, 2017 at 9:24 AM, Simon Ratner <si...@proxy.co> wrote:
> Found the culprit, and it is something else - the adv packet data itself.
>
> scan: event_type=0 addr_type=1 addr=4b:41:99:63:b4:e4 uuids128=1
> (cc040100-2aae-4d26-ad62-03e9
) mfg_data_len=3
scan: event_type=4 addr_type=1 addr=4b:41:99:63:b4:e4 uuids128=0 ()
mfg_data_len=10
I see both types of reports, but note the uuid128: the first byte of it
appears to be corrupted (should be 0x03).
On Wed, Sep 6, 2017 at 8:43 AM, Simon Ratner <si...@proxy.co> wrote:
> In
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?
On 5 Sep. 2017 23:43, "Szymon Janc" <szymon.j...@codecoup.pl> wrote:
> Hi Simon,
>
> On 6 September 20
in unfair starving of other advertisers when it comes to grabbing
an HCI event?
On 5 Sep. 2017 23:57, "Andrzej Kaczmarek" <andrzej.kaczma...@codecoup.pl>
wrote:
Hi Simon,
On Wed, Sep 6, 2017 at 5:06 AM, Simon Ratner <si...@proxy.co> wrote:
>
> Hi devs,
>
> I am
July 2017 00:31:55 CEST Simon Ratner wrote:
> > Thanks for the heads-up, Szymon.
> > How does the bt5 implementation of "multiple advertising instances"
> relate
> > to the corresponding vendor extension that's currently in master?
>
> I should mention that i
Hi devs,
I am seeing a change in behaviour when performing active scan, compared to
pre-1.1. Previously, BLE_GAP_EVENT_DISC event would be reported for both
the original advertising packet (BLE_HCI_ADV_RPT_EVTYPE_ADV_IND), and the
scan response (BLE_HCI_ADV_RPT_EVTYPE_SCAN_RSP), in close
Never mind, upgrading newt tool to 1_2_0_dev did the trick (wasn't there a
warning at some point to tell us that the toolchain is outdated?)
On Tue, Sep 5, 2017 at 7:16 PM, Simon Ratner <si...@proxy.co> wrote:
> Got the following trying to build my app on 1.2 (moving from pre-1.1):
Got the following trying to build my app on 1.2 (moving from pre-1.1):
Error: Priority violations detected (Packages can only override settings
defined by packages of lower priority):
Package: net/nimble/controller overriding setting:
BLE_LL_CFG_FEAT_LE_CSA2 defined by net/nimble/controller
e best (imo)
>
>
> > On Sep 5, 2017, at 11:57 AM, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
> >
> > Hi,
> >
> > On Sep 5, 2017 8:15 PM, "Simon Ratner" <si...@proxy.co> wrote:
> >
> > On Tue, Sep 5, 2017 at 11:0
On Tue, Sep 5, 2017 at 11:01 AM, Łukasz Rymanowski <
lukasz.rymanow...@codecoup.pl> wrote:
>
> Note that this is how BLE works. Master sends LE Create Connection on
> Advertising event and assumes connection is created. In this point of time
> host gets Connection Complete Event according to BT
that is causing connection to not be established? I do see
this with both Android and iOS, for what it's worth (and both iOS10 and
iOS11). What would be an easy way for me to confirm?
On Tue, Sep 5, 2017 at 10:34 AM, Simon Ratner <si...@proxy.co> wrote:
> Indeed that would be an im
that cputime is counting at 1 MHz and not at 32.768kHz. Which also
> > implies that you are not using the latest code.
> >
> > NOTE: I would expect this to happen occasionally, and more occasionally
> if
> > there are alot of devices transmitting in close proximity or if t
tting in close proximity or if the two
> devices connecting dont have a great RF link.
>
> > On Sep 4, 2017, at 5:50 PM, Simon Ratner <si...@proxy.co> wrote:
> >
> > Hi devs,
> >
> > I am tracking a nimble issue (on nrf52) that seems to surface
&g
31 matches
Mail list logo
