Re: NimBLE controller on FreeRTOS and nRF52820

[Andrzej Kaczmarek]

Hi Mike,

Our porting layer doesn't fully support the NimBLE controller so we don't
officially support other platforms for that part. If you could share your
changes in some public repository I can take a look on what could be the
issue. Also, if you can make it running it would be great if you could then
upstream those changes just like RIOT OS guys did some time ago - that
would make it easier for other people to run it.

BR,
Andrzej



On Fri, 7 Jun 2024 at 19:25, Mike Redd  wrote:

>
> Hello,
>
> We are building a NimBLE controller on FreeRTOS and the Nordic nRF52820
> chip. (It communicates with a host over the HCI UART interface.) We have a
> reference build with MyNewt, which seems to work, but we are having
> difficulty with FreeRTOS. (We want to use FreeRTOS for compatibility with
> other parts of our application.)
>
> Hoping someone might have a clue
>
>  Using a BLE sniffer with MyNew, we get:
>
> [image: image.png]
> But with FreeRTOS we get:
>
> [image: image.png]
>
> Thanks in advance for any clues!
> --
> Mike Redd
>
> Principal Embedded Systems Engineer
>
> 801-317-8802
>
> mike.r...@prodatakey.com
>
> prodatakey.com 
> [image: Mike Redd] 
>

Re: [VOTE] Release Apache Mynewt 1.12.0-rc1 and Apache NimBLE 1.7.0-rc1

[Andrzej Kaczmarek]

+1



On Wed, 27 Mar 2024 at 14:56, Szymon Janc  wrote:

> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.12.0 and Apache NimBLE 1.7.0.
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> Apache NimBLE is Bluetooth Low Energy 5.4 stack from Apache Mynewt.
>
> This release is coordinated release of Apache Mynewt and NimBLE. Future
> NimBLE releases may be released separately depending on needs.
>
> For full release notes for both Mynewt and NimBLE, please visit the Apache
> Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> Apache Mynewt and Apache NimBLE release candidates were tested as follows:
>   1. Manual execution of the Mynewt test plan:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
>  The test results can be found at:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/1.12.0+Test+Results
>   2. Manual execution of the NimBLE test plan:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+NimBLE+Test+Plan
>  The test results can be found at:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/NimBLE+1.7.0+Test+Results
>
>  Note that this testing is not yet complete and more results will show
> while
>  voting is ongoing.
>
>   2. The full unit test suite for both releases was executed via "newt
> test all"
>  with no failures. This testing was performed on the following
> platforms:
>* Fedora Linux 38
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.12.0/rc1/
> https://dist.apache.org/repos/dist/dev/mynewt/apache-nimble-1.7.0/rc1/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit 2c2d990a96541a9688a5f0d5b5005ed37c6cd082
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit c95f54c3e7a90005e54e27c225fee89294b4b2f7
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit 3a5cfeb31a36847f727f77046cd52cdeb177029c
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 2462905c1ba4542676592bdb2a5df4d5e441b153
> nimble:
>   repos: https://github.com/apache/mynewt-nimble
>   commit 675452b62822efd3e3fd28ac55eb166baf8461f4
>
> In addition, the following newt and newtmgr convenience binaries are
> available:
>   linux:
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.12.0/rc1/apache-mynewt-newt-bin-linux-1.12.0.tgz
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.12.0/rc1/apache-mynewt-newtmgr-bin-linux-1.12.0.tgz
>
>   osx:
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.12.0/rc1/apache-mynewt-newt-bin-osx-1.12.0.tgz
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.12.0/rc1/apache-mynewt-newtmgr-bin-osx-1.12.0.tgz
>
>   windows:
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.12.0/rc1/apache-mynewt-newt-bin-windows-1.12.0.tgz
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.12.0/rc1/apache-mynewt-newtmgr-bin-windows-1.12.0.tgz
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon K. Janc
>
>
>

Re: [VOTE] Release Apache Mynewt 1.11.0-rc1 and Apache NimBLE 1.6.0-rc1

[Andrzej Kaczmarek]

+1 (binding)


On Fri, 11 Aug 2023 at 13:07, Szymon Janc  wrote:

> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.11.0 and Apache NimBLE 1.6.0.
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> Apache NimBLE is Bluetooth Low Energy 5.4 stack from Apache Mynewt.
>
> This release is coordinated release of Apache Mynewt and NimBLE. Future
> NimBLE releases may be released separately depending on needs.
>
> For full release notes for both Mynewt and NimBLE, please visit the Apache
> Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> Apache Mynewt and Apache NimBLE release candidates were tested as follows:
>   1. Manual execution of the Mynewt test plan:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
>  The test results can be found at:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/1.11.0+Test+Results
>   2. Manual execution of the NimBLE test plan:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+NimBLE+Test+Plan
>  The test results can be found at:
>
>
> https://cwiki.apache.org/confluence/display/MYNEWT/NimBLE+1.6.0+Test+Results
>
>  Note that this testing is not yet complete and more results will show
> while
>  voting is ongoing.
>
>   2. The full unit test suite for both releases was executed via "newt test
> all"
>  with no failures. This testing was performed on the following
> platforms:
>* Fedora Linux 38
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/
> https://dist.apache.org/repos/dist/dev/mynewt/apache-nimble-1.6.0/rc1/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit 223f0b3f8859c77cc0a41038a21e8d0f348e992e
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit 6de871dfa7306a06df4219470205af69c569c0d9
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit 2215fc6201d7c7c376b9d6733bd35a10b5691aae
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 5086b90977bc0782b1f36eaebacabeb694d19cb5
> nimble:
>   repos: https://github.com/apache/mynewt-nimble
>   commit df0718d7eacf414b2f4ed1e28f866250d92cadcb
>
> In addition, the following newt and newtmgr convenience binaries are
> available:
>   linux:
>
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newt-bin-linux-1.11.0.tgz
>
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newtmgr-bin-linux-1.10.0.tgz
> <
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newtmgr-bin-linux-1.11.0.tgz
> >
>
>   osx:
>
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newt-bin-osx-1.11.0.tgz
>
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newtmgr-bin-osx-1.11.0.tgz
>
>   windows:
>
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newt-bin-windows-1.11.0.tgz
>
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.11.0/rc1/apache-mynewt-newtmgr-bin-windows-1.11.0.tgz
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon K. Janc
>

Re: MyNewt NimBLE Issue

[Andrzej Kaczmarek]

Hi Arden,

On Thu, 29 Jun 2023 at 02:32, Arden Kolodner 
wrote:

> Hello! I’m having an issue with NimBLE (but not any other BLE stack) on my
> ESP32-S3 device. I submitted an issue on GitHub but didn’t hear anything
> back, and I just found out about this email, so I thought I’d ask here too
> in case someone has seen anything like this before.
>
> I have an ESP32S3 connecting via BLE to multiple MbientLab MetaMotionS <
> https://mbientlab.com/metamotions/> devices. The BLE client on the ESP32
> subscribes to a characteristic on each device, which is supposed to send a
> notification update at 100Hz. This works fine when using Bluedroid, but
> unfortunately Bluedroid causes other problems down the line and we want to
> switch to NimBLE.
>
> However, for some reason, when using NimBLE, most of the notifications
> from all devices except the last one are dropped. Each time a new device is
> connected, the device that was previously the most recent connection
> suddenly develops this problem, in addition to all previous ones. Only
> about 10% of the notifications go through, which is far too few for our use
> case.
>
> We found that lowering the min and max connection interval made more of
> the notifications go through, but still not most, even when trying the max
> value.
>
> Oddly enough, setting the connection parameters will reverse the issue:
> the first connected device will now be the fast one, and the others,
> including the last one, will be slow. This seems to be the case even if I
> set the connection interval to a very large value, instead of very small,
> and even happened sometimes when I set invalid connection parameters and
> got an 0x0212 HCI error. So maybe it’s not the actual parameter values that
> are affecting anything, but some side effect?
>
> Since the issue doesn't occur with Bluedroid, and nothing else is changed,
> the problem seems like it must be with NimBLE.
>
> Does anybody know why this problem occurs or how to fix it?
>

If there's anything wrong with the host stack it's likely the controller
that triggers it since I cannot see why changing connection parameters
would affect connection handling in the host stack. The best would be to
have capture from a BLE sniffer so we can take a look at what's happening
over the air. If not possible, then at least HCI logs from central side
(i.e. ESP, I assume) in some easily readable format like btsnoop. Also
corresponding logs from Bluedroid would also be nice to compare.


> Note: we use NimBLE through the esp-nimble-cpp library, but this seems
> unlikely to be the issue since it just provides an interface for BLE
> connection and callbacks just immediately call our code.
>
> Thank you very much for your time.


BR,
Andrzej

Re: [VOTE] Release Apache Mynewt 1.10.0-rc1 and Apache NimBLE 1.5.0-rc1

[Andrzej Kaczmarek]

gt; > > >
> > > > > In addition, the following newt and newtmgr convenience binaries
> are
> > > > > available:
> > > > >   linux:
> > > > >
> > > > >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newt-bin-linux-1.10.0.tgz
> > > > >
> > > > >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newtmgr-bin-linux-1.10.0.tgz
> > > > >
> > > > >   osx:
> > > > >
> > > > >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newt-bin-osx-1.10.0.tgz
> > > > >
> > > > >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newtmgr-bin-osx-1.10.0.tgz
> > > > >
> > > > >   windows:
> > > > >
> > > > >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newt-bin-windows-1.10.0.tgz
> > > > >
> > > > >
> >
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newtmgr-bin-windows-1.10.0.tgz
> > > > >
> > > > > The release candidate is signed with a GPG key available at:
> > > > > https://dist.apache.org/repos/dist/dev/mynewt/KEYS
> > > > >
> > > > > The vote is open for at least 72 hours and passes if a majority of
> at
> > > > > least three +1 PMC votes are cast.
> > > > >
> > > > > [ ] +1 Release this package
> > > > > [ ]  0 I don't feel strongly about it, but don't object
> > > > > [ ] -1 Do not release this package because...
> > > > >
> > > > > Anyone can participate in testing and voting, not just committers,
> > > > > please feel free to try out the release candidate and provide your
> > > > > votes.
> > > > >
> > > > > A separate [DISCUSS] thread will be opened to talk about this
> release
> > > > > candidate.
> > > > >
> > > > > --
> > > > > pozdrawiam
> > > > > Szymon Janc
> > > >
> > > >
> > > >
> > > > --
> > > > pozdrawiam
> > > > Szymon K. Janc
> >
> --
>
> Regards,
> Vipul Rahane
>


-- 
pozdrawiam,
Andrzej Kaczmarek

Re: programming the net core on the nrf5340 dk

[Andrzej Kaczmarek]

Hi,

On Thu, 17 Mar 2022 at 21:16, manish  wrote:
>
(...)
>
> Also, perhaps the nordic_pca10095_net  bsp syscfg.yml has a bug.
> BLE_TRANSPORT_NETCORE:  1   should be under syscfg.vals instead of
> syscfg.defs .

The definition in syscfg.yml is correct, but you'll need to use newt
built from the latest master branch to handle it properly.

Best regards,
Andrzej

Re: HCI mode firmware upgrading

[Andrzej Kaczmarek]

Hi Alan,

On Tue, Jan 19, 2021 at 12:39 AM Alan Graves 
wrote:

> Hi all,
>
> Just wondering if anyone has insights they could share on how I might be
> able to implement an upgrade procedure for a BLE Device running HCI mode
> firmware?
>
> The following is basically what I have to work with:
>
> * The Device programmed during manufacturing with a JTAG
> programmer.
>
> * The nRF52832 based Device I'm using will be running the HCI mode
> firmware and connected to an embedded Alpine Linux Host over a UART
> connection with full hardware RTS/CTS handshaking support.
>
> * Once the Device is out in the field I need to be able to
> reprogram from the Host side via the same UART the HCI mode protocol is
> using.
>
> Also there a few caveats that I have to adhere to:
>
> * Obviously the JTAG on the Device is not available out in the
> field.
>
> * Here is no HOST hardware GPIO signal available to signal to the
> Device that it should wait for new firmware.
>
> * OTA upgrades to the Device are not permitted.
>
>
> I believe that this only leaves a few UART options open to the Host to
> initiate the Device firmware upgrade:
>
> 1.   Host issues a custom HCI command to write a 'magic' number to a
> special Nordic chip register, then does a software reset of the Device.
>
> 2.   Host does a software reset of the Device and sends a trigger
> string over the UART during the Bootloader startup.
>

Those would be probably easiest to implement. If you use bootloader then
there's already support for upgrade over serial so all you need is a way to
do a soft reset of a device (HCI Reset does only restart LL). This can be
done by implementing vendor specific command which is quite simple. Then,
after reset bootloader can either wait for some predefined string to appear
on UART or NV registers can be used to enter DFU mode - IIRC MCUBoot
supports both.


> 3.   There is no Device Bootloader used and the HCI mode firmware has
> the firmware upgrade support built-in.
>

That is also possible, although we do not have any code to do this so you'd
need to write it from scratch, i.e. add some vendor specific HCI commands
to transfer new firmware and then restart.


> 4.   ...
>
> Any help on this problem would be much appreciated.
>
> Thanks,
> ALan
>
>
Best,
Andrzej

NimBLE controller on Dialog DA1469x MCU

[Andrzej Kaczmarek]

 
Hi,

I've just pushed PRs that enable NimBLE controller on Dialog DA1469x MCU
family:
https://github.com/apache/mynewt-core/pull/2368
https://github.com/apache/mynewt-nimble/pull/859
That's right: no more binaries, you can now run a full NimBLE controller
with all supported features on Dialog MCU.

I will not explain how this works here since it's really lots of code that
we wrote together with Will, so those interested in more technical details
should just check commits and source code (there are comments included!).
And those who just want to give it a try, here's simple target to run
bleprph on DA1469x DK:

targets/da1469x_bleprph
app=@apache-mynewt-nimble/apps/bleprph
bsp=@apache-mynewt-core/hw/bsp/dialog_da1469x-dk-pro
build_profile=debug
syscfg=BLE_HCI_TRANSPORT=dialog_cmac

You only need to build and flash a single image for DA1469x - controller
side is built and packaged automatically into application image.

For now you will also need to manually set device address in syscfg (or
modify bleprph to set static random one), check
targets/dialog_cmac/syscfg.yml in nimble repo for details.

You can find more information about required setup and configuration in
README found in nimble/drivers/dialog_cmac directory.

Best,
Andrzej

Re: Memory leak with timers on FreeRTOS

[Andrzej Kaczmarek]

Hi,

The fix should only skip creating a new timer, but it still should
initialize other fields in the callout struct since some code may need to
initialize the same callout with e.g. different callback for an event (no
idea if we use it like this anywhere).
As for the issue itself, the code can be modified so callout is initialized
only once (on init) since it's always initialized with the same values -
this happens in other places in code as well iirc so it can be improved.
Patches are welcome :-)

Best,
Andrzej



On Sat, Jul 11, 2020 at 3:59 PM  wrote:

> I'm sorry to bump this message, but I would be very interested in your
> opinion on this issue, and on the fix I applied in
> npl_freertos_callout_init(). It seems to work fine, but I don't know if
> it can produce bad side effects...
>
> Thanks!
>
> Le 04/07/2020 20:32, j...@codingfield.com a écrit :
> > Hi,
> >
> > I'm still working on my firmware for Pinetime! Thanks to your help a
> > couple of weeks ago, BLE connectivity is now much more reliable.
> > As a remainder, I work on a firmware based on FreeRTOS and running on
> > the NRF52 MCU. It uses NimBLE as BLE stack. I use the FreeRTOS port
> > available in the source tree
> > (https://github.com/apache/mynewt-nimble/tree/master/porting/npl).
> >
> > However, I noticed that my code would crash after a certain number of
> > connections/disconnections. I noticed that use of the heap memory
> > allocated to FreeRTOS would grow by ~100 bytes each time a new
> > connection is established and this memory is never released.
> >
> > I discovered that this memory is used by 2 timers (mynewt "callouts")
> > that are created in npl_freertos_callout_init(). This function calls
> > xTimerCreate() which allocates the memory necessary for the timer.
> > This memory is taken from the heap allocated for FreeRTOS.
> > When the connection is closed, xTimerDelete() is never called meaning
> > that the memory is not freed.
> > When a new device connects, 2 new timers are created, allocating ~100B
> > from the heap. This continues until the heap is full and refuses to
> > give any more memory.
> > Note that I use heap_4.c, which allows memory to be allocated and
> > freed.
> >
> > To my surprise, there is NO function npl_freertos_callout_uninit() or
> > npl_freertos_callout_delete() or anything else. It looks like timers
> > (callouts) are not intended to be removed once they are created.
> > Should they be reused/recycled?
> >
> > Anyway, I modified the function npl_freertos_callout_init() so that it
> > does nothing if the handle is not NULL and... it looks like it works
> > (even if I don't think this is a valid fix):
> >
> > void npl_freertos_callout_init(struct ble_npl_callout *co, struct
> > ble_npl_eventq *evq,
> >  ble_npl_event_fn *ev_cb, void *ev_arg)
> > {
> > if(co->handle != NULL) return;  // < I added this line.
> >
> > memset(co, 0, sizeof(*co));
> > co->handle = xTimerCreate("co", 1, pdFALSE, co,
> > os_callout_timer_cb);
> > co->evq = evq;
> > ble_npl_event_init(&co->ev, ev_cb, ev_arg);
> >
> > }
> >
> > Is this a bug that must be fixed in the source code or am I missing
> > something about the creation and deletion of timers?
> >
> > Thanks for your help,
> >
> > JF
>

Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze

[Andrzej Kaczmarek]

Hi,

Your changes look good, I think it should work just fine.
Just fyi, in theory you could use basepri with NimBLE controller if you set
radio irq priority to 1 and lower any other priorities below that one.
However, this requires extra care to make sure there are no irqs set to
priority 0 since we really want radio irq to have the lowest latency
possible. So unless you really need some irqs to be enabled all the time,
using primask instead of basepri is a simpler option imo.

Best,
Andrzej



On Fri, Jun 19, 2020 at 10:23 PM  wrote:

> Hi,
>
> And thanks Andrzej for this advanced analysis of my code! I've never dug
> this deep in FreeRTOS and ARM interrupts, so, I did some researches.
>
> If I understand correctly, BASEPRI allows to mask all interrupts with a
> priority lower than the value of the register, while PRIMASK masks all
> the interrupts.
> Using PRIMASK is slower (and induce a higher IRQ lantency) but BASEPRI
> does not allow to mask IRQ 0, which is needed by nimble to mask the
> radio IRQ. Am I right?
>
> So, I found out that port of FreeRTOS for Cortex-M4 uses BASEPRI
> (because it's faster) and, as BASEPRI is not available on Cortex-M0, the
> port for Cortex-M0 uses PRIMASK.
> Then, I tried to change the macro portENABLE_INTERRUPTS() and
> portDISALE_INTERRUPTS from
>
> #define portDISABLE_INTERRUPTS()vPortRaiseBASEPRI()
> #define portENABLE_INTERRUPTS() vPortSetBASEPRI(0)
>
> to (code from Cortex-M0 port):
>
> #define portDISABLE_INTERRUPTS()__asm volatile  ( "
> cpsid i " ::: "memory" )
> #define portENABLE_INTERRUPTS() __asm volatile  ( "
> cpsie i " ::: "memory" )
>
> and... connection from Android seems to be a lot more reliable! And the
> rest of the application seems to work correctly.
>
> Do you think my modification is complete and safe? I don't think
> interrupt latency will be a big deal in my application.
>
> Thanks a lot for your help!
>
> Le 19/06/2020 14:20, Andrzej Kaczmarek a écrit :
> > Hi,
> >
> > I just quickly looked through the code and it seems that your FreeRTOS
> > port
> > uses basepri for critical sections. The problem here is that radio irq
> > has
> > priority 0 so it cannot be blocked by basepri, that's one reason why
> > NPL
> > uses primask for its own macros. One function that can be affected in
> > particular is npl_freertos_eventq_remove() which uses FreeRTOS calls to
> > enter critical section so if some corner case it can be called from
> > both
> > ISR and task context messing up queue contents, although other calls
> > may
> > have the same problem due to basepri usage in general. That could
> > explain
> > problems which appear only in certain build configurations since they
> > are
> > triggered by timing.
> >
> > Best,
> > Andrzej
> >
> >
> >
> > On Wed, Jun 17, 2020 at 9:05 PM  wrote:
> >
> >> Hi,
> >>
> >> I use the init functions found in porting/nimble and
> >> porting/npl/freertos. There are functions to handle semaphores,
> >> queues,
> >> timers,... Is there any issue with this freertos port, if it's not
> >> official? I did not write any code related to the radio or irq as it
> >> seems to be handled by these functions.
> >>
> >> Here is the function I call in my main() to init nimble:
> >>
> >> void nimble_port_init(void) {
> >>void os_msys_init(void);
> >>void ble_store_ram_init(void);
> >>ble_npl_eventq_init(&g_eventq_dflt);
> >>os_msys_init();
> >>ble_hs_init();
> >>ble_store_ram_init();
> >>
> >>int res;
> >>res = hal_timer_init(5, NULL);
> >>ASSERT(res == 0);
> >>res = os_cputime_init(32768);
> >>ASSERT(res == 0);
> >>ble_ll_init();
> >>ble_hci_ram_init();
> >>nimble_port_freertos_init(BleHost);
> >> }
> >>
> >> And BleHost():
> >>
> >> void BleHost(void *) {
> >>struct ble_npl_event *ev;
> >>
> >>while (1) {
> >>  ev = ble_npl_eventq_get(&g_eventq_dflt, BLE_NPL_TIME_FOREVER);
> >>  ble_npl_event_run(ev);
> >>}
> >> }
> >>
> >> If you want to have a look at the complete code, it's hosted on
> >> Github.
> >> main() is in src/main.cpp, the nimble is in src/libs/mynewt-nimble :
> >> https://github.com/JF002/Pinetime
> >>
> >> Is there anyth

Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze

[Andrzej Kaczmarek]

Hi,

I just quickly looked through the code and it seems that your FreeRTOS port
uses basepri for critical sections. The problem here is that radio irq has
priority 0 so it cannot be blocked by basepri, that's one reason why NPL
uses primask for its own macros. One function that can be affected in
particular is npl_freertos_eventq_remove() which uses FreeRTOS calls to
enter critical section so if some corner case it can be called from both
ISR and task context messing up queue contents, although other calls may
have the same problem due to basepri usage in general. That could explain
problems which appear only in certain build configurations since they are
triggered by timing.

Best,
Andrzej



On Wed, Jun 17, 2020 at 9:05 PM  wrote:

> Hi,
>
> I use the init functions found in porting/nimble and
> porting/npl/freertos. There are functions to handle semaphores, queues,
> timers,... Is there any issue with this freertos port, if it's not
> official? I did not write any code related to the radio or irq as it
> seems to be handled by these functions.
>
> Here is the function I call in my main() to init nimble:
>
> void nimble_port_init(void) {
>void os_msys_init(void);
>void ble_store_ram_init(void);
>ble_npl_eventq_init(&g_eventq_dflt);
>os_msys_init();
>ble_hs_init();
>ble_store_ram_init();
>
>int res;
>res = hal_timer_init(5, NULL);
>ASSERT(res == 0);
>res = os_cputime_init(32768);
>ASSERT(res == 0);
>ble_ll_init();
>ble_hci_ram_init();
>nimble_port_freertos_init(BleHost);
> }
>
> And BleHost():
>
> void BleHost(void *) {
>struct ble_npl_event *ev;
>
>while (1) {
>  ev = ble_npl_eventq_get(&g_eventq_dflt, BLE_NPL_TIME_FOREVER);
>  ble_npl_event_run(ev);
>}
> }
>
> If you want to have a look at the complete code, it's hosted on Github.
> main() is in src/main.cpp, the nimble is in src/libs/mynewt-nimble :
> https://github.com/JF002/Pinetime
>
> Is there anything specific I should check?
>
> Thanks,
>
> JF
>
>
> Le 17/06/2020 10:35, Andrzej Kaczmarek a écrit :
> > Hi,
> >
> > How did you setup interrupts on FreeRTOS (e.g. radio) and critical
> > section?
> > These kinds of problems are common if you have misconfigured locking,
> > interrupt priorities or smth. Since we do not have any official port
> > for
> > FreeRTOS (there's only NPL but it does not deal with hardware) I assume
> > you
> > did this on your own so would be good to know more details.
> >
> > Best,
> > Andrzej
> >
> >
> > On Tue, Jun 16, 2020 at 8:29 PM  wrote:
> >
> >> Hi,
> >>
> >> I was able to do more tests using BLE_MONITOR_RTT and btmon.
> >> Here are 3 captures from 2 phones (nexus 5 and huawei). The one from
> >> the
> >> Nexus contains 3 successful connections followed by a failed one. Both
> >> from nexus only contain 1 failed attempt. For each test, you'll find
> >> the
> >> output of btmon and the capture from wireshark.
> >> The files are available here :
> >> https://seafile.codingfield.com/d/3e17cb3f43da4eedaefd/
> >>
> >> Note that I observed that the connection is more often successful when
> >> BLE_MONITOR_RTT is enabled than when it is disabled. Remember it was
> >> the
> >> same with Debug/Release : there are more successful connections in
> >> Debug
> >> than in Release.
> >> It makes me think of a timing issue, but it's weird that it works
> >> better
> >> when the code is supposed to run slower...
> >>
> >> I hope you'll be able to make sense of these captures!
> >>
> >> Thanks for your help!
> >>
> >> JF
> >>
> >>
> >> Le 15/06/2020 22:54, j...@codingfield.com a écrit :
> >> > Hi,
> >> >
> >> > Sorry, I do not mean to spam this mailing list. I just wanted to say I
> >> > misread the article, and manage to use the monitor over RTT. I build
> >> > the tool rtt2pty, ran it and then launched "btmon -J nrf52" and I see
> >> > very detailed logs about BLE communication!
> >> >
> >> > It's running late, I'll analyze them tomorrow evening.
> >> >
> >> > Thanks for your help, and sorry for the spam :)
> >> >
> >> > JF
> >> >
> >> > Le 15/06/2020 22:25, j...@codingfield.com a écrit :
> >> >> Hi again,
> >> >>
> >> >> Ok, I had a look to BLE_MONITOR_RTT, but I can&#

Re: Nimble on NRF52 : connectivity issue with Android, stack seems to freeze

[Andrzej Kaczmarek]

Hi,

How did you setup interrupts on FreeRTOS (e.g. radio) and critical section?
These kinds of problems are common if you have misconfigured locking,
interrupt priorities or smth. Since we do not have any official port for
FreeRTOS (there's only NPL but it does not deal with hardware) I assume you
did this on your own so would be good to know more details.

Best,
Andrzej


On Tue, Jun 16, 2020 at 8:29 PM  wrote:

> Hi,
>
> I was able to do more tests using BLE_MONITOR_RTT and btmon.
> Here are 3 captures from 2 phones (nexus 5 and huawei). The one from the
> Nexus contains 3 successful connections followed by a failed one. Both
> from nexus only contain 1 failed attempt. For each test, you'll find the
> output of btmon and the capture from wireshark.
> The files are available here :
> https://seafile.codingfield.com/d/3e17cb3f43da4eedaefd/
>
> Note that I observed that the connection is more often successful when
> BLE_MONITOR_RTT is enabled than when it is disabled. Remember it was the
> same with Debug/Release : there are more successful connections in Debug
> than in Release.
> It makes me think of a timing issue, but it's weird that it works better
> when the code is supposed to run slower...
>
> I hope you'll be able to make sense of these captures!
>
> Thanks for your help!
>
> JF
>
>
> Le 15/06/2020 22:54, j...@codingfield.com a écrit :
> > Hi,
> >
> > Sorry, I do not mean to spam this mailing list. I just wanted to say I
> > misread the article, and manage to use the monitor over RTT. I build
> > the tool rtt2pty, ran it and then launched "btmon -J nrf52" and I see
> > very detailed logs about BLE communication!
> >
> > It's running late, I'll analyze them tomorrow evening.
> >
> > Thanks for your help, and sorry for the spam :)
> >
> > JF
> >
> > Le 15/06/2020 22:25, j...@codingfield.com a écrit :
> >> Hi again,
> >>
> >> Ok, I had a look to BLE_MONITOR_RTT, but I can't figure out how to
> >> enable it in my code (which does not use mynewt as RTOS) : at first,
> >> the code did not compile. I tried to fix the compilation errors (for
> >> example, I had to define struct File_methods and struct File).
> >> Then, I built the code, but couldn't see any messages coming out of
> >> JLinkRTTClient.
> >>
> >> It is supposed to work with JLinkRTTClient, or do I need to use
> >> btshell running on another nrf board? (I do not have a nrf52840 on
> >> hands...).
> >>
> >> By the way, I already use the RTT for logging, and manage to enable
> >> some loggers some nimble. Are the same messages available using the
> >> logger, or do I really need bt_monitor?
> >>
> >> Thx!
> >>
> >> JF
> >>
> >> Le 15/06/2020 20:38, j...@codingfield.com a écrit :
> >>> Hi,
> >>>
> >>> The ACK you're talking about, are they the "Rcvd Read" listed in the
> >>> capture?
> >>>
> >>> If BLE_MONITOR_RTT means that nimble supports JLink RTT, then yes, I
> >>> have a console available. I'll try to enable it. I'll also have a
> >>> look
> >>> at the stats and how to use them.
> >>>
> >>> Thanks for the pointers, I'll report to you as soon as I have more
> >>> information!
> >>>
> >>> JF
> >>>
> >>> Le 14/06/2020 23:18, Łukasz Rymanowski a écrit :
>  Hi,
> 
>  so indeed your logs show that after trying to read include services
>  from
>  GATT service, something bad happened. Controller was able to ACK 2
>  following master packets then it stopped to send ACKs.
>  Do you have a console available? If so, does it show anything
>  interesting?
> 
>  For further debugging I suggest to look at BLE_MONITOR_RTT to grab
>  hci logs
>  (https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/)
>  With this we will know if response is still in the host or is in the
>  controller.
> 
>  Then we could check some stats e.g. ble_ll_stats - maybe that could
>  show us
>  something interesting - but first let us see where it stuck.
> 
>  Best
>  Łukasz
> 
>  On Sun, 14 Jun 2020 at 21:06,  wrote:
> 
> > Hi,
> >
> > It looks like the attachements were dropped somewhere... You can
> > download them on my seafile instance :
> > https://seafile.codingfield.com/d/64d53a6ca6b44ae6b5d7/
> >
> > It seems to fail during the discovery of the characteristics on the
> > device. From what I understand, it happens during the discovery of
> > Generic Access Profile and Generic Attributes Profile, which are
> > handled
> > by nimble.
> > I may be wrong, I'm a beginner with BLE and nimble!
> > Maybe the captures will make more sens to you?
> >
> > Yeah, it's very strange that it works when the code is supposed to
> > run
> > slower... It makes me think of a timing or memory issue, but I
> > couldn't
> > find it...
> >
> > Thanks,
> > JF
> >
> > Le 14/06/2020 20:46, Łukasz Rymanowski a écrit :
> > > Hi,
> > >
> > > Thanks for the report, however looks like attachments are 

Re: nimble doesn't receive 31B scan response

[Andrzej Kaczmarek]

Hi,

Yes, it will scan only once - this is allowed by spec. I think for testing
you could try to remove the call to "ble_ll_scan_have_rxd_scan_rsp" from
"ble_ll_scan_send_scan_req" and it should scan everything unless you'll run
out of HCI buffers.

Best,
Andrzej


On Tue, May 12, 2020 at 8:17 PM Ondrej Pilat 
wrote:

> Hi,
>
> does nimble ask for the scan response only once? It looks that it was
> fault in our code and cheap sniffer doesn't catch it :(.
>
> Regards
>
> Ondrej
> Dne 5/12/2020 v 4:51 PM Andrzej Kaczmarek napsal(a):
>
> Hi,
>
> On Tue, May 12, 2020 at 4:05 PM Ondrej Pilat 
> wrote:
>
>> Hi All,
>>
>> we have device which in the past had 29B scan response and nimble
>> properly asked for it. Now We extended scan response at 31B to use it whole
>> but now nimble doesn't ask for it. No ble_gap_disc_desc *disc with
>> disc->event_type === BLE_HCI_ADV_RPT_EVTYPE_SCAN_RSP for our device.
>>
> The scanner cannot decide whether to send a scan request or not based on
> the length of the scan response because it does not know that length in
> advance. Did you really see that NimBLE does not send a scan request to
> your device? Could be simply that your device does not send a scan response
> or there's something wrong (configuration?) with advertising packets. The
> best would be if you could provide some logs (HCI, air, etc.) that would
> show us how advertising is configured on your device and how the scanner is
> configured in NimBLE.
>
>> Where can be an issue? Does nimble support 31B scan response?
>>
> Yes, it's required by spec.
>
>> Regards
>>
>> Ondrej
>>
> Best,
> Andrzej
>
>
>> --
>>
>
> --
>

Re: nimble doesn't receive 31B scan response

[Andrzej Kaczmarek]

Hi,

On Tue, May 12, 2020 at 4:05 PM Ondrej Pilat 
wrote:

> Hi All,
>
> we have device which in the past had 29B scan response and nimble properly
> asked for it. Now We extended scan response at 31B to use it whole but now
> nimble doesn't ask for it. No ble_gap_disc_desc *disc with disc->event_type
> === BLE_HCI_ADV_RPT_EVTYPE_SCAN_RSP for our device.
>
The scanner cannot decide whether to send a scan request or not based on
the length of the scan response because it does not know that length in
advance. Did you really see that NimBLE does not send a scan request to
your device? Could be simply that your device does not send a scan response
or there's something wrong (configuration?) with advertising packets. The
best would be if you could provide some logs (HCI, air, etc.) that would
show us how advertising is configured on your device and how the scanner is
configured in NimBLE.

> Where can be an issue? Does nimble support 31B scan response?
>
Yes, it's required by spec.

> Regards
>
> Ondrej
>
Best,
Andrzej


> --
>

Re: BLE communication scheduling

[Andrzej Kaczmarek]

One correction...

On Tue, Apr 14, 2020 at 11:31 AM Andrzej Kaczmarek <
andrzej.kaczma...@codecoup.pl> wrote:
(...)

> You need to take NimBLE scheduling into account here. Each connection
> event is preallocated a fixed amount of time in 1250us slots - see
> BLE_LL_CONN_INIT_SLOTS. This means effectively connection events cannot be
> scheduled less than 1250us apart. Also, scheduler overhead is ~200us (for
> nRF52, may be different for nRF51) for each connection event so effective
> connection event time with 1 slot allocated is 1050us. Note that this is
> min time since connection events can be extended pretty much indefinitely
> as long as there is no other activity scheduled so e.g. until another
> connection event.
>
(...)

> I do not know if "20B packet" means "20 bytes of LL payload", but will
> assume so since we are talking LL level here. This can fit into a single
> scheduled slot: 240us + 150us + 80us = 470us < 1050us. Let's assume 1ms for
> each connection event including scheduler overhead so you need 18ms to
> serve all 18 devices in one direction.
>

Obviously 18ms is not a proper number since we need to count it as 1.25ms
slots mentioned earlier - should be 22.5ms for 1 connection event per
device and 45ms for 2 events.

Best,
Andrzej

Re: BLE communication scheduling

[Andrzej Kaczmarek]

Hi Ondrej,

Some tips inline below.

On Thu, Apr 9, 2020 at 5:46 PM Ondrej Pilat  wrote:

> Hi,
>
> I cannot find any documentation about Nimble connection events scheduling.
> I have following scenario:
>
> NRF52 Nimble is in dual role setting. Peripheral device connected to a PC
> with at least BLE 4.2 and MTU more than 153B. Central is connected to 18
> peripheral devices BLE 4.1 with MTU 27B.
>
> Do you think that Nimble can keep interval window 12.5ms with the PC and
> 37.5ms with all peripherals?
>
> My assumption are following:
>
>- only one packet per each connection event
>- send/receive 132B packet between NRF52 and PC each connection event
>- send/receive 20B packet between NRF52 and peripheral each connection
>event
>
> I made following rough computation:
>
> PC <-> NRF52: 132B data + 21B header => (153B * 8) / 1Mbps => 1224 uS +
> 150 uS IFR + 80 uS ACK + 150 uS IFR => 1604 uS * 2 (send/receive) => 3208
> uS
>
> NRF52 <-> peripheral: 20B data + 21B header => (41B * 8)  / 1Mbps => 328uS
> + 150 uS IFR + 80 uS ACK + 150uS IFR => 708uS * 2 (send/receive) => 1416 uS
>
> It means one big and six small packets should fit in each PC <-> NRF52
> connection event 3208 + 6 * 1416 = 11 704 < 12.5ms interval window. For 18
> peripherals it means 3 such cycles to serve them all therefore 37.5ms
> interval window between NRF52 and a peripheral.
>

You need to take NimBLE scheduling into account here. Each connection event
is preallocated a fixed amount of time in 1250us slots - see
BLE_LL_CONN_INIT_SLOTS. This means effectively connection events cannot be
scheduled less than 1250us apart. Also, scheduler overhead is ~200us (for
nRF52, may be different for nRF51) for each connection event so effective
connection event time with 1 slot allocated is 1050us. Note that this is
min time since connection events can be extended pretty much indefinitely
as long as there is no other activity scheduled so e.g. until another
connection event.

I do not know if "20B packet" means "20 bytes of LL payload", but will
assume so since we are talking LL level here. This can fit into a single
scheduled slot: 240us + 150us + 80us = 470us < 1050us. Let's assume 1ms for
each connection event including scheduler overhead so you need 18ms to
serve all 18 devices in one direction. If you need to send data in both
directions you need 240us + 150us + 240us = 630us < 1050us so nothing
changes and you still have quite a lot of extra time to spare in each
connection event (e.g. for retransmissions). It will be a bit different if
you need to transfer data in both directions in separate connection events
as basically you need twice as much connection events, this means you need
at least 36ms to serve all peripherals. One possible problem here is that
connection may not be scheduled exactly 1.25ms apart and this will create
gaps where no connection can be scheduled, you can't really control this
with default scheduler. Possible solution would be to use
BLE_LL_STRICT_CONN_SCHEDULING which schedules connections in central role
at fixed intervals, although I never used it so not sure if there's
anything that requires more configuration than just enabling this feature.

So dealing with peripherals should not be a problem. Connection with a PC
is a more troublesome since NimBLE has a slave role here so it needs to use
anchor point imposed by a master. In theory, as a slave you can request to
move anchor point but you would need to guarantee there is slot of proper
duration and at proper intervals (so slave connections need to be arranged
properly) for this to make any sense. NimBLE does not yet allow to move
anchor point since it does not have any logic to do this in a way that
makes any sense. Perhaps the best solution you could try for now is just to
ignore connection with a PC in your scheduling so it will be scheduled at
the time of some peripheral connection. In such case, NImBLE will let the
least recently active connection run so it will skip connection events on
"random" connections. It should not impact data throughput since
outstanding data will be sent at next connection interval, but it will
likely impact latency so you just need to check it this is acceptable in
your case.

Are following parameters good to achieve this:
>
> NRF52 <-> PC
>
> static const struct ble_gap_conn_params ble_gap_conn_params_ideal = {
>.scan_itvl = BLE_GAP_SCAN_FAST_INTERVAL_MIN,
>.scan_window = BLE_GAP_SCAN_FAST_WINDOW,
>.itvl_min = 10,
>.itvl_max = 10,
>.latency = 0,
>.supervision_timeout = 500,
>.min_ce_len = 5, // 3.208 / 0.625 = 5.1328
>.max_ce_len = 6,
> };
>
> NRF52 <-> Peripheral
>
> static const struct ble_gap_conn_params ble_gap_conn_params_ideal = {
>.scan_itvl = BLE_GAP_SCAN_FAST_INTERVAL_MIN,
>.scan_window = BLE_GAP_SCAN_FAST_WINDOW,
>.itvl_min = 30,
>.itvl_max = 30,
>.latency = 0,
>.supervision_timeout = 500,
>.min_ce_len = 2, // 1.416 / 0.625 = 2.2656
>.max_ce_len 

Re: [VOTE] Release Apache Mynewt 1.8.0-rc2 and Apache NimBLE 1.3.0-rc2

[Andrzej Kaczmarek]

+1 (binding)

/a.

On Thu, Mar 26, 2020 at 5:27 PM Szymon Janc  wrote:

> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.8.0 and Apache NimBLE 1.3.0.
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> Apache NimBLE is Bluetooth Low Energy 5.1 stack from Apache Mynewt.
>
> This release is coordinated release of Apache Mynewt and NimBLE. Future
> NimBLE releases may be released separately depending on needs.
>
> For full release notes for both Mynewt and NimBLE, please visit the Apache
> Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> Comparing to rc1 only licensing issues were sorted out and there were no
> code
> changes.
>
> Apache Mynewt and Apache NimBLE release candidates were tested as follows:
>   1. Manual execution of the Mynewt test plan:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.8.0+Test+Results
>   2. Manual execution of the NimBLE test plan:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+NimBLE+Test+Plan
>  The test results can be found at:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/NimBLE+1.3.0+Test+Results
>   3. The full unit test suite for both releases was executed via "newt
> test all"
>  with no failures. This testing was performed on the following
> platforms:
>* OS X 10.15
>* Fedora Linux 32
>
> Note that this testing is not yet complete and more results will show while
> voting is ongoing.
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/
> https://dist.apache.org/repos/dist/dev/mynewt/apache-nimble-1.3.0/rc2/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit 34e9aae78f3ab4a4307bf99b4e25be11060aa526
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit cb9df4273aac1c8e627ff4df67b866ba9a22b018
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit 725740e08825a4a15d6270cccd7ff45fdd928312
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 15c6a24d57d6dbdcf33646df365b2c64a12de251
> nimble:
>   repos: https://github.com/apache/mynewt-nimble
>   commit 97ce3eacaaa79e8ed6cf71717149ced4f5328ee7
>
> In addition, the following newt and newtmgr convenience binaries are
> available:
>   linux:
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newt-bin-linux-1.8.0.tgz
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newtmgr-bin-linux-1.8.0.tgz
>
>   osx:
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newt-bin-osx-1.8.0.tgz
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newtmgr-bin-osx-1.8.0.tgz
>
>   windows:
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newt-bin-windows-1.8.0.tgz
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.8.0/rc2/apache-mynewt-newtmgr-bin-windows-1.8.0.tgz
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon Janc
>
>
>

Common API for provisioned data

[Andrzej Kaczmarek]

Hi,

Long story short: I want to have some interface to provision NimBLE with
device address and keys (e.g. IRK) in a way that is consistent on all BSPs.
This means application does not need to care where address or IRK is stored
on any given platform.

Currently NimBLE host provides helper API to figure out identity address,
but it uses either syscfg value or ble_hw controller API which only works
on Nordic chips and returns address burned into FICR. This is less than
ideal. For example, we recently added support for Dialog MCU which does not
have ble_hw nor has address burned into chip anywhere. On the other hand it
has OTP which can be programmed in factory with addresses and keys, but how
this is done is up to vendor and thus can be different for each BSP.

A similar use case I believe is a hardware id which already has its own
API, namely hal_bsp_hw_id(). However, adding separate API for each data
type does not sound like a good idea. It would be better to have a single
API for any kind of provisioned data and also merge hardware id there.

I drafted some code to add new API and also updated some nRF52840 DK code
to implement this new API, please take a look here:
https://github.com/apache/mynewt-core/pull/2192

I think it's all pretty well described in the code, but just to give a
quick overview here as well:
- hal_bsp_prov_data_get() is used to retrieve provisioned data with given
identifier
- identifiers are predefined for known data types, custom types (e.g.
BSP-specific) can also be used
- application can register a callback which allows to override data, i.e.
BSP will query application to get some data instead of providing it; not
sure if this is really useful assuming BSP should be already customized for
each product, but perhaps some data may be further customized per-app

So this is all quite simple and I think will be useful for other packages
as well in future.

As always, comments are welcome!

Best,
Andrzej

Re: NimBLE: Host based privacy support

[Andrzej Kaczmarek]

Hi Prasad,

I understand that there are controllers without LL Privacy support, but to
be honest this feature was added a few years ago and there were already few
subsequent Core spec versions adopted in the meantime so I'd rather assume
LL Privacy is a standard feature for an LE Controller in 2020 and vote
against adding support for host-based privacy in our host.

Moreover, I think you don't really need it. Since NimBLE APIs resemble HCI
interface (which is a good and a bad thing, depending on what you need - in
this case it's the former) you can handle privacy in your app. I think all
required APIs should be available, but let me know if you think something
is missing and we can figure out what to do. Such privacy support could be
wrapped inside a separate module for app to use rather than being
integrated inside NimBLE.

Another option to consider is a layer between HCI transport and host (could
be just a separate HCI transport with this layer integrated) which will
translate HCI traffic from a LL-Privacy-aware host to
non-LL-Privacy-enabled controller. This basically means resolving list and
address resolution/generation would be performed by this layer and there
would be no host changes required. This is obviously quite tricky to do, so
I think just handling privacy inside app is a much easier solution here.

Best,
Andrzej






On Thu, Jan 30, 2020 at 6:46 AM Prasad Alatkar 
wrote:

> Hi Andrzej,
>
> Thank you for your reply. I was thinking of adding "Host based privacy" as
> an additional feature, by default "Controller based privacy" will be used.
> I thought this feature will be useful for NimBLE Host only implementation
> where vendor's controller does not support privacy feature. Please let me
> know your take on this.
>
> Regards,
> Prasad
> --
> *From:* Andrzej Kaczmarek 
> *Sent:* Thursday, January 30, 2020 6:09 PM
> *To:* dev@mynewt.apache.org 
> *Cc:* Hrishikesh Dhayagude 
> *Subject:* Re: NimBLE: Host based privacy support
>
> Hi Prasad,
>
> On Thu, Jan 30, 2020 at 1:13 PM Prasad Alatkar <
> prasad.alat...@espressif.com>
> wrote:
>
> > Hi all,
> >
> > I have been working on "NimBLE host based privacy (RPA)" with no
> > involvement of controller for past few days, spec ref: Vol 3, part C,
> > section 10.7.1.2 / 10.7.2.2 (Privacy Feature in a Peripheral/central with
> > Host-based privacy). Before I come up with pull request, here are few key
> > points:
> >
> >   1.  Similar to `BLE_LL_CFG_FEAT_LL_PRIVACY`, add
> > `BLE_HOST_BASED_PRIVACY`.
> >   2.  As controller is not aware of host based privacy, we can not
> > directly use "own address type = BLE_OWN_ADDR_RPA_PUBLIC_DEFAULT". I have
> > tried to use "own address type = BLE_OWN_ADDR_RANDOM" for this feature.
> >   3.  Provide API to enable/disable Host based privacy, wherein the RPA
> > will be generated and address will be set in controller as
> BLE_ADDR_RANDOM,
> > provide API similar to `ble_hs_id_set_rnd` which sets RPA address.
> >   4.  Handle the peer side privacy in `LE enhanced connection` &
> > `advertisement reports`, save the peer RPA in "Peer Records" (similar to
> > Resolving list ).
> >   5.  Once the pairing is done and bond is established, add device to
> > resolved list (maintained in host) and update corresponding "Peer
> record".
> >   6.  While reconnecting, check if the peer is RPA, check if it is
> > resolvable by any entry from "peer records", get entry from "resolving
> > list" corresponding to it and we are done with the reconnection.
> >
> >
> > Please let me know if this is an acceptable approach for mynewt nimble.
> >
>
> NimBLE does not support host based privacy by design - it works primarily
> with NimBLE controller (i.e. 4.2+) which does support LL Privacy and thus
> simply assumes such support. I think this is just fine and unless you have
> a very good reason why host based privacy support is required, we should
> keep it as it is now.
>
>
> >
> > Regards,
> > Prasad
> >
>
> Best,
> Andrzej
>

Re: NimBLE: Host based privacy support

[Andrzej Kaczmarek]

Hi Prasad,

On Thu, Jan 30, 2020 at 1:13 PM Prasad Alatkar 
wrote:

> Hi all,
>
> I have been working on "NimBLE host based privacy (RPA)" with no
> involvement of controller for past few days, spec ref: Vol 3, part C,
> section 10.7.1.2 / 10.7.2.2 (Privacy Feature in a Peripheral/central with
> Host-based privacy). Before I come up with pull request, here are few key
> points:
>
>   1.  Similar to `BLE_LL_CFG_FEAT_LL_PRIVACY`, add
> `BLE_HOST_BASED_PRIVACY`.
>   2.  As controller is not aware of host based privacy, we can not
> directly use "own address type = BLE_OWN_ADDR_RPA_PUBLIC_DEFAULT". I have
> tried to use "own address type = BLE_OWN_ADDR_RANDOM" for this feature.
>   3.  Provide API to enable/disable Host based privacy, wherein the RPA
> will be generated and address will be set in controller as BLE_ADDR_RANDOM,
> provide API similar to `ble_hs_id_set_rnd` which sets RPA address.
>   4.  Handle the peer side privacy in `LE enhanced connection` &
> `advertisement reports`, save the peer RPA in "Peer Records" (similar to
> Resolving list ).
>   5.  Once the pairing is done and bond is established, add device to
> resolved list (maintained in host) and update corresponding "Peer record".
>   6.  While reconnecting, check if the peer is RPA, check if it is
> resolvable by any entry from "peer records", get entry from "resolving
> list" corresponding to it and we are done with the reconnection.
>
>
> Please let me know if this is an acceptable approach for mynewt nimble.
>

NimBLE does not support host based privacy by design - it works primarily
with NimBLE controller (i.e. 4.2+) which does support LL Privacy and thus
simply assumes such support. I think this is just fine and unless you have
a very good reason why host based privacy support is required, we should
keep it as it is now.


>
> Regards,
> Prasad
>

Best,
Andrzej

Re: Runtime memory statistics

[Andrzej Kaczmarek]

Hi Mark,

On Mon, Jan 6, 2020 at 6:08 PM Mark Ruys  wrote:

> Is there a way to determine the current maximum heap usage. I want to
> check in my application how low free heap became so far to warn if it got
> too low. Idem for the stacks. Basically tools like
> https://os.mbed.com/docs/mbed-os/v5.14/tutorials/optimizing.html#runtime-memory-statistics
> <
> https://os.mbed.com/docs/mbed-os/v5.14/tutorials/optimizing.html#runtime-memory-statistics
> >
>

If you just want to track max bytes allocated from stack at any time you'll
need to hack malloc/free to track this - it should be fairly simple.

> Thanks,
>
> Mark
>
> PS This gives me the current free heap:
> uint16_t heap_free = &__HeapLimit - (char *)_sbrk(0)
>

This is not current free heap space - it's just the size of remaining space
that heap can use. This is because baselibc can increase program break on
malloc, but will never decrease it. However, you can use similar
calculation to get something that is closer to what you want:
size_t heap_max = (char *)_sbrk(0) - &__HeapBase;
This will return max ever bytes used by heap. It's not the same as max ever
bytes allocated from heap since there can be some free space included due
to fragmentation but honestly it's much better than just raw number of
allocated bytes since it allows to estimate actual required heap size.


> For stack I iterate os_task_info_get_next(), giving me oti_stksize and
> oti_stkusage.


Best,
Andrzej

Re: Can I run nimble stack on nRF52840DK without RTOS?

[Andrzej Kaczmarek]

Hi,

On Thu, Jan 9, 2020 at 9:37 AM pei cao  wrote:

> Hi~
>
> I'm trying to measure the power consumption of the nRF52840 chip , which
> runs the nimble full stack.
> However, the mynewt RTOS seems to bring too much noise and deeply effect
> the measurement.
> I want to use nimble without RTOS so that I can get pure measurement
> results，is it possible? Any suggestions?
>
> Thanks for any help.
>

You can't run NimBLE without RTOS since it needs OS to work, i.e. it's not
a bare metal code.
What do you mean by "bring too much noise"? If you want to measure power
consumption of nRF52840 then just do not run NimBLE on it. If you want to
measure power consumption of nRF52840 running full NimBLE stack (I assume
controller+host) then OS is just one of the components of overall power
consumption. Make sure that you do not have unnecessary stuff enabled in
your build (so there are no unused peripherals enabled) and use app which
works like a regular product (so e.g. does not have console where all debug
output is printed) and you will get pretty much accurate results.

Best,
Andrzej

Re: Incorrect reporting of desc.sec_stat.bonded value on legacy pairing.

[Andrzej Kaczmarek]

Hi Daniel,

On Mon, Jan 13, 2020 at 10:09 PM Daniel Mastain  wrote:

> Hello,
>
> I'm experiencing an issue when using the btshell app on a linux machine.
> I'm attempting to pair two devices both running nimBLE in a just works
> scenario where both initiator and responder are set to have bonding
> disabled but the desc.sec_state.bonded values are being set to 1 on both
> devices. My set up is as follows.
>
> Device
> Initiator
> Resonder
> io_cap
> 4
> 0
> mitim_flag
> 0
> 0
> bonding_flag
> 0
> 0
> sc_flag
> 0
> 0
> oob_flag
> 0
> 0
>
> btshell log:
>
> 223873 btshell> connect peer_addr=01:02:03:04:05:06
> 225189 [ts=225189us, mod=4 level=1] GAP procedure initiated: connect;
> peer_addr_type=0 peer_addr=
> 01:02:03:04:05:06 scan_itvl=16 scan_window=16 itvl_min=24 itvl_max=40
> latency=0 supervision_timeout=2
> 56 min_ce_len=16 max_ce_len=768 own_addr_ty
> 225200 btshell> connection established; status=0 handle=72
> our_ota_addr_type=0 our_ota_addr=00:1a:7d:
> da:71:08 our_id_addr_type=0 our_id_addr=00:1a:7d:da:71:08
> peer_ota_addr_type=0 peer_ota_addr=01:02:03
> :04:05:06 peer_id_addr_type=0 peer_id_addr=01:02:03:04:05:06 conn_itvl=40
> conn_latency=0 supervision_
> timeout=256 key_size=0 encrypted=0 authenticated=0 bonded=0
>
> 225445 btshell>
> 225462 btshell> security-set-data mitm_flag=0 our_key_dist=0
> their_key_dist=0 bonding=0 sc=0 oob_flag
> =0 io_capabilities=4
> 226883 btshell>
> 227016 btshell> security-pair conn=72
> 228082 btshell> encryption change event; status=0 handle=72
> our_ota_addr_type=0 our_ota_addr=00:1a:7d
> :da:71:08 our_id_addr_type=0 our_id_addr=00:1a:7d:da:71:08
> peer_ota_addr_type=0 peer_ota_addr=01:02:0
> 3:04:05:06 peer_id_addr_type=0 peer_id_addr=01:02:03:04:05:06 conn_itvl=40
> conn_latency=0 supervision
> _timeout=256 key_size=16 encrypted=1 authenticated=0 bonded=1
>
> 229827 btshell> keystore-show type=msec
> 231814 btshell>
>
> Wireshark SMP exchange verification:
>
>
> My observations indicate the while the device is performing as expected it
> is reporting incorrect values. I'm not experienced enough with this stack
> to know where the change needs to be implemented to correct this issue but
> the root cause looks like it may be in the function
> ble_sm_key_exh_success() when called by ble_sm_key_exch_exec() wherein the
> bonded value is hard coded to be written to 1. Let me know your thoughts.
>
>
Seems like you're right, we should not force bonding=1 in
ble_sm_key_exch_success() but use calculated value (we do this when pairing
is started). I think this is the proper way to update conn state:
https://github.com/apache/mynewt-nimble/pull/730. Could you please try it
and see if it fixes your issue? Before merging we'll need to run this
through qualification test cases to verify that it does not break something
else anyway.

Best,
Andrzej

Re: Cortex-M hardware stack limit checking

[Andrzej Kaczmarek]

FYI: patch which replaces stack top with stack bottom and related changes
are already merged

Best,
Andrzej


On Wed, Nov 27, 2019 at 10:14 AM Marko Kiiskila 
wrote:

> Option 3 sounds best to me as well.
>
> > On 26 Nov 2019, at 18.36, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
> >
> > option 3 looks good to me: +1
> >
> > Best
> > Łukasz
> >
> > On Mon, 25 Nov 2019 at 21:11, Jerzy Kasenberg
> >  wrote:
> >>
> >> HI,
> >>
> >> I vote for option 3
> >>
> >> My reason, apart what Andrzej mentioned (usefulness and debugging),
> >> is that there is a notorious coverity warning popping up about usage of
> >> address &t_tasktop[stack_size].
> >>
> >> best regards
> >> Jerzy
> >>
> >> pon., 25 lis 2019 o 16:28 Andrzej Kaczmarek <
> andrzej.kaczma...@codecoup.pl>
> >> napisał(a):
> >>
> >>> Hi,
> >>>
> >>> I recently created a PR which adds support for hardware stack limit
> >>> checking on Cortex-M33. It was already approved by few people but
> >>> apparently there are different opinions of how this should be
> implemented
> >>> so I would like to get more opinions on this since we likely will have
> more
> >>> MCUs with this feature soon, so consider this as a voting.
> >>>
> >>> PR: https://github.com/apache/mynewt-core/pull/2108
> >>>
> >>> Here are proposed ways to do this:
> >>> 1. use stack top and stack size to calculate PSPLIM on every context
> switch
> >>> this does not require any modification in os_task structure and adds 4
> >>> instructions on each context switch
> >>> 2. add stack bottom to os_task
> >>> this extends os_task struct by 4 bytes and adds 2 instructions on each
> >>> context switch
> >>> 3. change stack top to stack bottom in os_task
> >>> this does not change the size of os_task struct and adds 2
> instructions on
> >>> each context switch, however it may break code which accesses os_task
> >>> structure directly (like mcumgr does - it should be modified to use
> proper
> >>> API anyway)
> >>>
> >>> My personal preference is option 3 since it is more useful to have
> stack
> >>> bottom in os_task struct instead of stack top. For example, stack
> overflow
> >>> or usage is determined using stack bottom. Also when debugging it's
> easier
> >>> to inspect stack by using stack bottom rather than stack top. In
> general,
> >>> seems like you only need stack top when initializing it but this is
> done
> >>> only once (even os_task_init has 'stack_bottom' parameter, not
> >>> 'stack_top').
> >>>
> >>> Best,
> >>> Andrzej
> >>>
>
>

Cortex-M hardware stack limit checking

[Andrzej Kaczmarek]

Hi,

I recently created a PR which adds support for hardware stack limit
checking on Cortex-M33. It was already approved by few people but
apparently there are different opinions of how this should be implemented
so I would like to get more opinions on this since we likely will have more
MCUs with this feature soon, so consider this as a voting.

PR: https://github.com/apache/mynewt-core/pull/2108

Here are proposed ways to do this:
1. use stack top and stack size to calculate PSPLIM on every context switch
this does not require any modification in os_task structure and adds 4
instructions on each context switch
2. add stack bottom to os_task
this extends os_task struct by 4 bytes and adds 2 instructions on each
context switch
3. change stack top to stack bottom in os_task
this does not change the size of os_task struct and adds 2 instructions on
each context switch, however it may break code which accesses os_task
structure directly (like mcumgr does - it should be modified to use proper
API anyway)

My personal preference is option 3 since it is more useful to have stack
bottom in os_task struct instead of stack top. For example, stack overflow
or usage is determined using stack bottom. Also when debugging it's easier
to inspect stack by using stack bottom rather than stack top. In general,
seems like you only need stack top when initializing it but this is done
only once (even os_task_init has 'stack_bottom' parameter, not 'stack_top').

Best,
Andrzej

Re: sensorhub bsp phase out proposal

[Andrzej Kaczmarek]

+1

/Andrzej

On Thu, Nov 14, 2019 at 8:58 AM Jerzy Kasenberg 
wrote:

> Hi there,
>
> For some time now targets based on "hw/bsp/sensorhub" are not building.
> There is outstanding PR https://github.com/apache/mynewt-core/pull/2086
> that removes build issues but it does not make sensorhub workable.
>
> I was not able to find any documentation for this hardware so it seems
> reasonable that it may not be available any more.
>
> I anyone is still using it's time to step out.
>
> I propose to drop whatever support we have for this BSP so it will not be
> available in the next release.
>
> best regards
> Jerzy
>

Re: Newt feature: run custom commands at build time

[Andrzej Kaczmarek]

Hi Chris,

On Tue, Oct 1, 2019 at 3:21 AM Christopher Collins  wrote:

> Hi Andrzej,
>
> On Thu, Sep 26, 2019 at 07:24:54PM +0200, Andrzej Kaczmarek wrote:
> > This looks very good! I was thinking if it would be possible to reference
> > other targets (i.e. artifacts) from scripts but with the latest addition
> of
> > shared folder this does not seem to be a problem since it can be also
> > shared with another newt build invoked from script and we can copy/write
> > data there. I did not yet check how this work in practice but will give
> it
> > a try and perhaps then I'll have some extra ideas.
>
> Thanks for taking a look!
>
> > > post_cmds (run after the build).
> > >
> > > ### EXAMPLE
> > >
> > > Example (apps/blinky/pkg.yml):
> > >
> > > pkg.pre_cmds:
> > > scripts/pre_build1.sh: 100
> > > scripts/pre_build2.sh: 200
> > >
> > > pkg.post_cmds:
> > > scripts/post_build.sh: 100
> > >
> >
> > I assume these are relative to package root so perhaps we could assume
> > there is scripts/ subdir and execute from there by default? Just the same
> > as we have src/ and include/.
>
> I'm reluctant to use an implicit path here.  I think it is good to be
> explicit so that there is no confusion about where a script is located.
>
> We use an implicit "targets" path, but I feel like that is easier to
> justify because it saves the user from constantly typing the same thing.
> I don't think this custom command feature will be used very often at
> all, so I am not sure an implicit path would add much in the way of
> convenience.
>
> It's easy to add an implicit path later, but impossible to remove it.
> Unless you have a strong opinion on this, I suggest we give the feature
> some time without the implicit path and make the decision later.
>

I do not have a strong opinion on this, we can keep it as is, however... I
expected that these paths are relative to package root but seems like they
are relative to project root. Is this intended behavior? I did not find any
way to address script in a package other that using full path, i.e.
'repos/.../.../script.sh' which is counter-intuitive tbh. Perhaps I
misunderstood description, but my understanding was that cwd is set to
project root, but newt will still look for a script in package root - this
would make more sense I think.


> Thanks,
> Chris
>

Best,
Andrzej

Re: Newt feature: run custom commands at build time

[Andrzej Kaczmarek]

Hi Chris,

On Tue, Sep 24, 2019 at 2:48 AM Christopher Collins 
wrote:

> Hello all,
>
> I have implemented a feature in newt: the ability to run custom shell
> commands at build time.
>
> 
>
> Is there any extra functionality that you'd like to see here?  All
> comments are appreciated.  I am duplicating the PR text here, but the
> formatting is a little nicer in the PR.
>

This looks very good! I was thinking if it would be possible to reference
other targets (i.e. artifacts) from scripts but with the latest addition of
shared folder this does not seem to be a problem since it can be also
shared with another newt build invoked from script and we can copy/write
data there. I did not yet check how this work in practice but will give it
a try and perhaps then I'll have some extra ideas.


> Thanks,
> Chris
>
> ---
>
> A package specifies custom commands in its `pkg.yml` file.  There are
> two types of commands: 1) pre_cmds (run before the build), and 2)
> post_cmds (run after the build).
>
> ### EXAMPLE
>
> Example (apps/blinky/pkg.yml):
>
> pkg.pre_cmds:
> scripts/pre_build1.sh: 100
> scripts/pre_build2.sh: 200
>
> pkg.post_cmds:
> scripts/post_build.sh: 100
>

I assume these are relative to package root so perhaps we could assume
there is scripts/ subdir and execute from there by default? Just the same
as we have src/ and include/.

Best,
Andrzej

Re: getting rid of ble_hs_dbg.c

[Andrzej Kaczmarek]

Hi,

On Wed, Sep 11, 2019 at 3:40 PM Szymon Janc  wrote:

> Hi,
>
> Since we have BLE_MONITOR support which is far superior copmaring to
> ble_hs_dbg.c... how about getting rid of that file?
>

I'm all for it and also for removing other "decoders" we have - these are
likely not up to date with new features anyway.


> Are there any active users relying on HCI events debugging via logs?
>

I never used it since it's just hard to follow - this was main reason why
monitor interface was added to make analyzing HCI stream much easier.


> --
> pozdrawiam
> Szymon Janc
>

Best,
Andrzej

Re: DA1469x board support

[Andrzej Kaczmarek]

Hi,

On Wed, Aug 7, 2019 at 1:17 AM Dr. Juergen Kienhoefer 
wrote:

> @mkiiskila: Thanks for providing the DA1469x board support.
> I'm putting together a tutorial how to get Newt working on these boards
> with Nimble.
> So far I gathered these bits of information. Apparently, it's not quite
> enough.
> Please help me getting it complete:
>


> FLASH LOADER
>
> newt target create da1469x_flash_loader
>
> newt target set da1469x_flash_loader
> app=@apache-mynewt-core/apps/flash_loader
>
> newt target set da1469x_flash_loader
> bsp=@apache-mynewt-core/hw/bsp/dialog_da1469x-dk-pro
>
> newt target set da1469x_flash_loader build_profile=optimized
>
> newt target set da1469x_flash_loader
> syscfg=FLASH_LOADER_DL_SZ=0x1:RAM_RESIDENT=1
>
>
> APP
>
> newt target create da1469x_blinky
>
> newt target set da1469x_blinky app=apps/blinky
>
> newt target set da1469x_blinky
> bsp=@apache-mynewt-core/hw/bsp/dialog_da1469x-dk-pro
>
> newt target set da1469x_blinky build_profile=debug
>
>
> LOAD FLASHLOADER
>
> >>>  must run "newt run da1469x_blinky" first to create flash_loader.img,
> then load it
>
> newt load da1469x_flash_loader
>

This is not how it works. You need 3 targets: flash_loader, bootloader and
app. What you are missing is a bootloader:
newt target create da1469_boot
newt target set da1469x_boot app=@mcuboot/boot/mynewt
newt target set da1469x_boot
bsp=@apache-mynewt-core/hw/bsp/dialog_da1469x-dk-pro
newt target set da1469x_boot build_profile=optimized

You need to load bootloader and app to flash and this is where flash_loader
is used, i.e. you do not load flash_loader, but download script requires it
to be able to load app and bootloader to flash. The easiest way to do this
is:
newt load da1469x_boot
newt create-image da1469x_blinky 1.0.0
newt load da1469x_blinky

"newt run da1469x_blinky 1.0.0" will create image for app and load it and
then start debugging session (as with newt debug) so can be used as a
shortcut for app, but bootloader needs to be loaded separately.
Also to load bootloader you will need Python 3.7 (3.6 or older won't work)
installed because part of bootloader download script which creates product
header is written in Python. Without proper product header internal
bootloader won't boot our bootloader (mcuboot) and app won't start.

Once you load both bootloader and app, it should boot properly.

Best,
Andrzej

Re: [VOTE] Release Apache Mynewt 1.7.0-rc2 and Apache NimBLE 1.2.0-rc2

[Andrzej Kaczmarek]

+1 (binding)



On Mon, Jul 29, 2019 at 1:39 PM Szymon Janc  wrote:

> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.7.0 and Apache NimBLE 1.2.0.
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> Apache NimBLE is Bluetooth Low Energy 5.0 stack from Apache Mynewt.
>
> This release is coordinated release of Apache Mynewt and NimBLE. Future
> NimBLE releases may be released separately depending on needs.
>
> For full release notes for both Mynewt and NimBLE, please visit the Apache
> Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> Apache Mynewt and Apache NimBLE release candidates were tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/
> Apache+Mynewt+Test+Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.7.0+Test+Results
>   2. Manual execution of the NimBLE test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/
> Apache+NimBLE+Test+Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/
> NimBLE+1.2.0+Test+Results
>
>  Note that this testing is not yet complete and more results will show
>  while voting is ongoing.
>
>   2. The full unit test suite for both releases was executed via
>  "newt test all" with no failures. This testing was performed on the
>  following platforms:
>* OS X 10.14
>* Fedora Linux 30
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/
> https://dist.apache.org/repos/dist/dev/mynewt/apache-nimble-1.2.0/rc2/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit 1007e978f2655b3e054099ff8600d147a79b369b
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit b7a5474d569d5b67152d1773627ddda010c080a3
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit 80bcba727dfe828dcb1f8da522f0502377d18fd4
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit a222bac117793db7b8444acfb744dcb822a6f448
> nimble:
>   repos: https://github.com/apache/mynewt-nimble
>   commit 5371a45890604d32564c6384eb00dfee74ee7d13
>
> In addition, the following newt and newtmgr convenience binaries are
> available:
>   linux:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/
> apache-mynewt-newt-bin-linux-1.7.0.tgz
> 
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/
> apache-mynewt-newtmgr-bin-linux-1.7.0.tgz
> 
>
>   osx:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/
> apache-mynewt-newt-bin-osx-1.7.0.tgz
> 
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/
> apache-mynewt-newtmgr-bin-osx-1.7.0.tgz
> 
>
>   windows:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/
> apache-mynewt-newt-bin-windows-1.7.0.tgz
> 
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/
> apache-mynewt-newtmgr-bin-windows-1.7.0.tgz
> 
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon Janc
>
>
>

Re: NimBLE controller: timer mapping for nrf51

[Andrzej Kaczmarek]

Hi Hauke,

On Tue, Jun 4, 2019 at 12:28 PM Hauke Petersen 
wrote:

> Dear community,
>
> I am not fully confident, if this is the right place to ask, so let me
> know if there is a better place :-)
>
> We were recently trying to run the NimBLE controller on nrf51-based
> platforms using RIOT. We found that that the NimBLE controller has a
> hardcoded dependency on the nrf51 NRF_TIMER0. The same timer is per
> default also used as base for the RIOT system timer (xtimer). Although
> its a simple workaround to map RIOT to use some other timer, it is
> sub-optimal in terms of energy usage, as the other timers are all only
> 16-bit. So my question: does the NimBLE controller need a >16-bit timer,
> and would it be feasible to make the used hw-timer configurable for the
> NimBLE nrf51-related controller code?
>

That won't work unfortunately.
The reason we use TIMER0 is that on nRF5x there are pre-programmed PPI
channels that link TIMER0 with RTC0 and RADIO to provide timing for radio
operations. To use other timer we would need to use 7 programmable PPI
channels which is doable, but IMO it would make code unnecessarily
complicated and would not work on 16-bit timers anyway (so ony nRF52). In
particular, TIMER0 is used to timestamp received packets so 16-bit timer
running at 1 MHz would roll-over every 65ms which is way too short for
scanning to work properly.


> Cheers,
> Hauke
>

Best,
Andrzej

Re: Adding a callback before asm("bkpt") in the assert function and hal_system_reset()

[Andrzej Kaczmarek]

Hi,

I already put some of comments below in (already merged) PR which seems to
add this functionality, but this gives more context about the change itself
so I have few more comments.

On Fri, May 3, 2019 at 1:57 AM Vipul Rahane  wrote:

> Hello,
>
> So, we are running into an issue where some peripheral needs to get shut
> down before the breakpoint gets hit. this only happens when the debugger is
> connected and so, it quite isolated in terms on functionality.
>

It would be better to have such callback/whatever as a general option, not
only while debugger is connected, since this makes it more generic and you
can easily check if debugger is connected in your callback.


> There are different approaches we could follow:
>
> 1. Have a macro (syscfg) define that function and call that macro
>
> 154 #ifdef MYNEWT_VAL_HAL_SYSTEM_PRE_BKPT_CB
> 155HAL_SYSTEM_PRE_BKPT_CB();
> 156 #endif
> 157
> 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT)
> 159asm("bkpt");
> 160 #endif
>
> 2. Have a `hal_system_pre_bkpt_cb()` function, register a callback and have
> one specific MCU call it only if a syscfg is set, something like:
>
> 154 #ifdef MYNEWT_VAL(HAL_SYSTEM_PRE_BKPT_CB)
> 155hal_system_pre_bkpt_cb();
> 156 #endif
> 157
> 158 #if !MYNEWT_VAL(MCU_DEBUG_IGNORE_BKPT)
> 159asm("bkpt");
> 160 #endif
>

I am not a fan of injecting code via syscfg, so definitely would prefer
callback approach or just have a function declaraction that application
should define if those callbacks are enabled. - this is quite low level API
so user-friendliness of a callbacks is not something I'd require, but otoh
there may be some scenarios where callbacks could be useful (I don't have
anything specific in mind).

Also refering to what was done in PR, I do not think that having a single
syscfg defined in MCU which controls code in both hal_system and kernel/os
is a good idea. I'd prefer separate options for callback in
hal_system_reset (like MCU_PRE_RESET_CALLBACK) and __assert_func (like
OS_ASSERT_CALLBACK).

These are just some simple suggestions we could follow, obviously there is
> a hard way of doing this thing where we change APIs and register a callback
> and have assert take that callback as an argument but I am not a big fan of
> changing standard APIs.
>
> If others have a suggestion, please let me know. If not I am going to
> assume everybody is fine with option 2.
>
> --
>
> Regards,
> Vipul Rahane
>

Best,
Andrzej

Re: nRF52 NFC

[Andrzej Kaczmarek]

Hi,

On Thu, Apr 18, 2019 at 3:23 PM Amr Bekhit  wrote:

> Hello all,
>
> I'm trying to port the nRF NFC library to mynewt 1.5, but I'm struggling to
> get basic NFC functionality up and running.
>
> I've put together a basic mynewt project using the PCA10040 BSP and using
> the barebones NFC example at
>
> https://devzone.nordicsemi.com/f/nordic-q-a/23154/nfc-not-working-on-payment-readers/91079#91079
> (I
> basically migrated that code over to the mynewt main.c file - you can see
> at https://pastebin.com/4mSUzKML). Unfortunately, the NFCT_IRQHandler
> never
> gets called. The same code works fine when I build it without mynewt using
> a bare-metal project in SEGGER IDE.
>
> I suspect that the problem may lie in declaration of the NFCT irq handler -
> perhaps despite declaring the function it's not being routed to the vector
> table? However, NFCT_IRQHandler does seem to be present in the
> gcc_startup_nrf52.s file.
>
> Any thoughts?


You need to implement this handler and set interrupt vector using
NVIC_SetVector() - Mynewt does not provide handlers for interrupts which
are not used in code.


> Amr
>

Best,
Andrzej

Re: [VOTE] Release Apache Mynewt 1.6.0-rc2 and Apache NimBLE 1.1.0-rc2

[Andrzej Kaczmarek]

+1 (binding)



On Tue, Apr 2, 2019 at 11:28 PM Szymon Janc  wrote:

> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.6.0 and Apache NimBLE 1.1.0.
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> Apache NimBLE is Bluetooth Low Energy 5.0 stack from Apache Mynewt.
>
> This release is coordinated release of Apache Mynewt and NimBLE. Future
> NimBLE releases
> may be released separately depending on needs.
>
> For full release notes for both Mynewt and NimBLE, please visit the Apache
> Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> Apache Mynewt and Apache NimBLE release candidates were tested as follows:
>   1. Manual execution of the Mynewt test plan:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.6.0+Test+Results
>   2. Manual execution of the NimBLE test plan:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+NimBLE+Test+Plan
>  The test results can be found at:
>
> https://cwiki.apache.org/confluence/display/MYNEWT/NimBLE+1.1.0+Test+Results
>
>  Note that this testing is not yet complete and more results will show
> while
>  voting is ongoing.
>
>   2. The full unit test suite for both releases was executed via "newt
> test all"
>  with no failures. This testing was performed on the following
> platforms:
>* OS X 10.14
>* Fedora Linux 29
>
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.6.0/rc2/
> https://dist.apache.org/repos/dist/dev/mynewt/apache-nimble-1.1.0/rc2/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit 8cad686874cd2824a5cd483df7254870f8ac5e88
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit eb1d3ec0f486d92887586f60d87f0bb916188515
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit da3758b66fa010cd8db7d5ae60a1a9dfaf97db8c
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 06ecbd65d47ca1c52b367d2be7f8c3a69d5bd195
> nimble:
>   repos: https://github.com/apache/mynewt-nimble
>   commit 223714cb16c255cfa701929c0de6d7579bfd2cdd
>
> In addition, the following newt and newtmgr convenience binaries are
> available:
>   linux:
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.6.0/rc2/apache-mynewt-newt-bin-linux-1.6.0.tgz
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.6.0/rc2/apache-mynewt-newtmgr-bin-linux-1.6.0.tgz
>
>   osx:
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.6.0/rc2/apache-mynewt-newt-bin-osx-1.6.0.tgz
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.6.0/rc2/apache-mynewt-newtmgr-bin-osx-1.6.0.tgz
>
>   windows:
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.6.0/rc2/apache-mynewt-newt-bin-windows-1.6.0.tgz
>
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.6.0/rc2/apache-mynewt-newtmgr-bin-windows-1.6.0.tgz
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon Janc
>
>
>

Re: unstable I2C communication waveform using mynewt core 1.5.0

[Andrzej Kaczmarek]

Hi,

The images in your e-mail are missing, at least on my side - could you
please resend them or, even better, upload them somewhere and provide links?
Also if you can share target settings and possibly some code snippet where
you access I2C it could help here as well.

Best,
Andrzej




On Wed, Apr 3, 2019 at 5:17 AM GE Bingjing (BST/ESA4) <
bingjing...@cn.bosch.com> wrote:

> Hi sir:
>
>  Nice to meet you, We are from Bosch Sensortec, now we are using
> Mynewt Core 1.5.0 on Nordic nRF52840, we have question about the I2C
> communication.
>
> As you can see from the picture below, the overall result of I2C
> communication is successful, but there are  a lot of NAK before a ACK read.
>  this is due to the abnormal behavior of SCL.
>
> Do you have any suggestion on this? Do we need to change some
> configuration/Mynewt Core code to fix this?
>
>
>
>
>
>
>
> The anolog waveform of I2C communication is also not so good(shown as
> below), can we change some configuration/Mynewt Core code to improve it?
>
>
>
> Best regards,
>
>
>
> *Bingjing GE BST/ESA3.2 *
> Tel. +86 21 2218-1915
>
>

Re: Storing Bonding information in NVS memory

[Andrzej Kaczmarek]

Hi Prasad,

On Fri, Feb 15, 2019 at 1:24 PM prasad  wrote:

> Hi Chris,
>
> Currently I have been able to develop an app which is able to store bond
> information in NVS flash. If my device (ESP32) based on NIMBLE stack is
> rebooted, the bond remains intact. But if the other device is rebooted
> the ` key_sec->peer_addr.val` gets changed based on
> `key_sec->peer_addr.type = 1` (static address, random device address).
>
> As I understand, it is expected of static address type to change to new
> value, generated after each power cycle.
>

It is allowed, but not required - device may use single static address for
its lifetime.


> So in this case how to keep bond between devices intact ?
>
> If in case static address type is not to be used for bonded devices then
> why our NIMBLE stack uses static type of address even after setting
> `bonding` flag to 1 ?
>

Static address can be used to create bond, there's nothing wrong here.
However, if you or any other vendor devices decide that their device will
use new static random address after each power cycle, then it's basically
considered as a "new" device and all bonds created using previous static
address are effectively lost. There's nothing you can do here as this is
"by design". For reference, see Core 5.0 spec, Vol 6, Part B, section 1.3.6.


> Could you help me resolve this issue? Or I am missing on something obvious?
>
> Below is the snippet of code which tries to retrieve index from database
> but fails to do so since the `peer_addr.val` field has been changed.
>
> `
>
> if (ble_addr_cmp(&key_sec->peer_addr, BLE_ADDR_ANY)) {
>  if (*ble_addr_cmp(&cur->peer_addr, &key_sec->peer_addr*)) {
>  continue;
> `
>
> Regards
>
> Prasad
>

Best,
Andrzej

Re: [VOTE] Release Apache Mynewt 1.5.0-rc1

[Andrzej Kaczmarek]

+1 (binding)

Best,
Andrzej


On Tue, Oct 23, 2018 at 4:20 PM Szymon Janc  wrote:

> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.5.0.
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test
> +Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.5.0+Test+Results
>
>  Note that this testing is not yet complete and more results will show
> while voting is ongoing.
>
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.13
>* Fedora Linux 28
>
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.5.0/rc1/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit a94cfa402da18a305db2ea9afa3771ead69968fe
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit e311e78e59e71aae72679b76baea8fd9e2aa18e8
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit d8b903e11abbfe854e6601de016e755ad307a2b0
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit d38f17df9143be4729f33572fa78fe276ac09af7
>
> In addition, the following newt convenience binaries are available:
>   linux:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.5.0/
> rc1/apache-mynewt-newt-bin-linux-1.5.0.tgz
> 
>   osx:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.5.0/rc1/
> apache-mynewt-newt-bin-osx-1.5.0.tgz
> 
>   windows:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.5.0/
> rc1/apache-mynewt-newt-bin-windows-1.5.0.tgz
> 
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon Janc
>
>
>

Re: Controlled shutdown

[Andrzej Kaczmarek]

Hi Chris,

On Mon, Oct 1, 2018 at 7:39 PM Christopher Collins  wrote:

> Hi Andrzej,
>
> On Sun, Sep 30, 2018 at 08:27:19PM +0200, Andrzej Kaczmarek wrote:
> > I guess device can be powered off simply as a power saving option or
> > shipping mode so perhaps 'reason' parameter could be added to shutdown
> > call. I do not know if it really matters to any package whether we
> shutdown
> > to reset device or just to power it off, but single extra parameter won't
> > hurt.
>
> Good idea.
>
> > Return codes feel like a bit more intuitive way to do this. You don't
> > really need to use branching in shutdown code, I think of two other ways
> to
> > do this:
> > 1. create array of pointers to functions and then main shutdown code can
> > call each function and examine return codes (or, a bit more complicated
> > way, create new section where these pointers are places and shutdown code
> > can also iterate them as array)
>
> Another good idea.  I will try it out and report back!
>
> > 2. just return logical "or" of all return codes from all shutdown
> functions
> > - zero means shutdown is complete, non-zero means it's in progress (you
> can
> > make it a bitmask in case there's need to distinguish few status codes)
>
> I am having a hard time seeing how this would work.  A logical-or of the
> return codes would only tell us if at least one subprocedure is still in
> progress.  This is not enough information; we need to know exactly how
> many are still in progress so that we can determine when they have all
> completed (i.e., when the counter reaches 0).  Are you envisioning a
> solution that does not require a counter?
>

Ah, you're absolutely right. I forgot that we need to know how many
subprocedures are pending. So this option is not a solution here.

Chris
>

Best,
Andrzej

Re: Controlled shutdown

[Andrzej Kaczmarek]

Hi Chris,

The overall idea looks good to me. I just have some suggestions as below.

On Sat, Sep 29, 2018 at 1:37 AM Christopher Collins 
wrote:

> On Fri, Sep 28, 2018 at 04:18:08PM -0700, will sanfilippo wrote:
> > Some comments:
> >
> > 1) Are there are any other cases you can see for a controlled shutdown?
> I get the reset command. I am trying to think of others.
>
> I think the newtmgr reset command is the main use case (as well as the
> shell "reset" command).  It seems plausible that a device would want to
> reset itself for other reasons, but I can't think of an actual use case!
>

I guess device can be powered off simply as a power saving option or
shipping mode so perhaps 'reason' parameter could be added to shutdown
call. I do not know if it really matters to any package whether we shutdown
to reset device or just to power it off, but single extra parameter won't
hurt.


> > 2) I am curious: how do you know how many of these functions, or which
> ones, return in progress? Curious to know how you were going to implement
> that specifically.
>
> I was thinking the sysdown module would maintain a counter representing
> the number of in-progress shutdown subprocedures.  When a subprocedure
> completes, it calls `sysdown_complete()`, which decrements the counter.
> When the counter reaches 0, the system restarts.
>
> There is something else I should mention.  I now think it is a bad idea
> to use return codes to indicate whether the subprocedure is complete.
> Each subprocedure is called by generated code, and branching on return
> codes makes the generated code too complicated in my opinion.  I think
> it is better to add a new function, `sysdown_in_progress()`.  If a
> subprocedure needs to continue beyond the initial callback, it calls
> this new function before returning.
>

Return codes feel like a bit more intuitive way to do this. You don't
really need to use branching in shutdown code, I think of two other ways to
do this:
1. create array of pointers to functions and then main shutdown code can
call each function and examine return codes (or, a bit more complicated
way, create new section where these pointers are places and shutdown code
can also iterate them as array)
2. just return logical "or" of all return codes from all shutdown functions
- zero means shutdown is complete, non-zero means it's in progress (you can
make it a bitmask in case there's need to distinguish few status codes)


> Chris
>
> > Otherwise, sounds good and seems like a good addition to mynewt!
> >
> >
> > > On Sep 28, 2018, at 1:08 PM, Christopher Collins 
> wrote:
> > >
> > > Hello all,
> > >
> > > I have been looking into implementing a graceful shutdown for Mynewt.
> > > The system may want to perform a cleanup procedure immediately before
> it
> > > resets, and I wanted to allow this procedure to be configured.  I am
> > > calling this shutdown facility "sysdown", as a counterpart to
> "sysinit".
> > >
> > > ### BASIC IDEA:
> > >
> > > My idea is to allow each Mynewt package to specify a sequence of
> > > shutdown function calls, similar to a package's `pkg.init` function
> call
> > > list.  The newt tool would generate a C shutdown function called
> > > `sysdown()`.  This function would consist of calls to each package's
> > > shutdown functions.  When a controlled shutdown is initiated,
> > > `sysdown()` would be called prior to the final call to
> > > `hal_system_reset()`.
> > >
> > > To clarify, this procedure would only be performed for a controlled
> > > shutdown.  It would be executed when the system processes a newtmgr
> > > "reset" command, for example.  It would not be executed when the system
> > > crashes, browns out, or restarts due to the hardware watchdog.
> > >
> > > I think this scheme is pretty straightforward and I see no issues so
> far
> > > (but please pipe up if this doesn't seem right!).
> > >
> > > ### PROBLEM:
> > >
> > > Then I tried applying this to an actual use case, and of course I
> > > immediately encountered some problems :).
> > >
> > > My actual use case is this: when I reset the Mynewt device, I would
> like
> > > the nimble stack to gracefully terminate all open Bluetooth
> connections.
> > > This isn't strictly necessary; the connected peer will eventually
> > > realize that the connection has dropped some time after the reset.  The
> > > problem is that Android centrals take a really long time to realize
> that
> > > the connection has dropped, as described here:
> > >
> https://blog.classycode.com/a-short-story-about-android-ble-connection-timeouts-and-gatt-internal-errors-fa89e3f6a456
> .
> > > So, I wanted to explicitly terminate the connections to speed up the
> > > process.
> > >
> > > Ideally, I could configure the nimble host package with a shutdown
> > > callback that just performs a blocking terminate of each open
> > > connection in sequence.  Unfortunately, the nimble host is likely
> > > running in the same task as the one that initiated the shutdown, so it
> >

Re: NimBLE host GAP event listeners

[Andrzej Kaczmarek]

Hi,

On Mon, Sep 10, 2018 at 9:56 AM Łukasz Rymanowski <
lukasz.rymanow...@codecoup.pl> wrote:

> Hi
> On Fri, 7 Sep 2018 at 21:12, Andrzej Kaczmarek <
> andrzej.kaczma...@codecoup.pl> wrote:
>
> > Hi Chris,
> >
> > On Fri, Sep 7, 2018 at 8:00 PM Christopher Collins 
> > wrote:
> >
> > > Hello all,
> > >
> > > TL;DR: Proposal for registration of GAP event listeners in the NimBLE
> > > host.  Currently, GAP event callbacks are specified by the code which
> > > creates a connection.  This proposal allows code to listen for GAP
> > > events without creating a connection.
> > >
> > > The NimBLE host allows the application to associate callbacks with GAP
> > > events.  Callbacks are configured *per connection*.  When the
> > > application initiates a connection, it specifies a single callback to
> > > be executed for all GAP events involving the connection.  Similarly,
> > > when the application starts advertising, it specifies the callback to
> > > use with the connection that may result.
> > >
> > > This design provides some degree of modularity.  If a package
> > > independently creates a connection, it can handle all the relevant GAP
> > > events without involving other packages in the system.  However, there
> > > is a type of modularity that this does not provide: *per event*
> > > callbacks.  If a package doesn't want to initiate any GAP events, but
> > > it wants to be notified every time a connection is established (for
> > > example), there is no way to achieve this.  The problem here is that
> > > there is only a single callback associated with each connection.  What
> > > we really need is a list of callbacks that all get called whenever a
> > > GAP event occurs.
> > >
> > > My proposal is to add the following to the NimBLE host API:
> > >
> > > struct ble_gap_listener {
> > > /*** Public. */
> > > ble_gap_event_fn *fn;
> > > void *arg;
> > >
> > > /*** Internal. */
> > > STAILQ_ENTRY(ble_gap_listener) next;
> > > };
> > >
> > > /**
> > >  * @brief Registers a BLE GAP listener.
> > >  *
> > >  * When a GAP event occurs, callbacks are executed in the following
> > >  * order:
> > >  * 1. Connection-specific GAP event callback.
> > >  * 2. Each registered listener, in the order they were registered.
> > >  *
> > >  * @param listener The listener to register.
> > >  */
> > > void ble_gap_register(struct ble_gap_listener *listener);
> > >
> > > /**
> > >  * @brief Unregisters a BLE GAP listener.
> > >  *
> > >  * @param listener The listener to unregister.
> > >  *
> > >  * @return  0 on success;
> > >  *  BLE_HS_ENOENT if the listener is
> > >  *  not registered.
> > >  */
> > > int ble_gap_unregister(struct ble_gap_listener *listener);
> > >
> > > Initially, I thought this functionality could be achieved with a new
> > > package implemented on top of the host (call it `blemux`).
> > > Unfortunately, I think there are some issues that make such an approach
> > > unwieldy for the user.  I imagined such a package would be used as
> > > follows:
> > >
> > > 1. The `blemux` package exposes a GAP callback (call it
> > >`blemux_gap_event`).
> > > 2. Elsewhere in the sytem, for each GAP function call, the caller
> > >specifies `blemux_gap_event` as the callback.
> > > 3. Each package that is interested in GAP events registers one or
> > >more listeners via `blemux_register()`.
> > > 4. When a GAP event occurs, `blemux_gap_event` is executed.  This
> > >callback executes every registered listener.
> > >
> > > The problem is that packages have no guarantee that the app is using
> > > blemux.  A package can depend on `blemux` and can register listeners,
> > > but it really only works if every other BLE-aware package in the system
> > > also uses `blemux`.  If any package doesn't use `blemux`, then the GAP
> > > procedures that it initiates won't be reported to the `blemux`
> > > listeners.  A secondary problem is that this just feels like a clumsy
&

Re: NimBLE host GAP event listeners

[Andrzej Kaczmarek]

Hi Chris,

On Fri, Sep 7, 2018 at 8:00 PM Christopher Collins  wrote:

> Hello all,
>
> TL;DR: Proposal for registration of GAP event listeners in the NimBLE
> host.  Currently, GAP event callbacks are specified by the code which
> creates a connection.  This proposal allows code to listen for GAP
> events without creating a connection.
>
> The NimBLE host allows the application to associate callbacks with GAP
> events.  Callbacks are configured *per connection*.  When the
> application initiates a connection, it specifies a single callback to
> be executed for all GAP events involving the connection.  Similarly,
> when the application starts advertising, it specifies the callback to
> use with the connection that may result.
>
> This design provides some degree of modularity.  If a package
> independently creates a connection, it can handle all the relevant GAP
> events without involving other packages in the system.  However, there
> is a type of modularity that this does not provide: *per event*
> callbacks.  If a package doesn't want to initiate any GAP events, but
> it wants to be notified every time a connection is established (for
> example), there is no way to achieve this.  The problem here is that
> there is only a single callback associated with each connection.  What
> we really need is a list of callbacks that all get called whenever a
> GAP event occurs.
>
> My proposal is to add the following to the NimBLE host API:
>
> struct ble_gap_listener {
> /*** Public. */
> ble_gap_event_fn *fn;
> void *arg;
>
> /*** Internal. */
> STAILQ_ENTRY(ble_gap_listener) next;
> };
>
> /**
>  * @brief Registers a BLE GAP listener.
>  *
>  * When a GAP event occurs, callbacks are executed in the following
>  * order:
>  * 1. Connection-specific GAP event callback.
>  * 2. Each registered listener, in the order they were registered.
>  *
>  * @param listener The listener to register.
>  */
> void ble_gap_register(struct ble_gap_listener *listener);
>
> /**
>  * @brief Unregisters a BLE GAP listener.
>  *
>  * @param listener The listener to unregister.
>  *
>  * @return  0 on success;
>  *  BLE_HS_ENOENT if the listener is
>  *  not registered.
>  */
> int ble_gap_unregister(struct ble_gap_listener *listener);
>
> Initially, I thought this functionality could be achieved with a new
> package implemented on top of the host (call it `blemux`).
> Unfortunately, I think there are some issues that make such an approach
> unwieldy for the user.  I imagined such a package would be used as
> follows:
>
> 1. The `blemux` package exposes a GAP callback (call it
>`blemux_gap_event`).
> 2. Elsewhere in the sytem, for each GAP function call, the caller
>specifies `blemux_gap_event` as the callback.
> 3. Each package that is interested in GAP events registers one or
>more listeners via `blemux_register()`.
> 4. When a GAP event occurs, `blemux_gap_event` is executed.  This
>callback executes every registered listener.
>
> The problem is that packages have no guarantee that the app is using
> blemux.  A package can depend on `blemux` and can register listeners,
> but it really only works if every other BLE-aware package in the system
> also uses `blemux`.  If any package doesn't use `blemux`, then the GAP
> procedures that it initiates won't be reported to the `blemux`
> listeners.  A secondary problem is that this just feels like a clumsy
> API.  It is confusing and error prone to need to specify
> `blemux_gap_event` as the GAP event callback.
>
> So, I think this functionality should be implemented directly in the
> host.
>

Sounds exactly like something I wrote some time ago, so I can only agree
with above :-)
Typical scenario here (and what I was doing) is that external package, like
service, wants to be notified about connection or characteristic
subscription state. Currently we do this by exposing extra API from package
which app needs to call from GAP callbacks in order to everything work
properly. It works, but it's really clunky. Hooks provided by host are imo
good way to handle this.

I did not finish my service so forgot to send a PR with NimBLE changes, but
here they are for reference - I can create PR if they look ok.
https://github.com/andrzej-kaczmarek/apache-mynewt-nimble/commit/6cc902821e6d65fbd5f72fa89e7219915afca38d

The API is pretty much the same as proposed. The difference is that
listener struct is opaque and fields are initialized when listener is
registered.
Notified events are the ones which are notifications, i.e. do not require
interaction from app (so e.g. pairing event does not call listeners since
it does not make sense to do so).


> Thoughts?
>
> Thanks,
> Chris
>

Best,
Andrzej

Re: I2C retries

[Andrzej Kaczmarek]

Hi all,

Seems like the majority already voted to go for retries in HAL, but
I'll add my opinion anyway: I do not think HAL is proper place to
include such logic.
I think HAL should only provide interfaces to hide differences between
underlying MCU hardware while read/write retry logic is something
driver should do (or any caller in general) since it can decide when
and if it makes sense to retry. This is what common error codes (so
#1) would allow to do. This does not however mean we can't have common
retry code. What we likely need is some bus-level driver/layer that
drivers will use instead of HAL directly so it can take care of
handling multiple devices on the same bus seamlessly (in general) and
also it would be the place where we can put extra common logic if
needed (like retries).

Best,
Andrzej



On Thu, Aug 30, 2018 at 3:59 AM Christopher Collins  wrote:
>
> Hello all,
>
> I noticed the HAL master I2C API does not include any retry logic.  As
> you probably know, in I2C, the default state of the SCL line is NACK.
> This means an unresponsive peripheral is indistinguishable from one that
> is actively nacking the master's writes.  If the master's writes are
> being NACKed because the slave is simply not ready to receive data, then
> retrying seems like the appropriate solution.
>
> I can think of two ways to add I2C retries.  Each of them requires
> changes:
>
> (1) Delegate the retry logic to the code calling into the HAL (e.g.,
> drivers).
> (2) Implement retry logic directly in the HAL.
>
> The problem with (1) is that HAL implementations currently return
> MCU-specific error codes.  A generic driver cannot determine if a retry
> is in order just from inspecting the error code.  If there were a common
> set of error codes that all HAL I2C implementations returned, drivers
> would have the information they need.  Actually, even ignoring the
> subject of retries, I think common error codes here makes sense.
>
> Re: (2) - I was thinking this could be implemented by adding two new
> members to the `hal_i2c_master_data` struct that gets passed to every
> master I2C function:
>
> /**
>  * Total number of times to attempt the I2C operation.  Certain
>  * failures get retried:
>  * o NACK received after sending address.
>  * o (if configured) NACK received after sending data byte.
>  */
> uint8_t tries;
>
> /** Whether to retry when a data byte gets NACKed. */
> uint8_t retry_on_dnack:1;
>
> (I hate to complicate things with the `retry_on_dnack` member, but some
> peripherals seem to become unresponsive in the middle of a transaction.)
>
> Since these additions are members of a struct, rather than new function
> parameters, this change would be mostly backwards-compatible.  There is
> still a problem here, though: code that doesn't zero-out the
> `hal_i2c_master_data` struct will likely get retries when it isn't
> expecting them, which could conceivably be a problem.
>
> I am leaning towards (1).  Thoughts?
>
> Thanks,
> Chris

Re: [RFC] BSP rename for Nordic dev kit

[Andrzej Kaczmarek]

Hi Jacob,

I would also like to keep old names at least for upcoming release, but
my main concern here is that at the moment the only way to do this is
to have duplicated code which I don't really like. We had this already
for BLE sample apps and it created a lot of confusion.
However, I am trying to extend newt so it will be possible to create
dummy package which only links to other package (simple dependency
won't work here) and thus we can keep old names linked to new names.
This could be useful in general so we can move packages and let newt
emit a clear warning that package name has changed and settings should
be updated. I hope I can push some working PR soon for testing...

Best,
Andrzej


On Wed, Aug 22, 2018 at 5:22 PM Jacob Rosenthal  wrote:
>
> Sounds good to me. Though Id say it might make sense to keep old names
> around with the compat mcu for a release or something? With some
> deprecation message and no updates for that cycle, and have the new names
> with the new mcu
>
> On Wed, Aug 22, 2018 at 7:50 AM Miguel Azevedo 
> wrote:
>
> > I agree that we should use the board name instead of the kit name, if dk is
> > the same board as pdk.
> >
> > On Wed, 22 Aug 2018, 15:12 Andrzej Kaczmarek, <
> > andrzej.kaczma...@codecoup.pl>
> > wrote:
> >
> > > Hi all,
> > >
> > > Since nRF52840 DK is available for quite some time now, I was going to
> > > rename "nrf52840pdk" to "nrf52840dk" so it matches current version.
> > > However, it is a good moment to change naming scheme for all dev kits
> > > from Nordic and use board name (e.g. PCA10056) instead of dev kit name
> > > (e.g. nRF52840 DK). There are at least two good reasons for this:
> > >
> > > 1. avoid possible renames in future once new revision of dev kit is
> > > launched (PDK -> DK) since this is the same board, just with a
> > > different revision
> > > 2. make selection of proper BSP easier since each board has its name
> > > clearly visible on a sticker (note that BSP description states both
> > > names)
> > >
> > > I created a PR which does such rename:
> > > https://github.com/apache/mynewt-core/pull/1348
> > >
> > > Thoughs? Are there any good reasons why we should not rename it?
> > > (except for historical reasons :P)
> > >
> > > Best,
> > > Andrzej
> > >
> >

[RFC] BSP rename for Nordic dev kit

[Andrzej Kaczmarek]

Hi all,

Since nRF52840 DK is available for quite some time now, I was going to
rename "nrf52840pdk" to "nrf52840dk" so it matches current version.
However, it is a good moment to change naming scheme for all dev kits
from Nordic and use board name (e.g. PCA10056) instead of dev kit name
(e.g. nRF52840 DK). There are at least two good reasons for this:

1. avoid possible renames in future once new revision of dev kit is
launched (PDK -> DK) since this is the same board, just with a
different revision
2. make selection of proper BSP easier since each board has its name
clearly visible on a sticker (note that BSP description states both
names)

I created a PR which does such rename:
https://github.com/apache/mynewt-core/pull/1348

Thoughs? Are there any good reasons why we should not rename it?
(except for historical reasons :P)

Best,
Andrzej

Re: [RFC] Peripherals cleanup in nRF52xxx BSPs

[Andrzej Kaczmarek]

Hi,

Since there were no objections here and PR was reviewed and approved, it
has been merged. This means if anyone has any out-of-tree BSP based on
nR52xxx, you will need to either temporarily switch it to use
"hw/mcu/nordic/nrf52xxx-compat" package or make necessary adjustments in
BSP.
I will update all BSPs in mynewt-core in separate PR(s), for now they use
compat package.

Best,
Andrzej


On Fri, Aug 3, 2018 at 1:02 PM Andrzej Kaczmarek <
andrzej.kaczma...@codecoup.pl> wrote:

> Hi all,
>
> It was discussed before [1] that MCU peripherals should be defined in
> hw/mcu package instead of hw/bsp. Seems like everyone agreed on this, but
> as far as I see everything is still unfortunately mixed between both
> packages. I experienced this when trying to create new BSP for some eval
> board I
>  use... there's a lot of duplicated code created by c&p, settings are
> defined in different packages which is confusing and makes BSPs
> inconsistent in terms of which peripherals can be used (even though they
> share the same MCU). So I created this RFC instead...
>
>
> What changed:
> * A
> ll syscfg settings
>  related to MCU are *defined* in hw/mcu package and then their *values*
> are overridden in BSP.
>  Previously we had (some) peripherals defined in hw/mcu package and their
> configuration settings (like pins) defined in hw/bsp so basically each BSP
> could have own names for these settings (they did not due to c&p but many
> BSPs are lacking settings for peripherals). Package-level restrictions are
> added to make sure enabled peripherals are configured properly (i.e. have
> pins assigned).
>
> * hw/mcu package defines syscfg settings which BSP shall override to
> specify which MCU it uses. This is used at the moment to enforce
> package-level restrictions. I know there are already similar symbols in
> BSPs, but the problem is again that they are defined in each hw/bsp
> packages instead of being defined in one place and then have values
> overridden.
>
> * Common code to create and init devices for peripherals is added to
> hw/mcu package and hal_bsp_init() just calls this function to ensure each
> BSP provides the same devices, as configured
> .
> * Soft PWM is left as a part of BSP
> .
> * Bit-banger UART is left as a part of BSP. Previously nRF52832 BSPs
> created uart1 device as bit-banger UART but this does not seem right to me
> since this is not a regular MCU UART, so updated BSPs create bit-banger
> UART as uartbb0 device instead (uart1 is reserved for UART1 on nRF52840).
>
> The most obvious problem here is that existing BSPs do not build with
> refactored hw/mcu package and probably we should allow users to transition
> smoothly to new package. For this reason I created an exact copy of
> pre-refactor package and called it nrf52xxx-compat so updating BSP to 1.5
> will just require changing dependency. After 1.5 release we remove compat
> package and force all users to switch to new nrf52xxx on 1.6. I know this
> just duplicates existing code, but I do not have any better idea here and I
> would prefer to avoid creating some nasty glue layers which will eventually
> transform one mess into another.
>
> For now I updated nrf52dk and nrf52840pdk packages and if these changes
> are accepted I can update all BSPs in core.
>
> Here's PR: https://github.com/apache/mynewt-core/pull/1313.
> Comments?
>
> [1]
> http://mail-archives.apache.org/mod_mbox/mynewt-dev/201802.mbox/%3CC7D6A5CB-3D7F-4541-BB7B-035EB2DC98D6%40runtime.io%3E
>
> Best,
> Andrzej
>
>

[RFC] Peripherals cleanup in nRF52xxx BSPs

[Andrzej Kaczmarek]

Hi all,

It was discussed before [1] that MCU peripherals should be defined in
hw/mcu package instead of hw/bsp. Seems like everyone agreed on this, but
as far as I see everything is still unfortunately mixed between both
packages. I experienced this when trying to create new BSP for some eval
board I
 use... there's a lot of duplicated code created by c&p, settings are
defined in different packages which is confusing and makes BSPs
inconsistent in terms of which peripherals can be used (even though they
share the same MCU). So I created this RFC instead...


What changed:
* A
ll syscfg settings
 related to MCU are *defined* in hw/mcu package and then their *values* are
overridden in BSP.
 Previously we had (some) peripherals defined in hw/mcu package and their
configuration settings (like pins) defined in hw/bsp so basically each BSP
could have own names for these settings (they did not due to c&p but many
BSPs are lacking settings for peripherals). Package-level restrictions are
added to make sure enabled peripherals are configured properly (i.e. have
pins assigned).

* hw/mcu package defines syscfg settings which BSP shall override to
specify which MCU it uses. This is used at the moment to enforce
package-level restrictions. I know there are already similar symbols in
BSPs, but the problem is again that they are defined in each hw/bsp
packages instead of being defined in one place and then have values
overridden.

* Common code to create and init devices for peripherals is added to hw/mcu
package and hal_bsp_init() just calls this function to ensure each BSP
provides the same devices, as configured
.
* Soft PWM is left as a part of BSP
.
* Bit-banger UART is left as a part of BSP. Previously nRF52832 BSPs
created uart1 device as bit-banger UART but this does not seem right to me
since this is not a regular MCU UART, so updated BSPs create bit-banger
UART as uartbb0 device instead (uart1 is reserved for UART1 on nRF52840).

The most obvious problem here is that existing BSPs do not build with
refactored hw/mcu package and probably we should allow users to transition
smoothly to new package. For this reason I created an exact copy of
pre-refactor package and called it nrf52xxx-compat so updating BSP to 1.5
will just require changing dependency. After 1.5 release we remove compat
package and force all users to switch to new nrf52xxx on 1.6. I know this
just duplicates existing code, but I do not have any better idea here and I
would prefer to avoid creating some nasty glue layers which will eventually
transform one mess into another.

For now I updated nrf52dk and nrf52840pdk packages and if these changes are
accepted I can update all BSPs in core.

Here's PR: https://github.com/apache/mynewt-core/pull/1313.
Comments?

[1]
http://mail-archives.apache.org/mod_mbox/mynewt-dev/201802.mbox/%3CC7D6A5CB-3D7F-4541-BB7B-035EB2DC98D6%40runtime.io%3E

Best,
Andrzej

Re: Old versions of newt tool in apt repo

[Andrzej Kaczmarek]

Hi,

On Fri, Jul 13, 2018 at 9:40 AM Simon Ratner  wrote:
>
> 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 https://raw.githubusercontent.com/runtimeco/debian-mynewt/master latest
> main
>
> $ apt-cache showpkg newt
> Package: newt
> Versions:
> 1.4.1-1
> (/var/lib/apt/lists/raw.githubusercontent.com_runtimeco_debian-mynewt_master_dists_latest_main_binary-amd64_Packages)
> Reverse Depends:
> Dependencies:
> 1.4.1-1 - libc6 (2 2.3.2)
> Provides:
> 1.4.1-1 -
>
> Any suggestions on getting 1.3.0 back, other than building from a source
> tag?

You can grab binary release from here:
http://www.apache.org/dist/mynewt/apache-mynewt-1.3.0/

> Cheers,
> simon

Best,
Andrzej

Re: BLE security/encryption/passkey authentication

[Andrzej Kaczmarek]

FYI: seems like it works fine if you enter passkey with leading zeroes
in Android (e.g. "001234" instead of "1234"). Not sure why it works
like this as passkey is handled as integer value during pairing
process, but Android is apparently full of surprises ;-)

Best,
Andrzej

On Mon, Jul 9, 2018 at 11:49 PM Andrzej Kaczmarek
 wrote:
>
> Hi,
>
> You code looks ok. However, I noticed strange thing when testing with
> Android phone on my side: pairing fails if specified passkey has less
> than 6 digits (i.e. <10). This does not seem to be issue in NimBLE
> since the same happens when trying to pair Android with BlueZ while
> pairing between NimBLE and BlueZ works just fine. Looks like some
> issue in Android LE SC implementation tbh...
>
> So please try with 6 digits passkey (i.e. >=10) and it should work.
>
> Best,
> Andrzej
>
>
> On Mon, Jul 9, 2018 at 12:08 PM Amr Bekhit  wrote:
> >
> > Hi Andrzej,
> >
> > Below is my GAP event callback function and the console output when I
> > attempt to bond with my device (I'm using the Nordic nRF Connect app
> > on my phone to interact with the device):
> >
> > static int bleprph_gap_event(struct ble_gap_event *event, void *arg) {
> > int rc = 0;
> >
> > switch(event->type) {
> > case BLE_GAP_EVENT_CONNECT:
> > console_printf("Connected\n");
> > break;
> >
> > case BLE_GAP_EVENT_DISCONNECT:
> > console_printf("Disconnected\n");
> > ble_advertise();
> > break;
> >
> > case BLE_GAP_EVENT_CONN_UPDATE:
> > console_printf("Connection updated\n");
> > break;
> >
> > case BLE_GAP_EVENT_CONN_UPDATE_REQ:
> > console_printf("Connection update requested\n");
> > break;
> >
> > case BLE_GAP_EVENT_PASSKEY_ACTION: {
> > console_printf("Passkey Request. Action: %d, Numcmp: %lu\n",
> > event->passkey.params.action,
> > event->passkey.params.numcmp);
> >
> > if (event->passkey.params.action == BLE_SM_IOACT_DISP) {
> > struct ble_sm_io pk;
> > pk.action = event->passkey.params.action;
> > pk.passkey = 4539;
> > rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
> > console_printf("ble_sm_inject_io result: %d\n", rc);
> > }
> > break;
> > }
> >
> > default:
> > console_printf("GAP Event: %i\n", event->type);
> > }
> >
> > return rc;
> > }
> >
> > 001039 Passkey Request. Action: 3, Numcmp: 0
> > 001040 ble_sm_inject_io result: 0
> > 001639 GAP Event: 10
> > 002037 Connection updated
> > 002037 Disconnected
> >
> > On the phone, I get requested for a pin number and I enter 4539. After
> > that, the end device just disconnects from the bluetooth.

Re: BLE security/encryption/passkey authentication

[Andrzej Kaczmarek]

Hi,

There is no such method to protect services from being discovered, but
this is "by design" as per Bluetooth Core spec [1]. As you said, you
can just protect access on characteristic level by combining
BLE_GATT_CHR_F_XXX_ENC (requires encryption, allows unauthenticated
key) and BLE_GATT_CHR_F_XXX_AUTHEN (requires encryption and
authenticated key) flags.

[1] Core 5.0, Vol 3, Part G, Section 8.1: "The list of services and
characteristics that a device supports is not considered private or
confidential information, and therefore the Service and Characteristic
Discovery procedures shall always be permitted."

Best,
Andrzej


On Tue, Jul 10, 2018 at 10:06 AM Amr Bekhit  wrote:
>
> I've experimented some more. If I declare a characteristic with the
> BLE_GATT_CHR_F_XXX_ENC flags, then accessing that characteristic
> prompts me for a pin code, and if I connect from a previously bonded
> profile, then no pin is requested (as expected). So this seems to work
> fine, in that I can pin code-protect certain characteristics of a
> service and require a pin to access them. However, is it possible to
> pin code-protect connections from the advertising stage? Because at
> the moment, any device can connect to and query the services and
> characteristics of the end device.
>
> Amr
> On Tue, 10 Jul 2018 at 10:12, Amr Bekhit  wrote:
> >
> > Hi Andrzej,
> >
> > Thank you - that does indeed work.
> >
> > I have another question. Bonding now works (i.e. using the nRF52
> > Connect app on Android, I connect to the advertising end device and
> > then bond with it to save the credentials), however I would also like
> > to configure the end device so that it requires a pin when connecting
> > to the advertising device. How would this be realised using Nimble?
> >
> > Thanks
> >
> > Amr
> > On Tue, 10 Jul 2018 at 00:50, Andrzej Kaczmarek
> >  wrote:
> > >
> > > Hi,
> > >
> > > You code looks ok. However, I noticed strange thing when testing with
> > > Android phone on my side: pairing fails if specified passkey has less
> > > than 6 digits (i.e. <10). This does not seem to be issue in NimBLE
> > > since the same happens when trying to pair Android with BlueZ while
> > > pairing between NimBLE and BlueZ works just fine. Looks like some
> > > issue in Android LE SC implementation tbh...
> > >
> > > So please try with 6 digits passkey (i.e. >=10) and it should work.
> > >
> > > Best,
> > > Andrzej
> > >
> > >
> > > On Mon, Jul 9, 2018 at 12:08 PM Amr Bekhit  wrote:
> > > >
> > > > Hi Andrzej,
> > > >
> > > > Below is my GAP event callback function and the console output when I
> > > > attempt to bond with my device (I'm using the Nordic nRF Connect app
> > > > on my phone to interact with the device):
> > > >
> > > > static int bleprph_gap_event(struct ble_gap_event *event, void *arg) {
> > > > int rc = 0;
> > > >
> > > > switch(event->type) {
> > > > case BLE_GAP_EVENT_CONNECT:
> > > > console_printf("Connected\n");
> > > > break;
> > > >
> > > > case BLE_GAP_EVENT_DISCONNECT:
> > > > console_printf("Disconnected\n");
> > > > ble_advertise();
> > > > break;
> > > >
> > > > case BLE_GAP_EVENT_CONN_UPDATE:
> > > > console_printf("Connection updated\n");
> > > > break;
> > > >
> > > > case BLE_GAP_EVENT_CONN_UPDATE_REQ:
> > > > console_printf("Connection update requested\n");
> > > > break;
> > > >
> > > > case BLE_GAP_EVENT_PASSKEY_ACTION: {
> > > > console_printf("Passkey Request. Action: %d, Numcmp: %lu\n",
> > > > event->passkey.params.action,
> > > > event->passkey.params.numcmp);
> > > >
> > > > if (event->passkey.params.action == BLE_SM_IOACT_DISP) {
> > > > struct ble_sm_io pk;
> > > > pk.action = event->passkey.params.action;
> > > > pk.passkey = 4539;
> > > > rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
> > > > console_printf("ble_sm_inject_io result: %d\n", rc);
> > > > }
> > > > break;
> > > > }
> > > >
> > > > default:
> > > > console_printf("GAP Event: %i\n", event->type);
> > > > }
> > > >
> > > > return rc;
> > > > }
> > > >
> > > > 001039 Passkey Request. Action: 3, Numcmp: 0
> > > > 001040 ble_sm_inject_io result: 0
> > > > 001639 GAP Event: 10
> > > > 002037 Connection updated
> > > > 002037 Disconnected
> > > >
> > > > On the phone, I get requested for a pin number and I enter 4539. After
> > > > that, the end device just disconnects from the bluetooth.

Re: BLE security/encryption/passkey authentication

[Andrzej Kaczmarek]

Hi,

You code looks ok. However, I noticed strange thing when testing with
Android phone on my side: pairing fails if specified passkey has less
than 6 digits (i.e. <10). This does not seem to be issue in NimBLE
since the same happens when trying to pair Android with BlueZ while
pairing between NimBLE and BlueZ works just fine. Looks like some
issue in Android LE SC implementation tbh...

So please try with 6 digits passkey (i.e. >=10) and it should work.

Best,
Andrzej


On Mon, Jul 9, 2018 at 12:08 PM Amr Bekhit  wrote:
>
> Hi Andrzej,
>
> Below is my GAP event callback function and the console output when I
> attempt to bond with my device (I'm using the Nordic nRF Connect app
> on my phone to interact with the device):
>
> static int bleprph_gap_event(struct ble_gap_event *event, void *arg) {
> int rc = 0;
>
> switch(event->type) {
> case BLE_GAP_EVENT_CONNECT:
> console_printf("Connected\n");
> break;
>
> case BLE_GAP_EVENT_DISCONNECT:
> console_printf("Disconnected\n");
> ble_advertise();
> break;
>
> case BLE_GAP_EVENT_CONN_UPDATE:
> console_printf("Connection updated\n");
> break;
>
> case BLE_GAP_EVENT_CONN_UPDATE_REQ:
> console_printf("Connection update requested\n");
> break;
>
> case BLE_GAP_EVENT_PASSKEY_ACTION: {
> console_printf("Passkey Request. Action: %d, Numcmp: %lu\n",
> event->passkey.params.action,
> event->passkey.params.numcmp);
>
> if (event->passkey.params.action == BLE_SM_IOACT_DISP) {
> struct ble_sm_io pk;
> pk.action = event->passkey.params.action;
> pk.passkey = 4539;
> rc = ble_sm_inject_io(event->passkey.conn_handle, &pk);
> console_printf("ble_sm_inject_io result: %d\n", rc);
> }
> break;
> }
>
> default:
> console_printf("GAP Event: %i\n", event->type);
> }
>
> return rc;
> }
>
> 001039 Passkey Request. Action: 3, Numcmp: 0
> 001040 ble_sm_inject_io result: 0
> 001639 GAP Event: 10
> 002037 Connection updated
> 002037 Disconnected
>
> On the phone, I get requested for a pin number and I enter 4539. After
> that, the end device just disconnects from the bluetooth.

Re: BLE security/encryption/passkey authentication

[Andrzej Kaczmarek]

Hi,

On Mon, Jul 9, 2018 at 10:49 AM Amr Bekhit  wrote:
>
> I've been playing around further. After including the
> @apache-mynewt-nimble/nimble/host/store/config package, when
> attempting to bond via my phone I now get request for a passkey (I've
> configured the bluetooth device to indicate that it has a display
> only). I'm trying to figure out how to tell the nimble stack what the
> passkey is. When the BLE GAP callback function is called with
> BLE_GAP_EVENT_PASSKEY_ACTION, I've tried to use the ble_sm_inject_io
> function to specify a passkey, but this doesn't seem to have any
> effect - the bonding still fails. Any thoughts?

ble_sm_inject_io() is the proper call to use here. Can you share some
code snippet how do you handle event and call this?

Best,
Andrzej


> On Fri, 6 Jul 2018 at 15:43, Amr Bekhit  wrote:
> >
> > Hello all,
> >
> > Is there any documentation regarding the security aspects of Nimble
> > (.e.g pairing, bonding, passkeys etc)? The mynewt documentation covers
> > the basic advertising and GATT systems quite well, and am happily
> > using those, but I'm struggling to find any information on the
> > security side of things.
> >
> > Amr

Re: newtmgr fs command fails in sim

[Andrzej Kaczmarek]

Hi,

On Fri, Jul 6, 2018 at 6:24 PM marko kiiskila  wrote:
>
>
>
> > On Jul 6, 2018, at 5:49 PM, Kevin Townsend  
> > wrote:
> >
> > Hi Chris,
> >> The error codes that come back in newtmgr responses are always (or at
> >> least should be) MGMT_ERR codes:
> >> https://github.com/apache/mynewt-core/blob/42bb5acc2f049d346c81f25e8c354bc3c6afefd4/mgmt/mgmt/include/mgmt/mgmt.h#L65
> >>
> >> `MGMT_ERR_ENOENT` is indicated when the newtmgr command isn't recognized
> >> (it is also used for other conditions; seems like we should have a
> >> dedicated error code for "command not supported).
> > Thanks for the point, and the quick reply!
> >
> > Command not supported would be more helpful, yes, but not a major problem.
> >> Did you enable the `FS_NMGR` syscfg setting?
> > That was indeed the problem. I did dig through the various packages looking 
> > at the CFG values, but didn't notice that one. Works great in the sim now 
> > with:
> >
> > # Enable newtmgr commands.
> > STATS_NEWTMGR: 1  # Enable stats over newtmgr
> > LOG_NEWTMGR: 1# Enable log over newtmgr
> > CONFIG_NEWTMGR: 1 # Enable config over newtmgr
> > FS_NMGR: 1# Enable 'fs' access from newtmgr
> >
> > It's a shame the naming is sort of inconsistent (inner OCD self speaking), 
> > but that's a minor detail. :P
> >
>
> I know what you mean. There’s other examples of the same. But then renaming 
> these would
> break people’s build targets. Which is not nice :)
>
> Although I guess we could do this if we gave people enough warning.

We can introduce new setting and set its default value to old setting, i.e.:

syscfg.defs:
FS_NEWTMGR:
value: 'MYNEWT_VAL_FS_NMGR'

This way people can continue using old settings for now and then
transition to new settings. Would be good if old value can be marked
as deprecated and newt would emit warning if deprecated setting is
overriden in other package.

I did similar change in RTT already:
https://github.com/apache/mynewt-core/commit/67c430c5ecc8ac06af256e5d1bd487d3b6efdedc

Best,
Andrzej

Re: HCI UART with console UART

[Andrzej Kaczmarek]

Hi,

You need to configure different UARTs for HCI transport and console:
- BLE_HCI_UART_PORT
- CONSOLE_UART_DEV

By default both use UART0.

Best,
Andrzej

On Thu, Jun 28, 2018 at 3:18 AM Jeff Belz  wrote:
>
> All:
>
> I have to use uart0 as the HCI, but I want to use the console too.   Anyone 
> do this before?
> I'm assuming I have to change the BSP, but I think it's more that that.
>
> Jeff

Re: Different Bluetooth controller

[Andrzej Kaczmarek]

Hi Jeff,

In general, NimBLE host does assume that (depending on features
enabled) certain functionality has to be supported by controller and
it will just try to use it. For example, if Privacy feature is enabled
host assumes that Link Layer Privacy is supported by controller thus
at least 4.2 controller is required for this to work properly. Anyway,
common functions work with 4.1 or even 4.0 controllers - just make
sure to disable all features that controller does not support. On
certain cheap controllers there may be issues during initialization as
they may not like our settings, but that we can usually fix easily.

Best,
Andrzej


On Thu, Jun 28, 2018 at 1:29 AM Jeff Belz  wrote:
>
> All:
>
> I was wondering how mynewt handles different controller.  For example
> CC2564b vs BCM43438
> Both of these have a 4 wire HCI interface, but I would think they would have 
> slightly different command sets.  When working with HCI, is there a list of 
> qualified BT controllers it works with?
>
> Jeff

Re: bleprph using HCI 4 wire

[Andrzej Kaczmarek]

Hi Jeff,

It seems you have explicit dependency to net/nimble/transport/ram
somewhere in your configuration (target, I suppose) which you need to
remove. bleprph app already includes net/nimble/transport package
which pulls proper HCI transport package depending on
BLE_HCI_TRANSPORT_* syscfg values and with settings you mentioned in
1st post it will automatically pull net/nimble/transport/uart.

bleuart is not updated to use meta-package for HCI transport so in
order to use it with different HCI transport you will need to manually
remove both net/nimble/controller and net/nimble/transport/ram
packages from its pkg.yml. Also there seem to be some includes from
both of these packages in main.c which are probably not needed and
should be removed as otherwise it won't build.

Best,
Andrzej


On Wed, Jun 27, 2018 at 10:03 PM Jeff Belz  wrote:
>
> Nimble error?
> I have tried the bleprph and bleuart  and both fail at this point in the 
> ble_hci_ram.c
>
> assert(ble_hci_ram_rx_cmd_ll_cb != NULL);
>
> Either I'm missing a setting or maybe an error in Nimble
>
> /This is the whole trace
> #12 0x08020b30 in os_eventq_run (evq=) at 
> repos/apache-mynewt-core/kernel/os/src/os_eventq.c:162
> 162 ev->ev_cb(ev);
> (gdb)
> #11 0x08025c12 in ble_hs_event_start (ev=) at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:498
> 498 rc = ble_hs_start();
> (gdb)
> #10 0x08025bf6 in ble_hs_start () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:563
> 563 ble_hs_sync();
> (gdb)
> #9  0x08025966 in ble_hs_sync () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs.c:325
> 325 rc = ble_hs_startup_go();
> (gdb)
> #8  0x0802800e in ble_hs_startup_go () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_startup.c:341
> 341 rc = ble_hs_startup_reset_tx();
> (gdb)
> #7  0x08027d52 in ble_hs_startup_reset_tx () at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_startup.c:326
> 326 rc = 
> ble_hs_hci_cmd_tx_empty_ack(BLE_HCI_OP(BLE_HCI_OGF_CTLR_BASEBAND,
> (gdb)
> #6  0x0802696a in ble_hs_hci_cmd_tx_empty_ack (opcode=opcode@entry=3075, 
> cmd=cmd@entry=0x0,
> cmd_len=cmd_len@entry=0 '\000') at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci.c:332
> 332 rc = ble_hs_hci_cmd_tx(opcode, cmd, cmd_len, NULL, 0, NULL);
> (gdb)
> #5  0x08026906 in ble_hs_hci_cmd_tx (opcode=, 
> cmd=cmd@entry=0x0, cmd_len=,
> evt_buf=evt_buf@entry=0x0, evt_buf_len=evt_buf_len@entry=0 '\000', 
> out_evt_buf_len=out_evt_buf_len@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci.c:294
> 294 rc = ble_hs_hci_cmd_send_buf(opcode, cmd, cmd_len);
> (gdb)
> #4  0x08026efc in ble_hs_hci_cmd_send_buf (opcode=opcode@entry=3075, 
> buf=buf@entry=0x0,
> buf_len=buf_len@entry=0 '\000') at 
> repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:122
> 122 return ble_hs_hci_cmd_send(opcode, buf_len, buf);
> (gdb)
> #3  0x08026d0e in ble_hs_hci_cmd_send (opcode=opcode@entry=3075, 
> len=len@entry=0 '\000', cmddata=cmddata@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:90
> 90  rc = ble_hs_hci_cmd_transport(buf);
> (gdb)
> #2  0x08026c9e in ble_hs_hci_cmd_transport (cmdbuf=cmdbuf@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/host/src/ble_hs_hci_cmd.c:42
> 42  rc = ble_hci_trans_hs_cmd_tx(cmdbuf);
> (gdb)
> #1  0x0802e834 in ble_hci_trans_hs_cmd_tx (cmd=cmd@entry=0x0)
> at repos/apache-mynewt-nimble/nimble/transport/ram/src/ble_hci_ram.c:89
> 89  assert(ble_hci_ram_rx_cmd_ll_cb != NULL);
> (gdb)
> #0  __assert_func (file=file@entry=0x0, line=line@entry=0, 
> func=func@entry=0x0, e=e@entry=0x0)
> at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:137
> 137asm("bkpt");
>
> -Original Message-
> From: Christopher Collins 
> Sent: Monday, June 25, 2018 11:25 PM
> To: dev@mynewt.apache.org
> Subject: Re: bleprph using HCI 4 wire
>
> Hi Jeff,
>
> My responses are inline.
>
> On Tue, Jun 26, 2018 at 02:11:46AM +, Jeff Belz wrote:
> > All:
> >
> >
> > I'm using a BroadCom(Cypress)43438 Bluetooth chip that receives a 4
> > wire HCI.  I got one response that said I just have to change the
> > syscfg setting in my target to
> >
> >
> >
> > BLE_HCI_TRANSPORT_NIMBLE_BUILTIN: 0
> > BLE_HCI_TRANSPORT_UART: 1
> >
> >   1.  I can't find any documentation to what these lines do?
>
> The documentation for syscfg settings is in the packages themselves.
> Both of the above settings are defined by the 
> @apache-mynewt-nimble/nimble/transport package.  You can see the full list of 
> settings in a project, along with their descriptions, with this
> command:
>
> newt target config show 
>
> However, I don't think you will see either of these settings if you execute 
> this command.  From the dependency list you quoted, it looks like you are 
> using an older version of Mynewt which 

Re: [VOTE] Release Apache Mynewt 1.4.1-rc1

[Andrzej Kaczmarek]

Hi,

+1 (binding)

Best,
Andrzej

On Fri, Jun 22, 2018 at 4:14 PM Szymon Janc  wrote:
>
> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.4.1.
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> This is a bugfix only release fixing BLE connection creation in central role
> on Nordic nRF51, flashing issues on Nordic nRF52840 and building errors on
> Windows for newt and newtmgr tools.
>
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test
> +Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.4.1+Test+Results
>
>  Note that only features affected by bugfixes were tested for this
> release. If you feel more testing is needed please provide your results here.
>
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.13
>* Ubuntu Linux 18.04
>
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit bb43247a7e28a1f5e5d869f1088cb4ae53a1
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit f0ce13e45c51825c35963fb13f2562d5911ef1ed
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit ac0db20a10ea042e253012c30b6261d722e11093
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 4d5d517d2a99c2f2c4b322e872714ea702c1a88f
>
> In addition, the following newt convenience binaries are available:
>   linux: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/
> rc1/apache-mynewt-newt-bin-linux-1.4.1.tgz
>   osx: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.1/rc1/
> apache-mynewt-newt-bin-osx-1.4.1.tgz
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon Janc
>
>

Re: [VOTE] Release Apache Mynewt 1.4.0-rc1 and Apache NimBLE 1.0.0-rc1

[Andrzej Kaczmarek]

Hi,

On Wed, Jun 6, 2018 at 9:45 PM Szymon Janc  wrote:
>
> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.4.0 and Apache NimBLE 1.0.0.
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> NimBLE is having its first release as separate package. This is first and last
> release that is coordinated with Apache Mynewt release. After that NimBLE will
> follow with independent releases.
>
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test
> +Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.4.0+Test+Results
>
>  Note that this testing is not yet complete and more results will show
> while voting is ongoing.
>
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.13
>* Ubuntu Linux 18.04
>
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.0/rc1/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit ceecdd3c98bba50859d744ce17b9e8f8b5206dd2
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit ddaf6d822f385b546fac683191ce776ccd53485a
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit bae15edb3b1b8f891f169fe9793131df91fb236b
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 5c759c31de25ec078f903a856d19c3ec1ecea28b
> nimble:
>   repos: https://github.com/apache/mynewt-nimble
>   commit a85b65d97ecd062d8ea88c1a151f649e35e47420
>
> In addition, the following newt convenience binaries are available:
>   linux: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.0/
> rc1/apache-mynewt-newt-bin-linux-1.4.0.tgz
>   osx: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.4.0/rc1/
> apache-mynewt-newt-bin-osx-1.4.0.tgz
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [X] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...

+1 (binding)

> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> --
> pozdrawiam
> Szymon Janc

Best,
Andrzej

Re: [DISCUSS] Release Apache Mynewt 1.4.0-rc1 and Apache NimBLE 1.0.0-rc1

[Andrzej Kaczmarek]

Hi,

There is regression in 1.4.0-rc1 which affects BLE controller on nRF51
as it is not possible to establish connection when acting as a master
(peripheral role and ongoing connections are NOT affected). This is
most likely broken since extended advertising data fragmentation was
merged some time ago which changed flow in TX code and, to make a long
story short, nRF51 is not fast enough to prepare CONNECT_IND packet
within required time after it received connectable advertising.
Possible workaround for this is to disable encryption and privacy
features in controller, though it may not be always feasible.

I made few optimizations which make things work again:
https://github.com/apache/mynewt-core/pull/1170
https://github.com/apache/mynewt-nimble/pull/128

However, I think we should test then a bit more in master first so I
would recommend to list above issue as a known issue in RN and then
make bugfix release (1.4.1 for core and 1.0.1 for NimBLE) soon with
fixes included if they turn out to work fine.

Best,
Andrzej


On Wed, Jun 6, 2018 at 9:45 PM Szymon Janc  wrote:
>
> Hi all,
>
> This thread is for any and all discussion regarding the release of
> Apache Mynewt 1.4.0 and Apache NimBLE 1.0.0.  All feedback is welcome.
>
> --
> pozdrawiam
> Szymon Janc
>
>

Re: ADC device not allowed multiple opens

[Andrzej Kaczmarek]

Hi,

+1 for proper ref counting
btw, trng_nrf52 already works this way except it does not check ref
counter explicitly but OS_DEV_F_STATUS_OPEN flag instead. This is also
already used in Mynewt as NimBLE host, controller and TinyCrypt can
(depending on configuration) just open trng device on its own and
there is no need to open it "globally".

One thing that may need to be fixed though is some locking when
calling open/close handlers since they are now called unlocked and ref
counter is updated later. Since ref counter is checked in these
handlers this may cause device to be initialized more than once and
also to be not un-initialized when all references are dropped. Both
are not a problem for trng_nrf52 driver so I did not worry about it
too much ;-)

Best,
Andrzej


On Wed, Jun 6, 2018 at 10:56 PM will sanfilippo  wrote:
>
> Chris and Vipul:
>
> That does indeed seem to be a decent option! I will see if others chime in 
> and if not, add that change.
>
> Thanks!!!
>
> > On Jun 6, 2018, at 1:32 PM, Vipul Rahane  wrote:
> >
> >
> >> On Jun 6, 2018, at 1:01 PM, Christopher Collins  wrote:
> >>
> >> On Wed, Jun 06, 2018 at 11:57:34AM -0700, will sanfilippo wrote:
> >>> Chris:
> >>>
> >>> I might be missing something here, but given that os_dev already has a 
> >>> reference count and that handles multiple folks opening/closing the 
> >>> device, does the underlying adc driver need a reference count itself? If 
> >>> it just returned no error if opened again this would be fine.
> >>>
> >>> I do note that os_dev_open() and os_dev_close() always call the 
> >>> open/close handlers regardless of reference count. I wonder if that 
> >>> should be changed (meaning only call open/close once)?
> >>
> >> No, you aren't missing anything; I just misunderstood the os_dev
> >> reference counting.  Thanks for setting me straight :).
> >>
> >> Another option: the ADC open function checks its os_dev's reference
> >> count.  If the value is greater than zero, then return without doing
> >> anything.
> >>
> >
> > I was going to suggest that as well. Seems like a simple solution :-)
> >
> >> Chris
> >>
> >>>
> >>>
>  On Jun 6, 2018, at 10:13 AM, Christopher Collins  
>  wrote:
> 
>  On Wed, Jun 06, 2018 at 08:50:34AM -0700, will sanfilippo wrote:
> > Hello:
> >
> > I am not the most familiar with the ADC device so it is possible that 
> > it was being used incorrectly but in any event I ran across something I 
> > wanted to discuss. The call to os_dev_open() allows a device to be 
> > opened multiple times (there is a reference count there). However, the 
> > call to nrf52_adc_open() returns an error (OS_EBUSY) if the device has 
> > already been opened.
> >
> > This presented a problem in the following case: consider two 
> > independent packages both of which want to use ADC_0. Each package is 
> > going to attempt to open the ADC device (since it has no idea if it was 
> > already opened) but the second attempt to open the device will result 
> > in an error code returned. Depending on how the code is written in the 
> > package, this could be a problem. Given that an ADC is almost always a 
> > mutli-channel peripheral (one adc device has multple channels) I would 
> > suspect the above case to be common: multiple packages wanting an ADC 
> > channel from a single device.
> >
> > I am not sure if anything needs to be done here; just wanted to see if 
> > folks thought there should different behavior with regards to the 
> > function returning an error if the device was already opened. If not, 
> > folks are going to have to be careful when they write code using the 
> > adc device. Seems to me if nothing is going to change we have two 
> > options:
> >
> > 1) The device gets created and opened in some place and handed to the 
> > packages that need it.
> > 2) The device gets created (say by the bsp) and each package can 
> > attempt to open the device. If os_dev_lookup() returns !NULL but 
> > os_dev_open() returns NULL it means that the device has already been 
> > opened.
> >
> > Something about #2 just sort of bothers me. I do not like ambiguous 
> > stuff like that; how do you know if there was an error for another 
> > reason?
> 
>  Why not:
> 
>  3) Make the ADC driver consistent with other drivers by adding a
>  reference count.
> 
>  ?
> 
>  I know something less than nothing about the ADC code, so I could
>  certainly be missing something.
> 
>  Chris
> >>>
> >
> > - Vipul
>

Re: MESH and BLE co-existence

[Andrzej Kaczmarek]

Hi Aditya,

Time slicing in Nordic's solution is required because SoftDevice and Mesh
are two separate stacks which access the same hardware resources (in
particular the same radio). In NimBLE this is not applicable since Mesh
works on top of host stack thus co-existence of adv bearer with other
application can be achieved by just using separate advertising instances
for both tasks - this is what was already proposed and implemented so I
believe it would be best to continue discussion in that thread in order to
fix remaining issues. There is no need for different solution here.

Best,
Andrzej

On Sat, May 5, 2018 at 8:19 AM Aditya Xavier  wrote:

> Hi Dev Team,

>  From my understanding BLE Mesh utilizing extended advertising is still in
development.

> Is it possible to have BLE MESH and BLE to co-exist with using extended
advertisement ? i.e. similar to Nordic Softdevice doing time slicing BLE
Mesh and BLE advertising signals.


> Thanks,
> Aditya Xavier.

Re: How to use the nimble in other OS?

[Andrzej Kaczmarek]

Hi,

On Mon, May 7, 2018 at 1:41 PM Tao Han  wrote:

> Hi,

> We try to merge Nimble in nuttx OS which is not support the interruption
> preemption,  now we can make connection and keep to notification some data
> from device A(nrf52832) to devices B(phone app), after sometime, device A
> stopped unexceptionally,  the ble_phy_isr not coming any more.

> Do you have any suggestion for this issue or some debug way to share with
> us.

Did you see any event in application, like disconnection, or it just stops
sending data without any event?
If this is disconnection, then disconnection reason should tell you whether
this was initiated by either side or just timed out (could be due to some
configuration issue then).
If it just stopped suddenly, you should first check if scheduler is running
since this is what will eventually trigger radio. Scheduler is running on
RTC1 at 32768 Hz and executes actions via ble_ll_sched_run(). There should
be some items in scheduler queue also (g_ble_ll_sched_q) and each item has
"start_time" which is number of RTC1 ticks when it should be executed so
you can quickly compare if these values make sense.

BTW, you may want to look on https://github.com/apache/mynewt-nimble/pull/72
which introduces much better support for porting NimBLE to other OS. In
particular, there is small example where complete NimBLE (controller +
host) is runnig on FreeRTOS on nRF52xxx. It's not yet well documented, but
if you have any questions regarding let me know on dev list or Mynewt's
Slack.

> Thanks.

> --
> Best Regards.
> Han Tao

Best,
Andrzej

[RFC] NimBLE porting

[Andrzej Kaczmarek]

Hi all,

There is PR to make NimBLE portable to other OS-es:
https://github.com/apache/mynewt-nimble/pull/72

There were many other small changes in NimBLE code done recently to make
porting process easier, but this one introduces major change by adding
NimBLE Porting Layer (NPL) which provides uniform interface for OS-specific
calls in NimBLE. This means NimBLE will no longer use Mynewt OS APIs
directly, but will call NPL interface which in case of Mynewt is just a
shim layer on top of kernel/os calls.

As an example, instead of using os_mutex and corresponding APIs directly,
NimBLE will now use ble_npl_mutex structure and call ble_npl_mutex_* APIs
which have OS-specific implementation. In particular, in Mynewt NPL these
will just wrap os_mutex_* API.

In this PR you will also find NPL implemented for FreeRTOS. This one is
integrated as an example into FreeRTOS port from nRF5 SDK so you can have
your favourite nRF52 DK or nRF52840 PDK running FreeRTOS with NimBLE. Note
that I am not sure if we can include this example in repository since it
includes Makefile and linker script from nRF5 SDK, so this could be some
licensing issue (nRF5 SDK has to be downloaded separately).

Ah, and there is no documentation... yet ;-)

Best,
Andrzej

Re: extended advertsing with btshell

[Andrzej Kaczmarek]

Hi,

On Tue, Apr 24, 2018 at 8:57 PM, swapnil kadam  wrote:
> Thanks Andzrej. As per your suggestions I followed the same steps.
>
>
>
> I am using following commands in btshell:
>
> I have to use extended advertisement so I am keeping legacy = 0 unset
>
> set addr_type=public addr=01:02:03:04:05:06

FYI, "addr_type=public" is default so you can skip this parameter (but
it's perfectly fine to include it).

> advertise-configure scannable=1
>
> when I enter
>
> advertise-set-adv-data name=xyz
>
> it throws error saying: error setting advertisement data; rc=3

You cannot set advertising data for instance configured as scannable.
Either set scan response data using "advertise-set-scan-rsp" command
(parameters are the same as for "advertise-set-adv-data") or configure
instance as non-scannable. For example, "advertise-configure" alone
will configure instance as non-connectable non-scannable which in your
case means you can set advertising data. Also note that if you
continue to use scannable instance you will need to perform active
scanning in order to get scan response data.

> but when I configure with legacy =1 it accepts all advertise-set-adv-data 
> commands.

This is because legacy advertising instances can accept both
advertising and scan response data but since they use legacu PDUs the
limit is still 31 bytes.

> I have to check data (more than 31 byte) on extended advertisement channels 
> which is not possible with legacy.
>
>
>
> I think I am missing something.
>
>
>
> Regards,
>
> Swapnil

Best,
Andrzej


>
> 
> From: Andrzej Kaczmarek 
> Sent: Tuesday, April 24, 2018 5:42:14 PM
> To: dev@mynewt.apache.org
> Subject: Re: extended advertsing with btshell
>
> Hi swapnil,
>
> You need to set BLE_EXT_ADV_MAX_SIZE syscfg to required value, e.g.:
>> newt target amend  
>> syscfg=BLE_EXT_ADV=1:BLE_EXT_ADV_MAX_SIZE=1650
>
> Default is 31, max is 1650 (as above).
>
> Best,
> Andrzej
>
>
> On Tue, Apr 24, 2018 at 5:35 PM, swapnil kadam  wrote:
>>
>>
>> Hello,
>> I am using btshell for advertsing with nrf52.
>>
>> When I use 31 bytes, mfg_data accepts the data with extended advertsing. But 
>> when I use more than that, mfg_data doesn’t accept. is 251 byte payload 
>> supported in extended advertising?
>> How could I send more than 251 byte payload on extended advertsing?
>>
>> Thank you,
>>
>> Regards,
>> swapnil
>>

Re: extended advertsing with btshell

[Andrzej Kaczmarek]

Hi swapnil,

You need to set BLE_EXT_ADV_MAX_SIZE syscfg to required value, e.g.:
> newt target amend  syscfg=BLE_EXT_ADV=1:BLE_EXT_ADV_MAX_SIZE=1650

Default is 31, max is 1650 (as above).

Best,
Andrzej


On Tue, Apr 24, 2018 at 5:35 PM, swapnil kadam  wrote:
>
>
> Hello,
> I am using btshell for advertsing with nrf52.
>
> When I use 31 bytes, mfg_data accepts the data with extended advertsing. But 
> when I use more than that, mfg_data doesn’t accept. is 251 byte payload 
> supported in extended advertising?
> How could I send more than 251 byte payload on extended advertsing?
>
> Thank you,
>
> Regards,
> swapnil
>

Re: [RFC] HAL for TRNG (True Random Number Generator)

[Andrzej Kaczmarek]

FYI, there was proposal to implement this as a hw/driver instead of
hal_trng to allow other randomness sources instead of MCU - I
implemented this as well and pushed to the same PR so you can take a
look on both.

Best,
Andrzej


On Wed, Apr 18, 2018 at 3:56 PM, Andrzej Kaczmarek
 wrote:
> Hi devs,
>
> I created a simple hal_trng which abstracts TRNG available on many SoCs:
> https://github.com/apache/mynewt-core/pull/1037
>
> I guess this is so simple it does not need much explanation (APIs are
> documented in hal_trng.h), but I can to provide some more information
> if needed :-)
>
> For now there is HAL API and sample implementation for nRF52xxx. If
> this is accepted (as-is or with some changes) I will also modify
> NimBLE drivers for Nordic SoCs to use hal_trng instead of accessing
> NRF_RNG directly so they can nicely work with applications.
>
> Best,
> Andrzej

[RFC] HAL for TRNG (True Random Number Generator)

[Andrzej Kaczmarek]

Hi devs,

I created a simple hal_trng which abstracts TRNG available on many SoCs:
https://github.com/apache/mynewt-core/pull/1037

I guess this is so simple it does not need much explanation (APIs are
documented in hal_trng.h), but I can to provide some more information
if needed :-)

For now there is HAL API and sample implementation for nRF52xxx. If
this is accepted (as-is or with some changes) I will also modify
NimBLE drivers for Nordic SoCs to use hal_trng instead of accessing
NRF_RNG directly so they can nicely work with applications.

Best,
Andrzej

Re: CBOR encoding problems.

[Andrzej Kaczmarek]

Hi Aditya,

On Sun, Apr 1, 2018 at 3:51 PM, Aditya Xavier  wrote:
> Hi Andrzej,
>
> PFB my the test code, this is a torn down version of the code we were trying 
> to do.
>
> However it should be good enough for you to understand the objective and the 
> issues at hand.
>
> I did not personally try the code myself, I would be able to do so and let 
> you know the same tomorrow.

I checked the code and there are some issues wrt to mbuf handling
which can cause problems.

Firstly, I don't see where you actually initialize cbor_codex_mbuf
with proper mbuf as you neither received it from somewhere or call
os_msys_get()/os_mbuf_get() to get it from a pool.
Calling net_buf_simple_init() does not work here since it only
initializes existing mbuf and you probably should not use it at all
unless you're using this code for mesh. In case of mesh you can get
valid mbuf by using NET_BUF_SIMPLE(). I assume this looks a bit
different in your app as this sample app will most likely crash during
startup.

Secondly, this probably causes data truncation:
cbor_decode_action((char *)cbor_codex_mbuf->om_data, cbor_codex_mbuf->om_len);
Basically this way you pass contents of first mbuf in chain to
decoding function, not complete chain. Internally this calls
cbor_read_flat_attrs() but when working with mbufs you should use
cbor_read_mbuf_attrs() instead and pass mbuf instead of its data.

> Thanks,
> Aditya Xavier.

Best,
Andrzej

>
>
>> On 31-Mar-2018, at 3:06 PM, Andrzej Kaczmarek 
>>  wrote:
>>
>> Hi Aditya,
>>
>> On Sat, Mar 31, 2018 at 5:51 AM, Aditya Xavier  wrote:
>>> Increasing MSYS_1_BLOCK_COUNT to 30 gets it to work, but if I increase it 
>>> to 40 it doesn’t.
>>> Block size being 110.
>>>
>>> Any reasoning behind this pattern?
>>
>> This is strange. Can you post some piece of code to show how you handle this?
>>
>>> Also what would is behaviour of os_mbuf_free? Do I need to re init it again?
>>
>> Not sure what you mean by "reinit". Calling os_mbuf_free() releases
>> mbuf back to pool and it should no longer be used. You should call
>> os_mbuf_get() or os_msys_get() to get new mbuf from appropriate pool.
>> Also, if your CBOR stream exceeds size of block then you will have
>> chain of mbufs which should be freed using os_mbuf_free_chain()
>> instead. Basically, if you're not sure whether your mbuf is just a
>> single mbuf or chain of mbufs, you can always use os_mbuf_free_chain()
>> instead of os_mbuf_free().
>>
>>> Sent from my iPhone
>>>
>>>> On 30-Mar-2018, at 1:58 AM, Christopher Collins  wrote:
>>>>
>>>>> On Thu, Mar 29, 2018 at 10:27:36PM +0530, Aditya Xavier wrote:
>>>>> Thanks for the tip. Would try that too..
>>>>>
>>>>> However, I have tried few variations to check the BLE side ( whether it 
>>>>> was responsible for truncating )
>>>>>
>>>>> 1. I am able to send the same message using encoding only.. i.e. if I 
>>>>> trigger the same using a button to send over ble.
>>>>>   i.e. BLE Connection, Button -> Encoding -> BLE Output, works.
>>>>>
>>>>> 2. The method which receives the char * data, itself receives a truncated 
>>>>> value.
>>>>>   BLE Connection, BLE Incoming -> Decoding -> Encoding -> BLE Outgoing, 
>>>>> does not work. Truncation.
>>>>>
>>>>> 3. I am able to send the same message using encoding only.. i.e if I 
>>>>> trigger only the encoding method after receiving a message over BLE.
>>>>>   i.e. BLE Connection, BLE Incoming -> Encoding -> BLE Outgoing, works.
>>>>>
>>>>> This kinda makes me feel that it should be a memory issue when its BLE + 
>>>>> Decoding + Encoding. With or without using mbuf / mbuf_pool
>>>>>
>>>>> Let me know if you require to see the code, I can write another small 
>>>>> test app for you.
>>>>
>>>> I think I understand the sequences you described.  I'm afraid I don't
>>>> have a good answer.
>>>>
>>>> Are you checking the return code of the encoding function?  If the
>>>> system is running out of mbufs during encoding, the function should
>>>> return `CborErrorOutOfMemory`, and the mbuf chain will be partially
>>>> filled.
>>>>
>>>> If you are running in gdb, another way to check for mbuf exhaustion is:
>>>> ```
>>>> p os_msys_init_1_mempool
>>>> ```
>>>>
>>>> and look at the `mp_min_free` value.  If it is 0, that means the pool
>>>> has been exhausted at some point, and it is likely that some allocations
>>>> have failed.
>>>>
>>>> You can also just try increasing the number of mbufs in the system:
>>>> ```
>>>> newt target amend  syscfg=MSYS_1_BLOCK_COUNT=16
>>>> ```
>>>>
>>>> (assuming you are currently using the default value of 12; adjust
>>>> accordingly if not)
>>>>
>>>> Chris
>
>

Re: CBOR encoding problems.

[Andrzej Kaczmarek]

Hi Aditya,

On Sat, Mar 31, 2018 at 5:51 AM, Aditya Xavier  wrote:
> Increasing MSYS_1_BLOCK_COUNT to 30 gets it to work, but if I increase it to 
> 40 it doesn’t.
> Block size being 110.
>
> Any reasoning behind this pattern?

This is strange. Can you post some piece of code to show how you handle this?

> Also what would is behaviour of os_mbuf_free? Do I need to re init it again?

Not sure what you mean by "reinit". Calling os_mbuf_free() releases
mbuf back to pool and it should no longer be used. You should call
os_mbuf_get() or os_msys_get() to get new mbuf from appropriate pool.
Also, if your CBOR stream exceeds size of block then you will have
chain of mbufs which should be freed using os_mbuf_free_chain()
instead. Basically, if you're not sure whether your mbuf is just a
single mbuf or chain of mbufs, you can always use os_mbuf_free_chain()
instead of os_mbuf_free().

> Sent from my iPhone
>
>> On 30-Mar-2018, at 1:58 AM, Christopher Collins  wrote:
>>
>>> On Thu, Mar 29, 2018 at 10:27:36PM +0530, Aditya Xavier wrote:
>>> Thanks for the tip. Would try that too..
>>>
>>> However, I have tried few variations to check the BLE side ( whether it was 
>>> responsible for truncating )
>>>
>>> 1. I am able to send the same message using encoding only.. i.e. if I 
>>> trigger the same using a button to send over ble.
>>>i.e. BLE Connection, Button -> Encoding -> BLE Output, works.
>>>
>>> 2. The method which receives the char * data, itself receives a truncated 
>>> value.
>>>BLE Connection, BLE Incoming -> Decoding -> Encoding -> BLE Outgoing, 
>>> does not work. Truncation.
>>>
>>> 3. I am able to send the same message using encoding only.. i.e if I 
>>> trigger only the encoding method after receiving a message over BLE.
>>>i.e. BLE Connection, BLE Incoming -> Encoding -> BLE Outgoing, works.
>>>
>>> This kinda makes me feel that it should be a memory issue when its BLE + 
>>> Decoding + Encoding. With or without using mbuf / mbuf_pool
>>>
>>> Let me know if you require to see the code, I can write another small test 
>>> app for you.
>>
>> I think I understand the sequences you described.  I'm afraid I don't
>> have a good answer.
>>
>> Are you checking the return code of the encoding function?  If the
>> system is running out of mbufs during encoding, the function should
>> return `CborErrorOutOfMemory`, and the mbuf chain will be partially
>> filled.
>>
>> If you are running in gdb, another way to check for mbuf exhaustion is:
>> ```
>> p os_msys_init_1_mempool
>> ```
>>
>> and look at the `mp_min_free` value.  If it is 0, that means the pool
>> has been exhausted at some point, and it is likely that some allocations
>> have failed.
>>
>> You can also just try increasing the number of mbufs in the system:
>> ```
>> newt target amend  syscfg=MSYS_1_BLOCK_COUNT=16
>> ```
>>
>> (assuming you are currently using the default value of 12; adjust
>> accordingly if not)
>>
>> Chris

Re: [ANNOUNCE] NimBLE code moved to separate repository

[Andrzej Kaczmarek]

Hi Simon,

On Thu, Mar 22, 2018 at 3:18 AM, Simon Ratner  wrote:
> 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 😶

Actually Newt rebuilds new files correctly, but then you have .a files
for old and new packages and linker just seems to pick symbols for the
old one.
What could be improved here is that Newt should only pick .a files for
packages included in build, not all packages in bin/ directory. But
this requires some Go wizard to implement :-)

Anyway, it's always good to do newt clean after some major upgrade ;-)

> Cheers,
> simon

Best regards,
Andrzej


>
> On Mar 16, 2018 02:09, "Andrzej Kaczmarek" 
> wrote:
>
>> Hi all,
>>
>> A few minutes ago I merged
>> https://github.com/apache/mynewt-core/pull/907 which removed NimBLE
>> code from mynewt-core repository. NimBLE code can be now found in
>> mynewt-nimble  repository https://github.com/apache/mynewt-nimble
>> which has complete history of NimBLE files imported with extra
>> information about original commit id.
>>
>> Mynewt-core repository is configured with dependency to new
>> mynewt-nimble repository - this requires new "newt" version which will
>> be part of 1.4 release or if you work with master, please build "newt"
>> from current master and then upgrade project with "newt upgrade".
>>
>> To make migration seamless, all @apache-mynewt-core/net/nimble/*
>> packages have dependency created to corresponding packages in
>> @apache-mynewt-nimble. This is a temporary solution and we'll probably
>> remove this in one of future releases (for sure not in 1.4).
>>
>> Soon we will also close all pending PRs which touch NimBLE code (there
>> are only few of them) asking authors to port them to new repository.
>>
>> Best regards,
>> Andrzej
>>

[ANNOUNCE] NimBLE code moved to separate repository

[Andrzej Kaczmarek]

Hi all,

A few minutes ago I merged
https://github.com/apache/mynewt-core/pull/907 which removed NimBLE
code from mynewt-core repository. NimBLE code can be now found in
mynewt-nimble  repository https://github.com/apache/mynewt-nimble
which has complete history of NimBLE files imported with extra
information about original commit id.

Mynewt-core repository is configured with dependency to new
mynewt-nimble repository - this requires new "newt" version which will
be part of 1.4 release or if you work with master, please build "newt"
from current master and then upgrade project with "newt upgrade".

To make migration seamless, all @apache-mynewt-core/net/nimble/*
packages have dependency created to corresponding packages in
@apache-mynewt-nimble. This is a temporary solution and we'll probably
remove this in one of future releases (for sure not in 1.4).

Soon we will also close all pending PRs which touch NimBLE code (there
are only few of them) asking authors to port them to new repository.

Best regards,
Andrzej

Re: [DISCUSSION] Moving NimBLE to separate project

[Andrzej Kaczmarek]

Hi Szymon,

On Thu, Mar 15, 2018 at 12:57 PM, Szymon Janc  wrote:
> Hi Andrzej,
>
> On Monday, 12 March 2018 15:30:52 CET Andrzej Kaczmarek wrote:
>> Hi,
>>
>> I created PR for apache-mynewt-core which removes NimBLE code and adds
>> dependency to apache-mynewy-nimble repository:
>> https://github.com/apache/mynewt-core/pull/907
>>
>> With latest changes in newt (thanks, Chris!) transition to new
>> structure is automatic - newt update will download new repository and
>> newt build will pick up all dependencies.
>>
>> apache-mynewt-nimble repository is basically rewritten history of
>> apache-mynewt-core with only commits touching NimBLE code included +
>> some directory structure reorg. Each new commit has id of original
>> commit added in commit message to make lookups easier.
>
> Since it looks like community agree with this proposal lets get this PR merged
> so that it can get some testing before next release.

All right, I'll update PR and apache-mynewt-nimble repository to
latest NimBLE code today evening (let's say not before 8pm CET / 12pm
PST) and so we can merge it.
If anyone disagrees, you still have few hours to let us know :-)

> --
> pozdrawiam
> Szymon Janc

Best regards,
Andrzej

Re: Synthesized LF CLOCK with the nrf52840

[Andrzej Kaczmarek]

Hi Abderrezak,

On Thu, Mar 15, 2018 at 1:40 AM, Abderrezak Mekkaoui  wrote:
> Hi All,
>
> I would appreciate any hints regarding  the configuration settings that need
> to be changed to use a synthesized LF clock (32.768 KHz) instead of the Xtal
> Oscillator clock.
> This is for a BLE application.

You'll need to set following settings:
XTAL_32768: 0
XTAL_32768_SYNTH: 1
BLE_XTAL_SETTLE_TIME: 0

Depending on accuracy of your XTAL32M, you might also need to adjust
clock accuracy:
BLE_LL_OUR_SCA
BLE_LL_MASTER_SCA
This is just in case you experience unstable connections - just
increase ppm using above settings. Allowed values are described in
net/nimble/controller/syscfg.yml. With crystal mounted on nRF52840 you
won't need to touch it.

Note that using synthesized clock is not really recommended since it
will keep HFXO running all the time and draw more power than with
LFXO.

> Thanks
>
> Abderrezak

Best regards,
Andrzej

Re: [DISCUSSION] Moving NimBLE to separate project

[Andrzej Kaczmarek]

Hi,

I created PR for apache-mynewt-core which removes NimBLE code and adds
dependency to apache-mynewy-nimble repository:
https://github.com/apache/mynewt-core/pull/907

With latest changes in newt (thanks, Chris!) transition to new
structure is automatic - newt update will download new repository and
newt build will pick up all dependencies.

apache-mynewt-nimble repository is basically rewritten history of
apache-mynewt-core with only commits touching NimBLE code included +
some directory structure reorg. Each new commit has id of original
commit added in commit message to make lookups easier.

Best regards,
Andrzej



On Thu, Feb 22, 2018 at 10:01 AM, Andrzej Kaczmarek
 wrote:
> Hi all,
>
> As some of you may already noticed, there is apache/mynewt-nimble repository
> created where NimBLE code was pushed along with some extra changes, most
> notably initial attempt to create port of NimBLE for FreeRTOS, but other
> platforms will be supported as well (native Linux port is also prepared).
>
> The problem is that this repo is now not synced with apache/mynewt-core and
> having two repositories with the same code is troublesome so we'd like to
> end development of NimBLE code in core repository and move it entirely to
> nimble repository. There are three open points on how this should be done:
> 1. When to do this switch? Before 1.4 release or after it?
> 2. How to deal with NimBLE in core repository?
> 3. How to manage NimBLE releases?
>
> My proposals are as follows:
>
> 2a. Remove NimBLE code from mynewt-core repository leaving only packages
> with dependencies to mynewt-nimble repository. The process of upgrading to
> new version should be as easy as doing 'newt upgrade' to fetch newt
> repository, assuming there are no local changes to NimBLE code. This is
> preferred option.
> 2b. Leave NimBLE code at its current state in mynewt-core and use it by
> default for next release, with option to use mynewt-nimble instead. This is
> safe option and can be also applied before 1.4 release.
>
> 3. NimBLE has its own releases, depending on needs, and Mynewt will use
> latest stable release of NimBLE at all time. First release of NimBLE will be
> synced with Mynewt release, I guess we can call it the same as Mynewt
> release and then start independent releases with 2.0. For those who would
> like to use latest NimBLE, of course it would be just a matter of switching
> repository version manually.
>
> Any thoughts on this?
>
> Best regards,
> Andrzej

Re: Question regarding exchanging long characteristic values over BLE

[Andrzej Kaczmarek]

Hi Simon,

On Thu, Mar 8, 2018 at 9:18 AM, Simon Ratner  wrote:
> 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 in time, the client may receive a mashup of two or more different
> values, if access_cb returns a current value each time. For example, a
> 32-byte value might end up as 22 bytes from sample 0 plus 10 bytes from
> sample 1 -- a combination that does not decode to a valid reading. One way
> around this is to lock in a stable sample for each connection, but that
> becomes harder to keep track of with many concurrent connections.

Reading long attributes is not atomic and there's not much stack can
do about it - it's just what spec says. Trying to make it look like
atomic operation in NimBLE would not be a good idea since there is
probably no good way to do this properly so instead we will end up
with complex code that breaks things.

I suggest to change approach here and instead of trying to read long
value just notify complete value in fragments. For example, add
 and  to each chunk and client should be
able to reassemble complete value easily without need to read
anything.

> I don't really have a solution yet, just complaining ;) Perhaps nimble
> holding on to the value for subsequent offset reads makes sense after all.
> I guess the difficulty there is knowing when to free it?

This is certainly one of biggest difficulties here. Also note that
attribute values are unique per-connection so this means we need to
store separate copy of value for each connection. This can easily
consume lots of memory and we don't really know if/when it can be
freed to make things work as expected.

I'd say if someone has good idea how such caching could be
implemented, it can be done as separate utility package so one can
reuse it in application easily. I'd certainly not want such thing to
be added to NimBLE directly since it's just not how ATT/GATT should
work according to spec.

> Cheers,
> simon

Best regards,
Andrzej


> On Tue, Jul 25, 2017 at 12:19 PM, Andrzej Kaczmarek <
> andrzej.kaczma...@codecoup.pl> wrote:
>
>> Hi,
>>
>>
>> On Tue, Jul 25, 2017 at 8:14 PM, Christopher Collins 
>> wrote:
>>
>> > On Tue, Jul 25, 2017 at 10:46:32AM -0700, Pritish Gandhi wrote:
>> > [...]
>> >
>> [...]
>>
>>
>> > > Is this true for notifications too? If I need to send notifications for
>> > > that long characteristic value, will my access callback be called
>> several
>> > > times based on the MTU of the connection?
>> >
>> > Unfortunately, Bluetooth restricts notifications to a single packet.  If
>> > the characteristic value is longer than the MTU allows, the notification
>> > gets truncated.  To get around this, the application needs to chunk the
>> > value into several notifications, and possibly use some protocol which
>> > indicates the total length, parts remaining, etc.
>> >
>>
>> Also client can just do long read in order to read remaining portion of
>> characteristic value
>>
>> - this is what ATT spec suggests.
>> It depends on actual use case, but this way client may be able to decide
>> whether it should read remaining portion of value or skip it, e.g. some
>> flags can be placed at the beginning of the characteristic value and they
>> will be always sent in notification.
>>
>> Best regards,
>> Andrzej
>>

Re: BLEMESH PB GATT

[Andrzej Kaczmarek]

Hi Aditya,

Seems like you're using Mynewt 1.3.0 release and probably see issue
fixed by following commit on master branch:
https://github.com/apache/mynewt-core/commit/0fd8239b7f914ddae77ac396bfce288fd6bc5b5f

Please apply this change to your tree and check if this solves your problem.

Best regards,
Andrzej


On Fri, Feb 23, 2018 at 1:17 PM, Aditya Xavier  wrote:
> Thanks for quick reply !
>
> With BLE_MESH_PB_GATT: FALSE and BLE_MESH_GATT_PROXY: FALSE, build fails for 
> the app.
>
> Error: repos/apache-mynewt-core/net/nimble/host/mesh/src/proxy.c: In function 
> 'proxy_send':
> repos/apache-mynewt-core/net/nimble/host/mesh/src/proxy.c:852:21: error: 
> unused variable 'om' [-Werror=unused-variable]
>  struct os_mbuf *om;
>  ^~
> At top level:
> repos/apache-mynewt-core/net/nimble/host/mesh/src/proxy.c:126:3: error: 
> 'gatt_svc' defined but not used [-Werror=unused-variable]
>  } gatt_svc = MESH_GATT_NONE;
>^~~~
> repos/apache-mynewt-core/net/nimble/host/mesh/src/proxy.c:95:41: error: 
> 'proxy_adv_param' defined but not used [-Werror=unused-variable]
>  static const struct ble_gap_adv_params *proxy_adv_param = &fast_adv_param;
>  ^~~
> repos/apache-mynewt-core/net/nimble/host/mesh/src/proxy.c:83:40: error: 
> 'slow_adv_param' defined but not used [-Werror=unused-const-variable=]
>  static const struct ble_gap_adv_params slow_adv_param = {
> ^~
> cc1: all warnings being treated as errors
>
> With BLE_MESH_PB_GATT: “0” and BLE_MESH_GATT_PROXY: “0”, build is successful. 
> However, device restarts.
>
> 00 Unhandled interrupt (2), exception sp 0x20001280
> 00  r0:0x  r1:0x  r2:0x8000  r3:0xe000ed00
> 00  r4:0x00019a3f  r5:0x  r6:0x  r7:0x
> 00  r8:0x  r9:0x r10:0x r11:0x
> 00 r12:0x  lr:0x8add  pc:0x8aec psr:0x6100
> 000000 ICSR:0x00421802 HFSR:0x CFSR:0x
> 00 BFAR:0xe000ed38 MMFAR:0xe000ed34
> 00 Assert @ 0x19a3f
>
>
>
>> On 23-Feb-2018, at 5:26 PM, Andrzej Kaczmarek 
>>  wrote:
>>
>> Hi Aditya,
>>
>> On Fri, Feb 23, 2018 at 12:50 PM, Aditya Xavier  wrote:
>>> Hi Mynewt Team,
>>>
>>>
>>>I have been going through and testing the BLEMESH sample app.
>>>
>>>Turning on only one device, which does not have BLE_MESH_GATT_PROXY 
>>> & BLE_MESH_PB_GATT flag, still allows the Silicon Labs application to scan 
>>> and connect to it.
>>>
>>>Correct me if am wrong, but I thought only those devices with 
>>> BLE_MESH_PB_GATT should be scannable / connectable by the Silicon Labs app.
>>>
>>>Am I missing something ?
>>>
>>>For reference am using the master branch.
>>
>> Did you disable GATT PB and proxy flags in your target settings? If
>> not then these are enabled by default in Mesh package so blemesh will
>> work with app from Silicon Labs.
>>
>>> Thanks and Regards,
>>> Aditya Xavier
>>
>> Best regards,
>> Andrzej
>

Re: BLEMESH PB GATT

[Andrzej Kaczmarek]

Hi Aditya,

On Fri, Feb 23, 2018 at 12:50 PM, Aditya Xavier  wrote:
> Hi Mynewt Team,
>
>
> I have been going through and testing the BLEMESH sample app.
>
> Turning on only one device, which does not have BLE_MESH_GATT_PROXY & 
> BLE_MESH_PB_GATT flag, still allows the Silicon Labs application to scan and 
> connect to it.
>
> Correct me if am wrong, but I thought only those devices with 
> BLE_MESH_PB_GATT should be scannable / connectable by the Silicon Labs app.
>
> Am I missing something ?
>
> For reference am using the master branch.

Did you disable GATT PB and proxy flags in your target settings? If
not then these are enabled by default in Mesh package so blemesh will
work with app from Silicon Labs.

> Thanks and Regards,
> Aditya Xavier

Best regards,
Andrzej

[DISCUSSION] Moving NimBLE to separate project

[Andrzej Kaczmarek]

Hi all,

As some of you may already noticed, there is apache/mynewt-nimble
repository created where NimBLE code was pushed along with some extra
changes, most notably initial attempt to create port of NimBLE for
FreeRTOS, but other platforms will be supported as well (native Linux port
is also prepared).

The problem is that this repo is now not synced with apache/mynewt-core and
having two repositories with the same code is troublesome so we'd like to
end development of NimBLE code in core repository and move it entirely to
nimble repository. There are three open points on how this should be done:
1. When to do this switch? Before 1.4 release or after it?
2. How to deal with NimBLE in core repository?
3. How to manage NimBLE releases?

My proposals are as follows:

2a. Remove NimBLE code from mynewt-core repository leaving only packages
with dependencies to mynewt-nimble repository. The process of upgrading to
new version should be as easy as doing 'newt upgrade' to fetch newt
repository, assuming there are no local changes to NimBLE code. This is
preferred option.
2b. Leave NimBLE code at its current state in mynewt-core and use it by
default for next release, with option to use mynewt-nimble instead. This is
safe option and can be also applied before 1.4 release.

3. NimBLE has its own releases, depending on needs, and Mynewt will use
latest stable release of NimBLE at all time. First release of NimBLE will
be synced with Mynewt release, I guess we can call it the same as Mynewt
release and then start independent releases with 2.0. For those who would
like to use latest NimBLE, of course it would be just a matter of switching
repository version manually.

Any thoughts on this?

Best regards,
Andrzej

Re: Define __MYNEWT__ symbol for Mynewt build

[Andrzej Kaczmarek]

Hi Chris,

Indeed, now I see that you added this to newt tool ​recently - I was using
newt 1.3.0 :-)
I'm fine with MYNEWT=1 name. So in this case I'll just close my PR as it is
not applicable now.

Thanks!
Andrzej


On Fri, Feb 9, 2018 at 5:08 PM, Christopher Collins 
wrote:

> Hi Andrzej,
>
> The newt tool already adds the `-DMYNEWT=1` compiler flag during builds.
> Mynewt and newt are not part of the C implementation, so in my opinion
> they should not introduce identifiers in the reserved namespace (leading
> underscore).  I know opinions differ on this point, and I could probably
> be convinced otherwise :).
>
> Chris
>
> On Fri, Feb 09, 2018 at 04:03:24PM +0100, Andrzej Kaczmarek wrote:
> > Hi all,
> >
> > I created a PR which modifies all compiler packages by adding
> > -D__MYNEWT__=1 to compiler.flags.base, see here:
> > https://github.com/apache/mynewt-core/pull/803
> >
> > The reason for this is to have some common symbol which can be used to
> > distinguish between building code for Mynewt or for some other platform -
> > similar symbols are defined for other platforms. This will be especially
> > useful for components which have separate repository, e.g. mynewt-nffs or
> > upcoming mynewt-nimble which can be also ported to other platforms so may
> > use different set of headers or some porting layer.
> >
> > Best regards,
> > Andrzej
>

Define __MYNEWT__ symbol for Mynewt build

[Andrzej Kaczmarek]

Hi all,

I created a PR which modifies all compiler packages by adding
-D__MYNEWT__=1 to compiler.flags.base, see here:
https://github.com/apache/mynewt-core/pull/803

The reason for this is to have some common symbol which can be used to
distinguish between building code for Mynewt or for some other platform -
similar symbols are defined for other platforms. This will be especially
useful for components which have separate repository, e.g. mynewt-nffs or
upcoming mynewt-nimble which can be also ported to other platforms so may
use different set of headers or some porting layer.

Best regards,
Andrzej

Re: Apache Mynewt release 1.4

[Andrzej Kaczmarek]

Hi,

On Thu, Feb 8, 2018 at 12:32 AM, aditi hilbert  wrote:

> Hi all,
>
> There has been a lot of feature additions and bug fixes since our last
> release on Dec 13, 2018.
> I’d like to propose we try to get a release out in two weeks (Feb 21st).
> Below are some of the things we have added:
>
> * Fixes for NimBLE 5 and Mesh issues found at upf59 last week
> * Fixes for NimBLE 5 issues found during BT certification testing
>

Also we'll have support for advertising data fragmentation (i.e.
AUX_CHAIN_IND) which was successfully tested on UPF59 and hopefully will be
merged soon: https://github.com/apache/mynewt-core/pull/770


> * NimBLE port to freeRTOS kernel
>

​This is actually being worked on in separate repository (mynewt-nimble) so
we now have two separate repositories with Nimble code. The goal is to have
mynewt-nimble as the only repository with Nimble code and build Mynewt with
that code. I think it would make sense to aim for completing this split
after current release so we can develop Nimble in one place and also start
raising issues on GitHub for proper repository. If this makes sense, I can
send separate e-mail for discussion later.


> * LoRa enhancements (e.g. config variable to distinguish boards with and
> without antenna switch)
> * Support for additional hardware: Cortex M3 (STM32L152), ARCv2
> architecture
> * Update supported tools e.g. STM32Cube
> * Additional sensor support: DRV2605L haptic driver for LRA and ERM
> * Port of image manager to other non-Mynewt OS
> * Newt tool bug fixes and minor features
>
> This means we get a release candidate out next week. Can we get one out by
> Feb 15th?
>
> thanks,
> Aditi


​Best regards,
Andrzej​

Re: [DISCUSS] To track issues on Github for Apache Mynewt projects or not?

[Andrzej Kaczmarek]

Hi Aditi,

On Tue, Feb 6, 2018 at 9:26 AM, aditi hilbert  wrote:

> Hi,
>
> Multiple people have suggested that issues be tracked on Github close to
> the code. The benefit is that contributors don’t have to switch between two
> systems to raise and clear issues.  Please let your thoughts known either
> way.
>

​+1​
GitHub issues are just enough for Mynewt purposes and I guess more people
will be willing to file issues - Jira is just overly complicated.


> In preparation for such a move (if the majority agrees to), “Issues” has
> been enabled on our GitHub repos.
> https://github.com/apache/mynewt-core  mynewt-core>
> https://github.com/apache/mynewt-newt  mynewt-newt>
> https://github.com/apache/mynewt-newtmgr  mynewt-newtmgr>
> https://github.com/apache/mynewt-nimble  mynewt-nimble>
> https://github.com/apache/mynewt-documentation  mynewt-documentation>
> https://github.com/apache/mynewt-mcumgr  mynewt-mcumgr>
>
> Issues are yet to be turned on for a couple of repos.
>
> thanks,
> Aditi


​Best,
Andrzej
​

Adding .mailmap to repository

[Andrzej Kaczmarek]

Hi all,

I created PR which adds .mailmap to mynewt-core repository:
https://github.com/apache/mynewt-core/pull/764

This allows git (e.g. git shortlog) to merge all commits of the same person
which have different name spelling and/or e-mail address to single entry. I
selected e-mail address with most commits in repository as the "main"
e-mail address, but if someone prefers different e-mail address or name
spelling, please put a comment in PR.

Best regards,
Andrzej

Re: [BLE central] Getting mfg data from advertisement packets

[Andrzej Kaczmarek]

Hi Jitesh,

On Tue, Nov 14, 2017 at 9:39 AM, Jitesh Shah  wrote:
> Few more details:
> These are general connectable and scannable advertisement packets.
>
> advertising interval is ~200ms

Are you sure that you parse data from packet which has mfg data? With
active scan and scannable packets you will have ADV_IND and SCAN_RSP
as separate events so mfg data may be in the other one - you need to
parse both.
If this is not the problem, can you share raw data from advertising
and scan response packets to see what could go wrong parsing them?

> Jitesh

Best regards,
Andrzej


> On Tue, Nov 14, 2017 at 12:30 AM, Jitesh Shah  wrote:
>
>> Hey guys,
>> I have a peripheral running Nordic softdevice (BLE 4.0 protocol). Central
>> is running nimBLE stack 1.0 (0db6321a75deda126943aa187842da6b977cd1c1).
>>
>> The peripheral advertises manufacturing data. I am trying to get to it
>> from the central. I never get the mfg data though. The advertisement packet
>> looks like this at the central:
>>
>>> (gdb) p/x *fields
>>> $1 = {flags = 0x6, uuids16 = 0x0, num_uuids16 = 0x0, uuids16_is_complete
>>> = 0x0, uuids32 = 0x0, num_uuids32 = 0x0, uuids32_is_complete = 0x0,
>>>   uuids128 = 0x20006750, num_uuids128 = 0x1, uuids128_is_complete = 0x1,
>>> name = 0x0, name_len = 0x0, name_is_complete = 0x0, tx_pwr_lvl = 0x0,
>>>   tx_pwr_lvl_is_present = 0x0, slave_itvl_range = 0x0, svc_data_uuid16 =
>>> 0x0, svc_data_uuid16_len = 0x0, public_tgt_addr = 0x0,
>>>   num_public_tgt_addrs = 0x0, appearance = 0x0, appearance_is_present =
>>> 0x0, adv_itvl = 0x0, adv_itvl_is_present = 0x0, svc_data_uuid32 = 0x0,
>>>   svc_data_uuid32_len = 0x0, svc_data_uuid128 = 0x0, svc_data_uuid128_len
>>> = 0x0, uri = 0x0, uri_len = 0x0, mfg_data = 0x0, mfg_data_len = 0x0}
>>
>>
>> Everything else adds up, except no mfg data. Worth noting that I can see
>> the mfg data if I use another BLE central to scan.
>>
>> My discovery parameters are as follows:
>> disc_params.filter_duplicates = 1;
>> disc_params.passive = 0; // active scan
>> /* Use defaults for the rest of the parameters. */
>> disc_params.itvl = 0;
>> disc_params.window = 0;
>> disc_params.filter_policy = 0;
>> disc_params.limited = 0;
>>
>> Any ideas or hints as to how I can debug?
>>
>> Jitesh
>>
>
> --
> This email including attachments contains Mad Apparel, Inc. DBA Athos
> privileged, confidential, and proprietary information solely for the use
> for the addressed recipients. If you are not the intended recipient, please
> be aware that any review, disclosure, copying, distribution, or use of the
> contents of this message is strictly prohibited. If you have received this
> in error, please delete it immediately and notify the sender. All rights
> reserved by Mad Apparel, Inc. 2012. The information contained herein is the
> exclusive property of Mad Apparel, Inc. and should not be used,
> distributed, reproduced, or disclosed in whole or in part without prior
> written permission of Mad Apparel, Inc.

Re: [RFC] Deprecation of bletiny application

[Andrzej Kaczmarek]

Hi,

On Wed, Nov 8, 2017 at 10:14 AM, Szymon Janc  wrote:
> Hello,
>
> This was vaguely discussed in the past when btshell was introduced but I
> wanted to bring it up again.
>
> In short: I propose to deprecate bletiny application (which is no longer
> tiny:) in favour of using btshell. This would also require update of
> documention and tutorials pointing to bletiny.

+1

Best regards,
Andrzej

Re: BLE Host - Removing the BLE_GAP_EVENT_CONN_CANCEL event type

[Andrzej Kaczmarek]

Hi Chris,

On Fri, Oct 13, 2017 at 7:18 PM, Christopher Collins 
wrote:

> Hello all,
>

​​


> *** Proposal
>
> I propose that we remove the `BLE_GAP_EVENT_CONN_CANCEL` event.  Instead
> of using this event type, the host would report a successful
> cancellation via a `BLE_GAP_EVENT_CONNECT` event with an appropriate
> status code.
>
> My rationale for this proposal is as follows.  If you think of the BLE
> stack as a state machine, a successful cancellation involves the same
> state transition as a failed connect attempt.  In both cases, the stack
> transitions from "connecting" to "idle".  For this reason, I think it is
> easier for the application to handle both cases with the same code.  I
> imagine the application doesn't care whether a connect attempt failed
> due to timeout or because it was cancelled.  In both cases, the upshot
> is that the connection wasn't established, and the application is now
> free to initiate another connection.  I believe the cause of failure is
> mainly used in reporting the event, and the status code should give all
> the necessary information for this.
>

​+1 for this​


> *** Details
>
> * For cancelled connection attempts, I suggest the
>   `BLE_GAP_EVENT_CONNECT` event specify a status code of `
> ​​
> BLE_HS_EAPP`
>   (application error).  This is not a perfect fit, but I am leery of
>   adding more error codes, as that imposes a burden on unrelated
>   application code.
>

What about BLE_HS_ENOTCONN?​


> * Because this is an API change, it would be best to introduce it
>   slowly.  The `BLE_GAP_CONN_CANCEL` event would be marked deprecated in
>   the next release, and then removed entirely in the one after that.
>
> * The numeric identifiers associated with the event types would not
>   change.  Instead, 2 (`BLE_GAP_CONN_CANCEL`) would be labelled
>   "reserved".
>

If we only want to keep API stable then making symbol value is not
necessary since symbols are part of API, not their numerical values.
However I can imagine that we can keep this as "stable ABI" so I don't mind
keeping it as you described.


> All comments welcome.
>
> Thanks,
> Chris
>

BR,
Andrzej​

Re: [VOTE] Release Apache Mynewt 1.2.0-rc1

[Andrzej Kaczmarek]

+1 (binding)



On Fri, Sep 8, 2017 at 8:54 PM, Szymon Janc  wrote:
> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.2.0.
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  
> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.2.0+Test+Results
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.11.5
>* Ubuntu Linux 17.04
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit 5ade7990e81ebfb6b9801fd56b7ea32774747ced
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit e511aa733ee0d5740484738036618332ed45475b
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit 3a3e87d754e63cbcf2e49b49c20847dc3c19e655
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit 8bc55635bbac12c036b25b4968ee0f48c1f06e52
>
> In addition, the following newt convenience binaries are available:
>   linux: 
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/apache-mynewt-bin-linux-1.2.0.tgz
>   osx: 
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/apache-mynewt-bin-osx-1.2.0.tgz
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> Thanks,
> Szymon Janc
>

Re: Change in active ble_gap_disc behaviour in 1_2_0_dev

[Andrzej Kaczmarek]

Hi Simon,

On Wed, Sep 6, 2017 at 5:06 AM, Simon Ratner  wrote:
>
> 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 succession.
>
> With 1_2_0_dev, I no longer see the advertising packet data, only the scan
> responses.
>
> This is my scan parameters:
>
> const struct ble_gap_disc_params scan_params_dflt = {
>   .itvl = 0, /* use default */
>   .window = 0, /* use default */
>   .filter_policy = BLE_HCI_SCAN_FILT_NO_WL,
>   .filter_duplicates = 0,
>   .limited = 0,
>   .passive = 0,
> };
>
> Is this an intentional change, and if so, any way to get at the actual adv
> packet data?

I'm not aware of any change in this code, but I've just done a quick
test using bletiny and for me it works just fine:

[08:50:23:504] 093668 received advertisement; event_type=0  fields:
[08:50:23:600] 093672 flags=0x1a:
[08:50:23:600] 093672 General discoverable mode
[08:50:23:600] 093673 tx_pwr_lvl=-7
[08:50:23:600] 093674
[08:50:23:600] 093674 received advertisement; event_type=4  fields:
[08:50:23:600] 093680 uuids16(complete)=0x180d
[08:50:23:600] 093681 name(complete)=andk xperia z5

I used 'b scan' which uses default parameters so the same as you quoted.

Can you see the advertising reports in HCI trace? If so, can you show
them perhaps to check if they are correct?

Best regards,
Andrzej

Separate repository for NFFS

[Andrzej Kaczmarek]

Hi all,

​I'm now porting NFFS code to Zephyr and in order to avoid forking this
code into two separate projects I'd like to propose to move NFFS code into
its own repository (i.e. mynewt-nffs) and basically make it a bit more
generic so it can be used by other projects.


Here's my work done so far in Zephyr: https://github.com/
zephyrproject-rtos/zephyr/pull/1288


As you can see major changes are:

- small glue layer introduced which abstracts memory and flash calls

- OS filesystem calls are then implemented using NFFS API which is now
basically everything that nffs_priv.h exposed so far

- heap memory is changes to static buffers


In case of Mynewt, there's not much to do since everything is already
implemented and just needs to be copied from one place to another. The API
can be polished over time and memory usage (heap vs. static) can be made
configurable.


Of course the new repository would be compatible with Mynewt ootb, the
changes in code are to make "copying" it to other OS-es as straightforward
as possible so code can be updated to new release easily.

Comments are welcome!

Best regards,

Andrzej

Re: [VOTE] Release Apache Mynewt 1.1.0-rc2

[Andrzej Kaczmarek]

+1 (binding)



On Fri, Jul 28, 2017 at 12:47 AM, Szymon Janc 
wrote:

> Hello all,
>
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.1.0.
>
> This is the second release candidate for Mynewt 1.1.0 (rc2); voting for
> rc1 was cancelled due to issues described in [CANCEL][VOTE] email:
>   https://lists.apache.org/thread.html/ba768bba6e3b448489d12039bf5268
> 66f49732c2f63e1270aff70cd3@
>
> Apache Mynewt is a community-driven, permissively licensed open source
> initiative for constrained, embedded applications. Mynewt provides a
> real-time operating system, flash file system, network stacks, and
> support utilities for real-world embedded systems.
>
> For full release notes, please visit the Apache Mynewt Wiki:
> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes
>
> This release candidate was tested as follows:
>   1. Manual execution of the Mynewt test plan:
>  https://cwiki.apache.org/confluence/display/MYNEWT/
> Apache+Mynewt+Test+Plan
>  The test results can be found at:
>  https://cwiki.apache.org/confluence/display/MYNEWT/1.1.0+Test+Results
>   2. The full unit test suite for this release was executed via "newt
>  test all" with no failures.  This testing was performed on the
>  following platforms:
>* OS X 10.11.5
>* Ubuntu Linux 17.04
>
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.1.0/rc2/
>
> The commits under consideration are as follows:
> blinky:
>   repos: https://github.com/apache/mynewt-blinky
>   commit 62dfe9154163b52ec2105ca329cc4547b7b11ae7
> core:
>   repos: https://github.com/apache/mynewt-core
>   commit a9bd2b466feba698eb07c70a434f6424479cc368
> newt:
>   repos: https://github.com/apache/mynewt-newt
>   commit 0e174a618b473e89b5c0d681957830f0d4b7a665
> newtmgr:
>   repos: https://github.com/apache/mynewt-newtmgr
>   commit e1c8a7f2294d3f2513eca16aebac12eede542596
>
> In addition, the following newt convenience binaries are available:
>   linux: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-
> 1.1.0/rc2/apache-mynewt-bin-linux-1.1.0.tgz
>   osx: https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-
> 1.1.0/rc2/apache-mynewt-bin-osx-1.1.0.tgz
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/mynewt/KEYS
>
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PPMC votes are cast.
>
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>
> Anyone can participate in testing and voting, not just committers,
> please feel free to try out the release candidate and provide your
> votes.
>
> A separate [DISCUSS] thread will be opened to talk about this release
> candidate.
>
> Thanks,
> Szymon Janc
>

Re: Question regarding exchanging long characteristic values over BLE

[Andrzej Kaczmarek]

Hi,


On Tue, Jul 25, 2017 at 8:14 PM, Christopher Collins 
wrote:

> On Tue, Jul 25, 2017 at 10:46:32AM -0700, Pritish Gandhi wrote:
> [...]
>
​[...]​


> > Is this true for notifications too? If I need to send notifications for
> > that long characteristic value, will my access callback be called several
> > times based on the MTU of the connection?
>
> Unfortunately, Bluetooth restricts notifications to a single packet.  If
> the characteristic value is longer than the MTU allows, the notification
> gets truncated.  To get around this, the application needs to chunk the
> value into several notifications, and possibly use some protocol which
> indicates the total length, parts remaining, etc.
>

Also client can just do long read in order to read remaining portion of
characteristic value​

​- this is what ATT spec suggests.
It depends on actual use case, but this way client may be able to decide
whether it should read remaining portion of value or skip it, e.g. some
flags can be placed at the beginning of the characteristic value and they
will be always sent in notification.

Best regards,
Andrzej

Re: [RFC] nimble: add monitor protocol/interface + improve logs

[Andrzej Kaczmarek]

Hi all,

There were some comments about logging refactor stuff in original PR so I
extracted monitor protocol core implementation to separate PR as it does
not depend on it so can be merged first:
https://github.com/apache/mynewt-core/pull/372.
The old PR will be then used to deliver logging stuff once we agree on how
to do this properly.

Best regards,
Andrzej



On Thu, Jun 29, 2017 at 5:17 PM, Andrzej Kaczmarek <
andrzej.kaczma...@codecoup.pl> wrote:

> Hi,
>
> I created a PR with implementation of monitor protocol/interface for
> nimble. This is the same protocol as used by BlueZ and Zephyr for logging
> which means we already have nice tools available for analysis.
>
> PR: https://github.com/apache/incubator-mynewt-core/pull/362
> Protocol: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/
> doc/btsnoop.txt
>
> Basically, with this code you can get complete HCI traces, (partial)
> nimble logging and console output over single UART or RTT in real
> time.Unfortunately, at the moment it can be used easily on Linux where you
> can capture and decode logs using btmon tool. It is then possible to open
> saved logs in Wireshark on other platforms.
>
> Some information on how to use it, let's start with configuration over
> UART:
>
> CONSOLE_UART: 0
> ​BLE_MONITOR_UART: 1
>
> ​You will also most probably need to enable some other console, since UART
> console is disabled. There are two options here:
> - CONSOLE_RTT - bidirectional​ console over RTT
> -
> ​ CONSOLE_BLE_MONITOR - output-only console over monitor​
>
>
> Now the monitor interface is accessible over UART with default baudrate of
> 1M, use btmon to access it:
>
> $ btmon -d /dev/ttyUSB0 --tty-speed 100 -p 8
> Bluetooth monitor ver 5.45
> --- /dev/ttyUSB0 opened ---
>
> The major problem with UART is that it usually "produces" some unwanted
> data e.g. during reset and this makes btmon stop recording. I guess the
> most reliable way to use it is to break on main(), start btmon and then
> continue.
>
> But fortunately, it works much better over RTT:
>
> BLE_MONITOR_RTT: 1
>
> You can use any console with RTT, including RTT console since monitor uses
> dedicated upstream buffer. The only problem here is that btmon can only
> read data from TTY so I created small tool to redirect data from RTT to
> PTY: https://github.com/codecoup/tools-rtt2pty/. There is no readme yet,
> but with nRF5x and J-Link installed in default location it should be enough
> to just launch it:
>
> $ rtt2pty &
> Connected to:
>   J-Link OB-SAM3U128-V2-NordicSemi compiled Mar  2 2017 12:22:13
>   S/N: 683111475
> Searching for RTT control block...
> Found 3 up-buffers.
> Using buffer #1 (size=256)
> PTY name is /dev/pts/3
>
> As you can see I run it in the background - as long as you do not either
> restart hw or load application which places RTT control block at different
> place in RAM, you do not need to restart neither rtt2pty or connected btmon.
>
> Now btmon:
>
> $ btmon -d /dev/pts/3
> Bluetooth monitor ver 5.45
> --- /dev/pts/3 opened ---
>
> And that's it for basic setup. Few more options (and default values) which
> may come in handy:
>
> BLE_MONITOR_UART_BAUDRATE: 100 -> UART baudrate (1M)
> BLE_MONITOR_RTT_BUFFERED: 1 -> double buffering for RTT, see below
> BLE_MONITOR_DEBUG: 0 -> redirect applicable nimble logs to monitor instead
> of console, see below for additional info about nimble logging
>
> The double buffering for RTT bears some explanation. For maximum
> performance, monitor packets are written directly to RTT buffer in chunks.
> This assumes that there is something on the other side to read the data
> (like rtt2pty running in the background), as otherwise nimble will block
> when RTT runs out of space waiting for someone to read the data - we cannot
> just discard some chunk of data as it will break the protocol. To avoid
> this an intermediate buffer is created (enabled by default) where complete
> monitor packet is composed and then written at once or discarded. In worst
> case, there will be just some dropped packets but nimble won't block. This
> however requires extra space for this buffer and also extra copy to write
> form intermediate buffer to RTT.
>
> Another part of this PR are improvements in nimble logging. This is kind
> of side-effect of using monitor interface, but I think an useful one.
> Since logs in nimble are "composed" using multiple macro invocations the
> were not really suitable to work with monitor which expects single line log
> at once. I created set of new macros and helpers to have logs printf-ed in
> single line along with function name by default. The old macros are st

[RFC] nimble: add monitor protocol/interface + improve logs

[Andrzej Kaczmarek]

Hi,

I created a PR with implementation of monitor protocol/interface for
nimble. This is the same protocol as used by BlueZ and Zephyr for logging
which means we already have nice tools available for analysis.

PR: https://github.com/apache/incubator-mynewt-core/pull/362
Protocol:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/btsnoop.txt

Basically, with this code you can get complete HCI traces, (partial) nimble
logging and console output over single UART or RTT in real
time.Unfortunately, at the moment it can be used easily on Linux where you
can capture and decode logs using btmon tool. It is then possible to open
saved logs in Wireshark on other platforms.

Some information on how to use it, let's start with configuration over UART:

CONSOLE_UART: 0
​BLE_MONITOR_UART: 1

​You will also most probably need to enable some other console, since UART
console is disabled. There are two options here:
- CONSOLE_RTT - bidirectional​ console over RTT
-
​ CONSOLE_BLE_MONITOR - output-only console over monitor​


Now the monitor interface is accessible over UART with default baudrate of
1M, use btmon to access it:

$ btmon -d /dev/ttyUSB0 --tty-speed 100 -p 8
Bluetooth monitor ver 5.45
--- /dev/ttyUSB0 opened ---

The major problem with UART is that it usually "produces" some unwanted
data e.g. during reset and this makes btmon stop recording. I guess the
most reliable way to use it is to break on main(), start btmon and then
continue.

But fortunately, it works much better over RTT:

BLE_MONITOR_RTT: 1

You can use any console with RTT, including RTT console since monitor uses
dedicated upstream buffer. The only problem here is that btmon can only
read data from TTY so I created small tool to redirect data from RTT to
PTY: https://github.com/codecoup/tools-rtt2pty/. There is no readme yet,
but with nRF5x and J-Link installed in default location it should be enough
to just launch it:

$ rtt2pty &
Connected to:
  J-Link OB-SAM3U128-V2-NordicSemi compiled Mar  2 2017 12:22:13
  S/N: 683111475
Searching for RTT control block...
Found 3 up-buffers.
Using buffer #1 (size=256)
PTY name is /dev/pts/3

As you can see I run it in the background - as long as you do not either
restart hw or load application which places RTT control block at different
place in RAM, you do not need to restart neither rtt2pty or connected btmon.

Now btmon:

$ btmon -d /dev/pts/3
Bluetooth monitor ver 5.45
--- /dev/pts/3 opened ---

And that's it for basic setup. Few more options (and default values) which
may come in handy:

BLE_MONITOR_UART_BAUDRATE: 100 -> UART baudrate (1M)
BLE_MONITOR_RTT_BUFFERED: 1 -> double buffering for RTT, see below
BLE_MONITOR_DEBUG: 0 -> redirect applicable nimble logs to monitor instead
of console, see below for additional info about nimble logging

The double buffering for RTT bears some explanation. For maximum
performance, monitor packets are written directly to RTT buffer in chunks.
This assumes that there is something on the other side to read the data
(like rtt2pty running in the background), as otherwise nimble will block
when RTT runs out of space waiting for someone to read the data - we cannot
just discard some chunk of data as it will break the protocol. To avoid
this an intermediate buffer is created (enabled by default) where complete
monitor packet is composed and then written at once or discarded. In worst
case, there will be just some dropped packets but nimble won't block. This
however requires extra space for this buffer and also extra copy to write
form intermediate buffer to RTT.

Another part of this PR are improvements in nimble logging. This is kind of
side-effect of using monitor interface, but I think an useful one.
Since logs in nimble are "composed" using multiple macro invocations the
were not really suitable to work with monitor which expects single line log
at once. I created set of new macros and helpers to have logs printf-ed in
single line along with function name by default. The old macros are still
in place since I updated only logs messages in crypto toolbox and GAP - se
respective commits for more explanation there.

Things still to do here:
- make buffers size configurable (for UART, RTT and logging) - they consume
some RAM now, it can be decreased at least in default configuration
- add statistics for dropped packets when using RTT double buffering
- update remaining logs to printf style

Oh, and in case you wonder how btmon trace with nimble stuff looks like,
here's an example from bleprph:
https://gist.github.com/andrzej-kaczmarek/118de10190192fbe76c4c2a2a7bf9299.

Comments?

Best regards,
Andrzej