[jira] [Resolved] (MYNEWT-873) newt crashes during 'newt install'

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-873.

Resolution: Fixed

> newt crashes during 'newt install'
> --
>
> Key: MYNEWT-873
> URL: https://issues.apache.org/jira/browse/MYNEWT-873
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Affects Versions: v1_3_0_rel
>Reporter: Marko Kiiskila
>Assignee: Sterling Hughes
>Priority: Major
>
> There might, or might not have been, an attempt to run 'newt install' before 
> for this project.
> Network was slow, so they might've stopped the fetch in the middle. But I'm 
> not certain
> of that.
> nu@mc-117:~/myproj$ newt install
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x75d4ce]
> goroutine 1 [running]:
> mynewt.apache.org/newt/newt/repo.(*Version).ToNuVersion(...)
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/version.go:162
> mynewt.apache.org/newt/newt/repo.(*Repo).CheckNewtCompatibility(0xc420094e10, 
> 0x0, 0x1, 0x2, 0x0, 0x0, 0x0, 0x1)
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/repo.go:796 
> +0x5e
> mynewt.apache.org/newt/newt/project.(*Project).loadRepo(0xc420064ae0, 
> 0xc4200157a0, 0x12, 0xc4200cc0e0, 0x1, 0x1)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:427 
> +0x51c
> mynewt.apache.org/newt/newt/project.(*Project).loadConfig(0xc420064ae0, 0x0, 
> 0xc42007dbc0)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:505 
> +0x421
> mynewt.apache.org/newt/newt/project.(*Project).Init(0xc420064ae0, 
> 0xc420014184, 0x10, 0x1c, 0x8363c0)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:544 
> +0xed
> mynewt.apache.org/newt/newt/project.NewProject(0xc420014184, 0x10, 
> 0xc420014184, 0x10, 0x0)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:135 
> +0x58
> mynewt.apache.org/newt/newt/project.LoadProject(0xc420014184, 0x10, 
> 0xc420057bd8, 0xc420062080, 0xc42180)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:719 
> +0x7d
> mynewt.apache.org/newt/newt/project.initProject(0xc420014184, 0x10, 
> 0xc420014184, 0x10)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:74 
> +0x39
> mynewt.apache.org/newt/newt/project.initialize(0x4, 0xc420057c90)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:92 
> +0x89
> mynewt.apache.org/newt/newt/project.TryGetProject(0x4, 0xc420019138, 0x4)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:100 
> +0x22
> mynewt.apache.org/newt/newt/cli.TryGetProject(0x0)
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/cli/util.go:208 
> +0x26
> mynewt.apache.org/newt/newt/cli.installRunCmd(0xc420161200, 0xb6fcf8, 0x0, 
> 0x0)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/cli/project_cmds.go:76 
> +0x26
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420161200,
>  0xb6fcf8, 0x0, 0x0, 0xc420161200, 0xb6fcf8)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
>  +0x234
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200ced80,
>  0xc42016e000, 0xc42016e900, 0xc42016e6c0)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
>  +0x2fe
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200ced80,
>  0xc42007d290, 0xc420057f10)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
>  +0x2b
> main.main()
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac
> gnu@mc-117:~/myproj$ cd ..
> gnu@mc-117:~$ cd adafruit/
> gnu@mc-117:~/adafruit$ cd myproj/
> gnu@mc-117:~/adafruit/myproj$ newt install
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x75d4ce]
> goroutine 1 [running]:
> mynewt.apache.org/newt/newt/repo.(*Version).ToNuVersion(...)
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/version.go:162
> mynewt.apache.org/newt/newt/repo.(*Repo).CheckNewtCompatibility(0xc42

[jira] [Reopened] (MYNEWT-873) newt crashes during 'newt install'

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reopened MYNEWT-873:


> newt crashes during 'newt install'
> --
>
> Key: MYNEWT-873
> URL: https://issues.apache.org/jira/browse/MYNEWT-873
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Affects Versions: v1_3_0_rel
>Reporter: Marko Kiiskila
>Assignee: Sterling Hughes
>Priority: Major
>
> There might, or might not have been, an attempt to run 'newt install' before 
> for this project.
> Network was slow, so they might've stopped the fetch in the middle. But I'm 
> not certain
> of that.
> nu@mc-117:~/myproj$ newt install
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x75d4ce]
> goroutine 1 [running]:
> mynewt.apache.org/newt/newt/repo.(*Version).ToNuVersion(...)
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/version.go:162
> mynewt.apache.org/newt/newt/repo.(*Repo).CheckNewtCompatibility(0xc420094e10, 
> 0x0, 0x1, 0x2, 0x0, 0x0, 0x0, 0x1)
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/repo.go:796 
> +0x5e
> mynewt.apache.org/newt/newt/project.(*Project).loadRepo(0xc420064ae0, 
> 0xc4200157a0, 0x12, 0xc4200cc0e0, 0x1, 0x1)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:427 
> +0x51c
> mynewt.apache.org/newt/newt/project.(*Project).loadConfig(0xc420064ae0, 0x0, 
> 0xc42007dbc0)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:505 
> +0x421
> mynewt.apache.org/newt/newt/project.(*Project).Init(0xc420064ae0, 
> 0xc420014184, 0x10, 0x1c, 0x8363c0)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:544 
> +0xed
> mynewt.apache.org/newt/newt/project.NewProject(0xc420014184, 0x10, 
> 0xc420014184, 0x10, 0x0)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:135 
> +0x58
> mynewt.apache.org/newt/newt/project.LoadProject(0xc420014184, 0x10, 
> 0xc420057bd8, 0xc420062080, 0xc42180)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:719 
> +0x7d
> mynewt.apache.org/newt/newt/project.initProject(0xc420014184, 0x10, 
> 0xc420014184, 0x10)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:74 
> +0x39
> mynewt.apache.org/newt/newt/project.initialize(0x4, 0xc420057c90)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:92 
> +0x89
> mynewt.apache.org/newt/newt/project.TryGetProject(0x4, 0xc420019138, 0x4)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:100 
> +0x22
> mynewt.apache.org/newt/newt/cli.TryGetProject(0x0)
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/cli/util.go:208 
> +0x26
> mynewt.apache.org/newt/newt/cli.installRunCmd(0xc420161200, 0xb6fcf8, 0x0, 
> 0x0)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/cli/project_cmds.go:76 
> +0x26
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420161200,
>  0xb6fcf8, 0x0, 0x0, 0xc420161200, 0xb6fcf8)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
>  +0x234
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200ced80,
>  0xc42016e000, 0xc42016e900, 0xc42016e6c0)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
>  +0x2fe
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200ced80,
>  0xc42007d290, 0xc420057f10)
> 
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
>  +0x2b
> main.main()
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac
> gnu@mc-117:~/myproj$ cd ..
> gnu@mc-117:~$ cd adafruit/
> gnu@mc-117:~/adafruit$ cd myproj/
> gnu@mc-117:~/adafruit/myproj$ newt install
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x75d4ce]
> goroutine 1 [running]:
> mynewt.apache.org/newt/newt/repo.(*Version).ToNuVersion(...)
> /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/version.go:162
> mynewt.apache.org/newt/newt/repo.(*Repo).CheckNewtCompatibility(0xc4200aae10, 
> 0x0

[jira] [Assigned] (MYNEWT-882) Newt - Problems with spaces in paths

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reassigned MYNEWT-882:
--

Assignee: Christopher Collins  (was: Sterling Hughes)

> Newt - Problems with spaces in paths
> 
>
> Key: MYNEWT-882
> URL: https://issues.apache.org/jira/browse/MYNEWT-882
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
>Priority: Major
>
> A user from the #general slack channel (Anup) reported an issue involving 
> spaces in path names.
> The summary is:
> {noformat}
> 2018/01/07 18:57:21.699 [DEBUG] 
> o=repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c:24:10: fatal 
> error: syscfg/syscfg.h: No such file or directory
> {noformat}
> {noformat}
> -IBhattacharjee/dev/myproj/bin/targets/nucleof401_boot/generated/include
> {noformat}
> The full include path should be: {{C:/msys64/home/Anup 
> Bhattacharjee/dev/myproj/bin/targets/nucleof401_boot/generated/include}}
> The full build log is here: 
> https://mynewt.slack.com/files/U8P49MQ83/F8P7W856W/-.txt



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MYNEWT-888) Build error if FLASH_AREA_IMAGE_1 is undefined

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-888:
---
Description: 
In {{flash_map.c}}, {{flash_area_id_from_image_slot()}} and 
{{flash_area_id_to_image_slot()}} unconditionally reference the 
{{FLASH_AREA_IMAGE_1}} macro.  This causes build errors for a BSP using the 
[single setup|http://mynewt.apache.org/latest/os/modules/split/split/].

These functions should be modified to only reference these constants in the 
unified and split setups.

  was:
In {{flash_map.c}},{{flash_area_id_from_image_slot()}} and 
{{flash_area_id_to_image_slot()}} unconditionally reference the 
{{FLASH_AREA_IMAGE_1}} macro.  This causes build errors for a BSP using the 
[single setup|http://mynewt.apache.org/latest/os/modules/split/split/].

These functions should be modified to only reference these constants in the 
unified and split setups.


> Build error if FLASH_AREA_IMAGE_1 is undefined
> --
>
> Key: MYNEWT-888
> URL: https://issues.apache.org/jira/browse/MYNEWT-888
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Image Mgmt
>Affects Versions: 1.3
>    Reporter: Christopher Collins
>Assignee: Marko Kiiskila
>Priority: Minor
>
> In {{flash_map.c}}, {{flash_area_id_from_image_slot()}} and 
> {{flash_area_id_to_image_slot()}} unconditionally reference the 
> {{FLASH_AREA_IMAGE_1}} macro.  This causes build errors for a BSP using the 
> [single setup|http://mynewt.apache.org/latest/os/modules/split/split/].
> These functions should be modified to only reference these constants in the 
> unified and split setups.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MYNEWT-882) Newt - Problems with spaces in path in Windows

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-882:
--

 Summary: Newt - Problems with spaces in path in Windows
 Key: MYNEWT-882
 URL: https://issues.apache.org/jira/browse/MYNEWT-882
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Newt
Reporter: Christopher Collins
Assignee: Sterling Hughes


A user from the #general slack channel (Anup) reported an issue involving 
spaces in path names.

The summary is:
{noformat}
2018/01/07 18:57:21.699 [DEBUG] 
o=repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c:24:10: fatal 
error: syscfg/syscfg.h: No such file or directory
{noformat}
{noformat}
-IBhattacharjee/dev/myproj/bin/targets/nucleof401_boot/generated/include
{noformat}

The full include path should be: {{C:/msys64/home/Anup 
Bhattacharjee/dev/myproj/bin/targets/nucleof401_boot/generated/include}}

The full build log is here: 
https://mynewt.slack.com/files/U8P49MQ83/F8P7W856W/-.txt



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: problem running the bare ble example on nrf52480

[Christopher Collins]

On Thu, Jan 04, 2018 at 08:02:20PM -0500, Abderrezak Mekkaoui wrote:
> Hi Chris
> 
> The result is as follows:
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __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
> 137    asm("bkpt");
> (gdb) bt
> #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
> #1  0x00016ae0 in ble_hs_event_start (ev=) at 
> repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:474
> #2  0x00016b0c in ble_hs_sync () at 
> repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:316
> #3  0x00016cfc in ble_hs_start () at 
> repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:560
> #4  0x00016d16 in ble_hs_event_start (ev=) at 
> repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:473
> #5  0xc322 in main (argc=, argv=) at 
> apps/ble_app/src/main.c:36

Darn... I see what the problem is.  This bug was fixed after the
1.3 release: https://github.com/apache/mynewt-core/pull/704.  I didn't
realize the BLE tutorial was broken, though!

The easiest fix is probably to add a store package to the app.  You can
do this by adding the following dependency to your app's pkg.yml file:

- "@apache-mynewt-core/net/nimble/host/store/config"

Thanks for the heads up!  I will submit a fix for the BLE tutorial to
include this change.

Chris

[jira] [Updated] (MYNEWT-857) BLE Controller - incompatibility with iPhone 8 (and iPhone X?)

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-857:
---
Summary: BLE Controller - incompatibility with iPhone 8 (and iPhone X?)  
(was: BLE Controller - incompatibility with iOS 11)

This seems to be a link layer issue, so I don't believe the version of iOS is a 
factor.

Lance, I have a few more questions if you don't mind:

1. Which iPhone model are you seeing this issue with?
2. Just to make sure - you weren't seeing this issue with older iPhones?
3. Did commenting out the call to {{ble_ll_ctrl_proc_start()}} help at all, or 
is the behavior the same?

> BLE Controller - incompatibility with iPhone 8 (and iPhone X?)
> --
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap, 
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but 
> the CoreBluetooth {{didConnect()}} callback does not get called.  A packet 
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never 
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature 
> Exchange Procedure immediately after connection establishment. The 
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet 
> #6211.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYNEWT-857) BLE Controller - incompatibility with iOS 11

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295629#comment-16295629
 ] 

Christopher Collins commented on MYNEWT-857:


I did some additional testing:

*Master:* iPhone 8 running iOS 11, lightblue
*Slave:* nRF52dk running bleprph

Unfortunately, I get the same results:
* With an unmodified NimBLE slave, the iPhone controller seems to get stuck 
after the slave initiates the Slave Feature Request link layer procedure.  
Service discovery does not occur and lightblue eventually times out.
* When I comment out the call to {{ble_ll_ctrl_proc_start()}}, the full connect 
procedure (including MTU exchange, service discovery, etc.) completes without 
issue.

I ran the "commented out" test 47 times with no issues.

h3. Initial failed attempt (unmodified NimBLE stack):

{noformat}
02 [ts=15624ssb, mod=4 level=1] GAP procedure initiated: advertise; 
disc_mode=2 adv_channel_map=0 own_addr_type=0 adv_filter_policy=0 
adv_itvl_min=0 adv_itvl_max=0
002100 [ts=16406224ssb, mod=64 level=1] connection established; status=0 
handle=1 our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0 
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1 
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1 
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0 
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
002110 [ts=16484344ssb, mod=64 level=1]
004020 [ts=31406224ssb, mod=64 level=1] connection updated; status=531 handle=1 
our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0 
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1 
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1 
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0 
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
004029 [ts=31476532ssb, mod=64 level=1]
004030 [ts=31484344ssb, mod=64 level=1] disconnect; reason=531 handle=1 
our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0 
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1 
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1 
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0 
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
004039 [ts=31554652ssb, mod=64 level=1]
004040 [ts=31562464ssb, mod=4 level=1] GAP procedure initiated: advertise; 
disc_mode=2 adv_channel_map=0 own_addr_type=0 adv_filter_policy=0 
adv_itvl_min=0 adv_itvl_max=0
{noformat}

h3. With call to {{ble_ll_ctrl_proc_start()}} commented out:

{noformat}
02 [ts=15624ssb, mod=4 level=1] GAP procedure initiated: advertise; 
disc_mode=2 adv_channel_map=0 own_addr_type=0 adv_filter_policy=0 
adv_itvl_min=0 adv_itvl_max=0
000611 [ts=4773388ssb, mod=64 level=1] connection established; status=0 
handle=1 our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0 
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1 
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1 
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0 
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
000620 [ts=4843696ssb, mod=64 level=1]
000649 [ts=5070308ssb, mod=64 level=1] mtu update event; conn_handle=1 cid=4 
mtu=256
000695 [ts=5429660ssb, mod=64 level=1] subscribe event; conn_handle=1 
attr_handle=14 reason=1 prevn=0 curn=0 previ=0 curi=1
001156 [ts=9031248ssb, mod=64 level=1] connection updated; status=531 handle=1 
our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0 
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1 
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1 
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0 
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
001165 [ts=9101556ssb, mod=64 level=1]
001166 [ts=9109368ssb, mod=64 level=1] subscribe event; conn_handle=1 
attr_handle=14 reason=2 prevn=0 curn=0 previ=1 curi=0
001169 [ts=9132804ssb, mod=64 level=1] disconnect; reason=531 handle=1 
our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0 
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1 
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1 
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0 
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
001178 [ts=9203112ssb, mod=64 level=1]
001179 [ts=9210924ssb, mod=4 level=1] GAP procedure initiated: advertise; 
disc_mode=2 adv_channel_map=0 own_addr_type=0 adv_filter_policy=0 
adv_itvl_min=0 adv_itvl_max=0
001651 [ts=12898380ssb, mod=64 level=1] connection established; status=0 
handle=1 our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0 
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1 
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1 
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0 
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
001660 [ts=12968688ssb, mod=64 level=1]
001690 [ts=13203112ssb, mod=64 level=1] mtu update event; conn_hand

[jira] [Comment Edited] (MYNEWT-857) BLE Controller - incompatibility with iOS 11

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209721#comment-16209721
 ] 

Christopher Collins edited comment on MYNEWT-857 at 12/16/17 6:47 PM:
--

Hmm, that's interesting.  Maybe the problem isn't the type of PDU that gets 
sent, but how early it gets sent.  I have attached a pcap file 
({{ios2nimble-no-feat.pcap}}) showing the successful connect (with the feature 
exchange commented out).  The CONNECT_REQ is at packet #285718.


was (Author: ccollins476):
Hmm, that's interesting.  Maybe the problem isn't the type of PDU that gets 
sent, but how early it gets sent.  I have attached a pcap file 
{{ios2nimble-no-feat.pcap}} showing the successful connect (with the feature 
exchange commented out).  The CONNECT_REQ is at packet #285718.

> BLE Controller - incompatibility with iOS 11
> 
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap, 
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but 
> the CoreBluetooth {{didConnect()}} callback does not get called.  A packet 
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never 
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature 
> Exchange Procedure immediately after connection establishment. The 
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet 
> #6211.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYNEWT-857) BLE Controller - incompatibility with iOS 11

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209721#comment-16209721
 ] 

Christopher Collins edited comment on MYNEWT-857 at 12/16/17 6:46 PM:
--

Hmm, that's interesting.  Maybe the problem isn't the type of PDU that gets 
sent, but how early it gets sent.  I have attached a pcap file 
{{ios2nimble-no-feat.pcap}} showing the successful connect (with the feature 
exchange commented out).  The CONNECT_REQ is at packet #285718.


was (Author: ccollins476):
Hmm, that's interesting.  Maybe the problem isn't the type of PDU that gets 
sent, but how early it gets sent.  I have attached a pcap file showing the 
successful connect (with the feature exchange commented out).  The CONNET_REQ 
is at packet #285718.

> BLE Controller - incompatibility with iOS 11
> 
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap, 
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but 
> the CoreBluetooth {{didConnect()}} callback does not get called.  A packet 
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never 
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature 
> Exchange Procedure immediately after connection establishment. The 
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet 
> #6211.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-857) BLE Controller - incompatibility with iOS 11

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-857:
---
Description: 
Master: iPhone running iOS 11
Slave: NimBLE device

The iPhone successfully establishes a connection to the NimBLE device, but the 
CoreBluetooth {{didConnect()}} callback does not get called.  A packet trace 
(see attached {{ios2nimble.pcap}} file) shows that the iPhone never initiates 
service discovery.

The problem seems to occur when the NimBLE controller initiates the Feature 
Exchange Procedure immediately after connection establishment. The 
{{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
{{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
service discovery, resulting in the CoreBluetooth callback being executed.

In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet 
#6211.

  was:
Master: iPhone running iOS 11
Slave: NimBLE device

The iPhone successfully establishes a connection to the NimBLE device, but the 
CoreBluetooth {{didConnect()}} callback does not get called.  A packet trace 
(see attached) shows that the iPhone never initiates service discovery.

The problem seems to occur when the NimBLE controller initiates the Feature 
Exchange Procedure immediately after connection establishment. The 
{{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
{{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
service discovery, resulting in the CoreBluetooth callback being executed.

In the attached pcap file, the CONNECT_REQ is at packet #6211.


> BLE Controller - incompatibility with iOS 11
> 
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap, 
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but 
> the CoreBluetooth {{didConnect()}} callback does not get called.  A packet 
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never 
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature 
> Exchange Procedure immediately after connection establishment. The 
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet 
> #6211.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYNEWT-857) BLE Controller - incompatibility with iOS 11

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293905#comment-16293905
 ] 

Christopher Collins edited comment on MYNEWT-857 at 12/16/17 6:44 PM:
--

Lance, that is disappointing to hear.  Could you estimate the frequency of the 
intermittent issue (e.g., 1 out of 10 connections)?  The problem seemed to be 
fully resolved for me when I removed the call to {{ble_ll_ctrl_proc_start()}}, 
but I admit that I only tried it a few times before declaring success.  I don't 
have access to a new iOS device at the moment, but I can try some more tests 
during the week.

Do you happen to have a Bluetooth sniffer?  A trace (e.g., pcap file) which 
captures the intermittent issue would be quite helpful.


was (Author: ccollins476):
Lance, that is disappointing to hear.  Could you estimate the frequency of the 
intermittent issue (e.g., 1 out of 10 connections)?

Do you happen to have a Bluetooth sniffer?  A trace (e.g., pcap file) which 
captures the intermittent issue would be quite helpful.

> BLE Controller - incompatibility with iOS 11
> 
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap, 
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but 
> the CoreBluetooth {{didConnect()}} callback does not get called.  A packet 
> trace (see attached) shows that the iPhone never initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature 
> Exchange Procedure immediately after connection establishment. The 
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file, the CONNECT_REQ is at packet #6211.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYNEWT-857) BLE Controller - incompatibility with iOS 11

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293905#comment-16293905
 ] 

Christopher Collins commented on MYNEWT-857:


Lance, that is disappointing to hear.  Could you estimate the frequency of the 
intermittent issue (e.g., 1 out of 10 connections)?

Do you happen to have a Bluetooth sniffer?  A trace (e.g., pcap file) which 
captures the intermittent issue would be quite helpful.

> BLE Controller - incompatibility with iOS 11
> 
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap, 
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but 
> the CoreBluetooth {{didConnect()}} callback does not get called.  A packet 
> trace (see attached) shows that the iPhone never initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature 
> Exchange Procedure immediately after connection establishment. The 
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file, the CONNECT_REQ is at packet #6211.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: newt load hang

[Christopher Collins]

Hi Mostafa,

On Wed, Dec 06, 2017 at 10:45:16AM -0500, Mostafa Abdulla Uddin wrote:
> Hello,
> 
> I have install mynewt 1.2.0 in my Mac OS 10.11.6.
> I am using Nordic Board
> nRF52 Development Kit (for nRF52832)
> 
> I am trying do load blinky project with shell enable. Unfortunately, my
> load command paused. Note that I have erase previous image using Jlinkexe.
> I see it paused at following point

Could you please run the `newt load` command again, but also specify the
`-v` and `-ldebug` command line switches?  Then include the output in a
follow up email.

Thanks,
Chris

Re: [VOTE] Release Apache Mynewt 1.3.0-rc1

[Christopher Collins]

On Thu, Nov 30, 2017 at 10:10:00PM -0200, Fabio Utzig wrote:
[...]
> [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)

Chris

Re: Cannot build lora_app_shell

[Christopher Collins]

On Wed, Nov 29, 2017 at 07:43:20AM -0800, will sanfilippo wrote:
> I doubt it was ever tested with no sx1276 actually connected. Where is it 
> crashing? What function is at 0x81bc?

> 
> > On Nov 29, 2017, at 6:20 AM, K Dmitry  wrote:
> > 
> > Thanks! That helped. I had to define few more pins and was able to build 
> > app. Now I'm trying to test it without SX1276 actually connected, but looks 
> > like app crashes:
> > 
> > 00 ICSR:0x00421002
> > 00 Assert @ 0xfb63
> > 00 Unhandled interrupt (2), exception sp 0x200013c0
> > 00  r0:0x  r1:0x00016289  r2:0x8000  r3:0xe000ed00
> > 00  r4:0xfb63  r5:0x0008  r6:0x  r7:0x2000268c
> > 00  r8:0x  r9:0x r10:0x r11:0x
> > 00 r12:0x  lr:0x8dcf  pc:0x81bc psr:0x81000200
> > 
> > Is it expected behavior when no SX1276 is present?

There are a few settings you can enable to help narrow down the cause of
the crash:

BASELIBC_ASSERT_FILE_LINE
SYSINIT_PANIC_FILE_LINE
SYSINIT_PANIC_MESSAGE

With these enabled, more information will get printed to the console at
the time of the crash, including the filename and line number where the
crash occurred.  They are disabled by default to reduce code size.

You can enable these settings as follows:

newt target amend  
syscfg='BASELIBC_ASSERT_FILE_LINE=1:SYSINIT_PANIC_FILE_LINE=1:SYSINIT_PANIC_MESSAGE=1'

I would enable these settings, and then reproduce the crash.

To later disble these settings, you can use the following command:

newt target amend -d  
syscfg='BASELIBC_ASSERT_FILE_LINE:SYSINIT_PANIC_FILE_LINE:SYSINIT_PANIC_MESSAGE'

or just manually remove them from your
`targets//syscfg.yml` file.

Chris

[jira] [Updated] (MYNEWT-287) Host Flow Control

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-287:
---
Fix Version/s: (was: v1_3_0_rel)
   v1_4_0_rel

> Host Flow Control
> -
>
> Key: MYNEWT-287
> URL: https://issues.apache.org/jira/browse/MYNEWT-287
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
> Environment: Using nimble from an external host stack
>Reporter: Johan Hedberg
>    Assignee: Christopher Collins
> Fix For: v1_4_0_rel
>
>
> If the Nimble controller part is connected to an external host stack the host 
> may need to control the flow of ACL packets from the controller to the host. 
> This is particularly important for resource-constrained hosts that have a 
> limited amount of RX ACL data buffers.
> The Bluetooth core specification provides a standard feature to accomplish 
> this called Host Flow Control. (Vol 2, Part E, Section 4.2). To implement 
> this the controller needs to support the "Set Controller To Host Flow 
> Control", "Host Buffer Size" and "Host Number Of Completed Packets" HCI 
> commands.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-869) net/nimble/host unittest failures

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-869:
---
Description: 
tcore/pullsset the following syscfg variables:
OS_MEMPOOL_CHECK:
description: 'Whether to do stack sanity check of mempool operations'
value: 1
OS_MEMPOOL_POISON:
description: 'Whether to do write known pattern to freed memory'
value: 1

(gdb) run
Starting program: 
/Users/marko/src2/incubator-mynewt-blinky/repos/apache-mynewt-core/bin/targets/unittest/net_nimble_host_test/app/net/nimble/host/test/net_nimble_host_test.elf
 
[New Thread 0x1303 of process 64395]
warning: unhandled dyld version (15)
[pass] ble_att_clt_suite/ble_att_clt_test_tx_find_info 
[pass] ble_att_clt_suite/ble_att_clt_test_rx_find_info 
[pass] ble_att_clt_suite/ble_att_clt_test_tx_read 
[pass] ble_att_clt_suite/ble_att_clt_test_rx_read 
[pass] ble_att_clt_suite/ble_att_clt_test_tx_read_blob 
[pass] ble_att_clt_suite/ble_att_clt_test_rx_read_blob 
[pass] ble_att_clt_suite/ble_att_clt_test_tx_read_mult 
[pass] ble_att_clt_suite/ble_att_clt_test_rx_read_mult 
[pass] ble_att_clt_suite/ble_att_clt_test_tx_write 
[pass] ble_att_clt_suite/ble_att_clt_test_tx_prep_write 
[pass] ble_att_clt_suite/ble_att_clt_test_rx_prep_write 
[pass] ble_att_clt_suite/ble_att_clt_test_tx_exec_write 
[pass] ble_att_clt_suite/ble_att_clt_test_tx_mtu 
[pass] ble_att_svr_suite/ble_att_svr_test_mtu 
[pass] ble_att_svr_suite/ble_att_svr_test_read 
[pass] ble_att_svr_suite/ble_att_svr_test_read_blob 
[pass] ble_att_svr_suite/ble_att_svr_test_read_mult 
[pass] ble_att_svr_suite/ble_att_svr_test_write 
[pass] ble_att_svr_suite/ble_att_svr_test_find_info 
[pass] ble_att_svr_suite/ble_att_svr_test_find_type_value 
[pass] ble_att_svr_suite/ble_att_svr_test_read_type 
[pass] ble_att_svr_suite/ble_att_svr_test_read_group_type 
[pass] ble_att_svr_suite/ble_att_svr_test_prep_write 
[pass] ble_att_svr_suite/ble_att_svr_test_prep_write_tmo 
[pass] ble_att_svr_suite/ble_att_svr_test_notify 
[pass] ble_att_svr_suite/ble_att_svr_test_indicate 
[pass] ble_att_svr_suite/ble_att_svr_test_oom 
[pass] ble_gap_test_suite_wl/ble_gap_test_case_wl_good 
[pass] ble_gap_test_suite_wl/ble_gap_test_case_wl_bad_args 
[pass] ble_gap_test_suite_wl/ble_gap_test_case_wl_ctlr_fail 
[pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_bad_args 
[pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_good 
[pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_ltd_mismatch 
[pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_hci_fail 
[pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_dflts 
[pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_already 
[pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_busy 
[pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_good 
[pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_bad_args 
[pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_dflt_params 
[pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_already 
[pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_done 
[pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_busy 
[pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_fail_evt 
[pass] ble_gap_test_suite_conn_cancel/ble_gap_test_case_conn_cancel_good 
[pass] ble_gap_test_suite_conn_cancel/ble_gap_test_case_conn_cancel_bad_args 
[pass] ble_gap_test_suite_conn_cancel/ble_gap_test_case_conn_cancel_ctlr_fail 
[pass] 
ble_gap_test_suite_conn_terminate/ble_gap_test_case_conn_terminate_bad_args 
[pass] ble_gap_test_suite_conn_terminate/ble_gap_test_case_conn_terminate_good 
[pass] 
ble_gap_test_suite_conn_terminate/ble_gap_test_case_conn_terminate_ctlr_fail 
[pass] 
ble_gap_test_suite_conn_terminate/ble_gap_test_case_conn_terminate_hci_fail 
[pass] ble_gap_test_suite_conn_find/ble_gap_test_case_conn_find 
[pass] ble_gap_test_suite_adv/ble_gap_test_case_adv_bad_args 
[pass] ble_gap_test_suite_adv/ble_gap_test_case_adv_dflt_params 
[pass] ble_gap_test_suite_adv/ble_gap_test_case_adv_good 
[pass] ble_gap_test_suite_adv/ble_gap_test_case_adv_ctlr_fail 
[pass] ble_gap_test_suite_adv/ble_gap_test_case_adv_hci_fail 
[pass] ble_gap_test_suite_stop_adv/ble_gap_test_case_stop_adv_good 
[pass] ble_gap_test_suite_stop_adv/ble_gap_test_case_stop_adv_hci_fail 
[pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_conn_good 
[pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_conn_bad 
[pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_conn_hci_fail 
[pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_conn_l2cap 
[pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_peer_good 
[pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_req_good 
[pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_req_hci_fail 
[pass] ble_gap_test_suite_update_conn

Re: Inconsistent HAL GPIO semantics

[Christopher Collins]

On Mon, Nov 13, 2017 at 04:32:58PM -0800, will sanfilippo wrote:
> Chris:
> 
> Personally, I think there should be separate API as it is more flexible and 
> the API names more accurately describe what the API is doing.
> 
> I do realize that this is more work and given that there currently is no API 
> to clear a pending interrupt, I suspect that everyone who used the enable API 
> expected the interrupt to be cleared prior to enabling.
> 
> Another possible solution (and yes, I suspect folks might think this crazy):
> 
> * Rename the API to something like: hal_gpio_irq_clear_and_enable()
> * Make all implementations consistent and use this API.
> 
> This way we could add the separate API over time and the code will work as 
> expected. Yeah, I know, crazy thought :-)

I don't think that is crazy, but I think it might be a bit disruptive
for some users.  Any code that calls `hal_gpio_irq_enable()` will fail
to build after the rename.  I assume that is the point: make sure things
break loudly if they are going to break.  At the risk of sounding lazy,
that seems like it could be a lot of work for everyone :).  Especially
if we plan on ultimately deprecating `hal_gpio_irq_clear_and_enable()`.

Here is an alternative plan for introducing the API change:

v1.3:
- Don't change any implementations of `hal_gpio_irq_enable()`
- Add the `hal_gpio_set/clear` to the API
- Notify users that the behavior of `hal_gpio_irq_enable()` will
  be changing in the future (for some MCUs).
- Modify code in apache-mynewt-core such that it doesn't assume
  that `hal_gpio_irq_enable()` clears the pending interrupt.
  That is, explicitly call the new `clear` function prior to
  enabling the interrupt.

v1.x [not sure if this is v1.4 or a later release]:
- Modify implementations of `hal_gpio_irq_enable()` such that
  they only enable the interrupt (don't clear it).

Chris

Inconsistent HAL GPIO semantics

[Christopher Collins]

Hello all,

It appears there is some inconsistency among implementations of the
`hal_gpio_irq_enable()` function.  There are two behaviors associated
with this function:

(1) Enable the interrupt associated with the specified pin.
(2) Clear any pending interrupt associated with the specified pin.

All implementations perform (1); only some perform (2).

This email concerns the second item - should `hal_gpio_irq_enable()`
also clear the pending interrupt?

I can understand why it is useful for the function to perform both
actions.  Often, when some code temporarily disables an interrupt, it
wants to ensure that an interrupt triggered in the meantime does not
cause its ISR to be executed.  Since there is no HAL function to clear
interrupt state, the enable function is the natural place to implement
this behavior.

On the other hand, it could argued that a function which does both
things is too coarse an abstraction.  An application may want to perform
just one of the two actions.

In my view, there are two possible solutions:

1. Just make the behavior consistent: make all implementations of
`hal_gpio_irq_enable()` perform both actions.

2. Add some functions to the HAL:
a. Make all implementations of `hal_gpio_irq_enable()` only perform
   the first action.
b. Add `void hal_gpio_irq_clear(int pin)`
c. Add `void hal_gpio_irq_set(int pin)`

(or combine b and c into a single function.)

Option 2 introduces more of a backwards compatibility headache than 1
does.  Still, I think it is the better solution.

All comments welcome.

Thanks,
Chris

[jira] [Created] (MYNEWT-864) Newt - Cannot specify multiple-argument cflags

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-864:
--

 Summary: Newt - Cannot specify multiple-argument cflags
 Key: MYNEWT-864
 URL: https://issues.apache.org/jira/browse/MYNEWT-864
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Newt
Reporter: Christopher Collins
Assignee: Sterling Hughes
 Fix For: v1.3


For example:

{noformat}
pkg.cflags:
- '-include /usr/local/extra-includes'
{noformat}

The entire item, including the space, gets passed to gcc as a single argument.  
We need a way to specify multiple arguments for a single flag.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Mutex oddities with v1.0.0

[Christopher Collins]

I agree that a mutex should never have a null owner and a nonzero level.

Unfortunately, my first guess is some form of memory corruption:
it seems like a null value accidentally got written to `mu_owner`.  I
could be missing it, but I don't see any logic error in the mutex code
which could cause this.

Getting to the bottom of this is probably going to be difficult,
especially if it is not easy to reproduce.  I don't know how valuable
they are, but my two suggestions are:

1. Look at the `.lst` file that newt generates during a build to
determine what object immediately follows the mutex in RAM.  Maybe an
errant write intended for this object is clearing the owner field.

2. Instrument the code with a bunch of asserts and logs.  Maybe you can
catch the problem shortly after it happens.

Like I said, probably not the most helpful advice, but I don't think
this is going to be an easy one to solve!

Chris

On Mon, Nov 06, 2017 at 03:16:06PM -0800, Jitesh Shah wrote:
> Hey wil,
> Are you saying that because "mu_level" is set to 1?
> 
> It is set to 1 because the last call to os_mutex_release() failed on
> account of "mu_owner" not matching. Thus, the task that got the mutex
> failed to release it. That explains t_lockcnt and mu_level, right?
> 
> Jitesh
> 
> On Mon, Nov 6, 2017 at 7:56 AM, will sanfilippo  wrote:
> 
> > What this looks like to me is that there was a nested pend without the
> > same number of releases. Maybe some path out of some code that is rarely
> > hit where a mutex is granted but not released?
> >
> > Just a guess...
> >
> > > On Nov 5, 2017, at 8:26 PM, Jitesh Shah  wrote:
> > >
> > > Hey Guys,
> > > I am running v1.0.0 branch (0db6321a75deda126943aa187842da6b977cd1c1).
> > > Seeing some strange mutex behaviour.
> > >
> > > So once in a bazillion times, a mutex fails to release. Here is how the
> > > structure looks like when it fails:
> > >
> > >> (gdb) p/x send_mutex
> > >> $1 = {mu_head = {slh_first = 0x0}, _pad = 0x0, mu_prio = 0x1, mu_level =
> > >> 0x1, mu_owner = 0x0}
> > >
> > >
> > > Why is mu_owner set to 0? That causes the os_mutex_release call to fail
> > > since the current task doesn't match the owner task anymore.
> > >
> > > The task which holds the mutex looks like this:
> > >
> > >> (gdb) p/x cent_task
> > >> $3 = {t_stackptr = 0x20008a28, t_stacktop = 0x20008ac8, t_stacksize =
> > >> 0x80, t_taskid = 0x6, t_prio = 0x1, t_state = 0x1, t_flags = 0x10,
> > >> t_lockcnt = 0x1, t_pad = 0x0,
> > >>  t_name = 0x22378, t_func = 0x90ad, t_arg = 0x0, t_obj = 0x0,
> > >> t_sanity_check = {sc_checkin_last = 0x0, sc_checkin_itvl = 0x0, sc_func
> > =
> > >> 0x0, sc_arg = 0x0, sc_next = {
> > >>  sle_next = 0x0}}, t_next_wakeup = 0x0, t_run_time = 0x0,
> > >> t_ctx_sw_cnt = 0x213d, t_os_task_list = {stqe_next = 0x0}, t_os_list =
> > >> {tqe_next = 0x20001338,
> > >>tqe_prev = 0x21a8}, t_obj_list = {sle_next = 0x0}}
> > >
> > >
> > > Comparing t_prio and mu_prio, this confirms that this task is indeed
> > > holding the mutex (no other task is waiting on the mutex).
> > >
> > > What can happen that set mu_owner to 0? My original theory was that if a
> > > mutex_pend was called from an interrupt context, mu_owner would be 0. But
> > > in this case, the only task that is calling mutex is running an eventq,
> > so
> > > that is unlikely.
> > >
> > > Any ideas?
> > >
> > > 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.
> >
> >
> 
> -- 
> 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: How hard to do the following....

[Christopher Collins]

On Fri, Nov 03, 2017 at 01:56:15PM +0100, Szymon Janc wrote:
> Hi,
> 
> On Thursday, 2 November 2017 18:07:00 CET Greg Strange wrote:
> > To clarify, we don't need to advertise and scan at the same time. We will
> > have multiple radios with dedicated tasks. So we could have one radio
> > scanning on a single channel, a second radio on a second channel, a third
> > on a third, and a fourth radio being a beacon.
> > 
> > Sounds like everything is do-able, but will need some tweak to the API, or
> > bypassing the host API.
> 
> 
> I'm currently working on adding extended advertising support to Mynewt host 
> and this includes multi advertising support. I plan to finish that before 1.3 
> release.

Cool!

> Having support for multiple controllers in Mynewt is another thing and I 
> think 
> it will be non-trivial to add it. Especially if you want to make host aware 
> of 
> multiple controllers.

Greg, maybe you could clarify - do you want to run a separate BLE host
on each Nordic board?  I agree with Szymon that running a single host
with multiple controllers is nonstandard and would require quite a bit
of work.  If each board is running a host, that simplifies the task
considerably.

Chris

Re: How hard to do the following....

[Christopher Collins]

On Thu, Nov 02, 2017 at 09:10:59AM -0700, will sanfilippo wrote:
> Others can correct me if I am wrong but I will attempt to answer some of 
> these:
> 
> 1. Yes, the current code supports this.

I know the controller supports multiple advertisers, but I don't believe
this functionality is accessible through the host API.  To do this,
you'll need to talk directly to the controller via HCI commands (or
augment the host API to do it for you).

> 2. Yes, the current code supports this assuming you want to use a different 
> random address for each advertiser.

I think the host lacks support for this as well.

> 3. Yes, you can scan 100% of the time. Of course, if you advertise you wont 
> scan, and if you connect you will not scan during the connection event. 
> Otherwise, you will be scanning 100% of the time assuming you choose the 
> proper window and interval (if they are equal you scan 100% of the time).

There is no problem with advertising and scanning at the same time, is
there?

Chris

> 
> 
> > On Nov 2, 2017, at 8:49 AM, Greg Strange  wrote:
> > 
> > Hi,
> > 
> > We are kicking off a project that will have a number of NRF52840 radios,
> > each doing something slightly different. Right now we are trying to decide
> > whether we will use the Nordic SDK or mynewt. Some of the things we want to
> > do are well within mainstream BLE and should be easy. Some things are a bit
> > custom. I've glanced at the mynewt BLE API, but it is not clear whether a
> > few of our needs are directly supported without the need for us to get into
> > the core code.
> > 
> > Below is a list of a few features we want to support.  We'd love to hear
> > whether the features are directly supported by the API, or if not, your
> > opinions on the how involved it will be for us to add these features.
> > 
> > 1. We'd like a single radio to be advertising multiple advertising packets
> > at different intervals.  For example, it may be sending an iBeacon like
> > packet at 200ms, while also sending an EddyStone like packet at 250ms,
> > while also sending some other packet at some other interval.
> > 
> > 2. In case #1, we would also like the option of using a different
> > advertising address for each beacon.  E.g. the iBeacon advertising address
> > could be different than the address in the Eddystone beacon.
> > 
> > 3. We would like a radio to be able to listen for advertisement packets
> > 100% of the time. It looks like the API to turn on scanning takes interval
> > and window parameters. Can these be set up such that the radio is listening
> > 100% of the time?
> > 
> > 4. We'd like to dedicate a single radio to listening for advertisements on
> > a single channel. (In fact, we'd like to dedicate three radios, one to each
> > channel so that we are listening 100% of the time to each advertisement
> > channel.)  Is there a way to specify a single advertising channel when
> > scanning or listening for advertisements?
> > 
> > Are any of the above supported already in the API?
> > 
> > If not, are we looking at major rework, or simple changes in your opinions?
> > 
> > Thanks for any help
> > 
> > 
> > *Greg Strange*
> > Software Engineering Program Lead
> > 
> > *Synapse Product Development*
> > A Cambridge Consultants Company
> > mail 1511 6th Ave Suite 400, Seattle, WA 98101
> > direct +1-206-832-1269 ext. 3505 <+1-206-832-1269,3505> | office
> > +1-206-381-0898 | mobile +1-206-240-5605
> > g...@synapse.com | https://www.synapse.com
> > 
> > This email and any files transmitted with it are confidential. Unauthorized
> > publication, use or dissemination of this email is prohibited.
> > Please consider the environment before printing.
> 

[jira] [Updated] (MYNEWT-859) Newt crashes on invalid target setting

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-859:
---
Description: 
(Pull request: https://github.com/apache/mynewt-newt/pull/106)

If a target's {{target.yml}} file contains a setting whose value is not a 
string and not an integer, newt panics with a stack trace like this:

{noformat}
goroutine 1 [running]:
mynewt.apache.org/newt/newt/target.(*Target).Load(0xc42052c540, 0xc42049c070, 
0x3000100, 0x0)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:88
 +0x831
mynewt.apache.org/newt/newt/target.LoadTarget(0xc42049c070, 0x8, 0xc42045a680, 
0x6)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:63
 +0x5b
mynewt.apache.org/newt/newt/target.buildTargetMap(0x0, 0x8)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:281
 +0xe9
mynewt.apache.org/newt/newt/target.GetTargets(0x7fff5fbffbfa)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:301
 +0x48
mynewt.apache.org/newt/newt/cli.ResolveTarget(0x7fff5fbffbf3, 0x8, 0x0)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/util.go:86
 +0x9d
mynewt.apache.org/newt/newt/cli.ResolveTargetsOrAll(0xc420041300, 0x1, 0x1, 
0x1103d5d, 0xc42007a16c, 0xc42004fbf0, 0x11035c2, 0xc42007a16c, 0x14fb9d8)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/util.go:125
 +0xda
mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420089440, 0xc420041300, 0x1, 
0x1, 0x0)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:118
 +0x90
mynewt.apache.org/newt/newt/cli.AddBuildCommands.func1(0xc420089440, 
0xc420041300, 0x1, 0x1)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:404
 +0x5f
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420089440,
 0xc4200412c0, 0x1, 0x1, 0xc420089440, 0xc4200412c0)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
 +0x234
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420088fc0,
 0x5, 0x25, 0x14ea8fa)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
 +0x2fe
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420088fc0,
 0x14ea8fa, 0x5)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
 +0x2b
main.main()

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/newt.go:170
 +0x1ac
Add Comment
{noformat}

The code responsible for the panic is here in {{func (target *Target) Load()}}
{noformat}
settings := v.AllSettings()
for k, v := range settings {
var ok bool
target.Vars[k], ok = v.(string)
if !ok {
target.Vars[k] = strconv.Itoa(v.(int))
}
}
{noformat}

  was:
If a target's {{target.yml}} file contains a setting whose value is not a 
string and not an integer, newt panics with a stack trace like this:

{noformat}
goroutine 1 [running]:
mynewt.apache.org/newt/newt/target.(*Target).Load(0xc42052c540, 0xc42049c070, 
0x3000100, 0x0)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:88
 +0x831
mynewt.apache.org/newt/newt/target.LoadTarget(0xc42049c070, 0x8, 0xc42045a680, 
0x6)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:63
 +0x5b
mynewt.apache.org/newt/newt/target.buildTargetMap(0x0, 0x8)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:281
 +0xe9
mynewt.apache.org/newt/newt/target.GetTargets(0x7fff5fbffbfa)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:301
 +0x48
mynewt.apache.org/newt/newt/cli.ResolveTarget(0x7fff5fbffbf3, 0x8, 0x0)

/private/tmp/mynewt-newt-20170911

[jira] [Commented] (MYNEWT-860) Newt - Empty `pkg.yml` file causes target to be built as split image

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222906#comment-16222906
 ] 

Christopher Collins commented on MYNEWT-860:


Specifically, an empty {{pkg.yml}} file causes problems because it describes a 
package with no name.  When there is a package whose name is {{""}}, it matches 
some unset settings.  In this case, the target being built does not specify a 
{{target.loader}} value, as it is not a split image.  However, newt thinks the 
target actually specifies the unnamed packages as its loader, so it attempts to 
build a split image.

The fix is to ignore packages with no name (and warn the user).

> Newt - Empty `pkg.yml` file causes target to be built as split image
> 
>
> Key: MYNEWT-860
> URL: https://issues.apache.org/jira/browse/MYNEWT-860
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>    Reporter: Christopher Collins
>Assignee: Christopher Collins
>
> 1. Create a directory in your project:
> {noformat}
> mkdir blah
> {noformat}
> 2. Create an empty {{pkg.yml}} file in the directory:
> {noformat}
> touch blah/pkg.yml
> {noformat}
> 3. Build a non-split-image target.
> Newt will compile everything twice, as if it were building a split image.  
> Then it will fail in an unpredictable way, e.g.:
> {noformat}
> Error: In file included from apps/krang/src/main.c:23:0:
> repos/apache-mynewt-core/sys/sysinit/include/sysinit/sysinit.h:28:25: fatal 
> error: split/split.h: No such file or directory
>  #include "split/split.h"
> {noformat}
> {noformat}
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x12a71d4]
> goroutine 1 [running]:
> mynewt.apache.org/newt/newt/pkg.(*LocalPackage).Name(...)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
> mynewt.apache.org/newt/newt/builder.(*Builder).TestExePath(0xc4205307e0, 0x0, 
> 0x0)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179 +0x34
> mynewt.apache.org/newt/newt/builder.(*Builder).CompileCmdsPath(0xc4205307e0, 
> 0xc420308920, 0x0)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:198 +0xad
> mynewt.apache.org/newt/newt/builder.(*Builder).Build(0xc4205307e0, 0x0, 0x0)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/build.go:601 +0xa20
> mynewt.apache.org/newt/newt/builder.(*TargetBuilder).buildLoader(0xc420518120,
>  0x0, 0x0)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:319 
> +0xc6
> mynewt.apache.org/newt/newt/builder.(*TargetBuilder).Build(0xc420518120, 
> 0xc420518120, 0x0)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:372 
> +0x16d
> mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420090b40, 0xc420048d50, 0x1, 
> 0x1, 0x0)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:160 
> +0x2c9
> mynewt.apache.org/newt/newt/cli.AddBuildCommands.func1(0xc420090b40, 
> 0xc420048d50, 0x1, 0x1)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:404 +0x5f
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420090b40,
>  0xc420048d10, 0x1, 0x1, 0xc420090b40, 0xc420048d10)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
>  +0x234
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200906c0,
>  0x5, 0x25, 0x1399e93)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
>  +0x2fe
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200906c0,
>  0x1399e93, 0x5)
> 
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
>  +0x2b
> main.main()
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-860) Newt - Empty `pkg.yml` file causes target to be built as split image

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-860:
---
Description: 
1. Create a directory in your project:
{noformat}
mkdir blah
{noformat}

2. Create an empty {{pkg.yml}} file in the directory:
{noformat}
touch blah/pkg.yml
{noformat}

3. Build a non-split-image target.

Newt will compile everything twice, as if it were building a split image.  Then 
it will fail in an unpredictable way, e.g.:

{noformat}
Error: In file included from apps/krang/src/main.c:23:0:
repos/apache-mynewt-core/sys/sysinit/include/sysinit/sysinit.h:28:25: fatal 
error: split/split.h: No such file or directory
 #include "split/split.h"
{noformat}

{noformat}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x12a71d4]

goroutine 1 [running]:
mynewt.apache.org/newt/newt/pkg.(*LocalPackage).Name(...)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
mynewt.apache.org/newt/newt/builder.(*Builder).TestExePath(0xc4205307e0, 0x0, 
0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179 
+0x34
mynewt.apache.org/newt/newt/builder.(*Builder).CompileCmdsPath(0xc4205307e0, 
0xc420308920, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:198 
+0xad
mynewt.apache.org/newt/newt/builder.(*Builder).Build(0xc4205307e0, 0x0, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/build.go:601 
+0xa20
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).buildLoader(0xc420518120, 
0x0, 0x0)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:319 
+0xc6
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).Build(0xc420518120, 
0xc420518120, 0x0)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:372 
+0x16d
mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420090b40, 0xc420048d50, 0x1, 
0x1, 0x0)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:160 +0x2c9
mynewt.apache.org/newt/newt/cli.AddBuildCommands.func1(0xc420090b40, 
0xc420048d50, 0x1, 0x1)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:404 +0x5f
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420090b40,
 0xc420048d10, 0x1, 0x1, 0xc420090b40, 0xc420048d10)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
 +0x234
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200906c0,
 0x5, 0x25, 0x1399e93)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
 +0x2fe
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200906c0,
 0x1399e93, 0x5)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
 +0x2b
main.main()
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac
{noformat}

  was:
1. Create a directory in your project:
{noformat}
mkdir blah
{noformat}

2. Create an empty {pkg.yml} file in the directory:
{noformat}
touch blah/pkg.yml
{noformat}

3. Build a non-split-image target.

Newt will compile everything twice, as if it were building a split image.  Then 
it will fail in an unpredictable way, e.g.:

{noformat}
Error: In file included from apps/krang/src/main.c:23:0:
repos/apache-mynewt-core/sys/sysinit/include/sysinit/sysinit.h:28:25: fatal 
error: split/split.h: No such file or directory
 #include "split/split.h"
{noformat}

{noformat}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x12a71d4]

goroutine 1 [running]:
mynewt.apache.org/newt/newt/pkg.(*LocalPackage).Name(...)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
mynewt.apache.org/newt/newt/builder.(*Builder).TestExePath(0xc4205307e0, 0x0, 
0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179 
+0x34
mynewt.apache.org/newt/newt/builder.(*Builder).CompileCmdsPath(0xc4205307e0, 
0xc420308920, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:198 
+0xad
mynewt.apache.org/newt/newt/builder.(*Builder).Build(0xc4205307e0, 0x0, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/build.go:601 
+0xa20
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).buildLoader(0xc420518120, 
0x0, 0x0)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:319 
+0xc6
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).Build(0xc420518120, 
0xc420518120, 0x0)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:372 
+0x16d
mynewt.apache.org/newt/newt/cli.buil

[jira] [Created] (MYNEWT-860) Newt - Empty `pkg.yml` file causes target to be built as split image

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-860:
--

 Summary: Newt - Empty `pkg.yml` file causes target to be built as 
split image
 Key: MYNEWT-860
 URL: https://issues.apache.org/jira/browse/MYNEWT-860
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Newt
Reporter: Christopher Collins
Assignee: Christopher Collins


1. Create a directory in your project:
{noformat}
mkdir blah
{noformat}

2. Create an empty {pkg.yml} file in the directory:
{noformat}
touch blah/pkg.yml
{noformat}

3. Build a non-split-image target.

Newt will compile everything twice, as if it were building a split image.  Then 
it will fail in an unpredictable way, e.g.:

{noformat}
Error: In file included from apps/krang/src/main.c:23:0:
repos/apache-mynewt-core/sys/sysinit/include/sysinit/sysinit.h:28:25: fatal 
error: split/split.h: No such file or directory
 #include "split/split.h"
{noformat}

{noformat}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x12a71d4]

goroutine 1 [running]:
mynewt.apache.org/newt/newt/pkg.(*LocalPackage).Name(...)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
mynewt.apache.org/newt/newt/builder.(*Builder).TestExePath(0xc4205307e0, 0x0, 
0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179 
+0x34
mynewt.apache.org/newt/newt/builder.(*Builder).CompileCmdsPath(0xc4205307e0, 
0xc420308920, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:198 
+0xad
mynewt.apache.org/newt/newt/builder.(*Builder).Build(0xc4205307e0, 0x0, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/build.go:601 
+0xa20
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).buildLoader(0xc420518120, 
0x0, 0x0)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:319 
+0xc6
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).Build(0xc420518120, 
0xc420518120, 0x0)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:372 
+0x16d
mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420090b40, 0xc420048d50, 0x1, 
0x1, 0x0)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:160 +0x2c9
mynewt.apache.org/newt/newt/cli.AddBuildCommands.func1(0xc420090b40, 
0xc420048d50, 0x1, 0x1)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:404 +0x5f
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420090b40,
 0xc420048d10, 0x1, 0x1, 0xc420090b40, 0xc420048d10)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
 +0x234
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200906c0,
 0x5, 0x25, 0x1399e93)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
 +0x2fe
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200906c0,
 0x1399e93, 0x5)

/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
 +0x2b
main.main()
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYNEWT-805) Better support for private repos

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-805.

Resolution: Fixed

> Better support for private repos
> 
>
> Key: MYNEWT-805
> URL: https://issues.apache.org/jira/browse/MYNEWT-805
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Reporter: Todd Mitton
>Assignee: Todd Mitton
>Priority: Minor
>
> A password or personal access token must be specified in project.yml for 
> `newt install` to access a private repo. This makes it hard to use private 
> repos in automated environments because it would require checking in the 
> clear text password/token.
> We should add support for getting the password/token from an env variables.  
> CI systems like jenkins, travis, etc. securely store secrets and make them 
> available to builds through env variables.
> Even better then env variables is to use ssh instead of https. Private repos 
> can be accessed via ssh, and newt can simply use the local ssh agent when 
> accessing the private repo.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: BLE Host - Removing the BLE_GAP_EVENT_CONN_CANCEL event type

[Christopher Collins]

On Thu, Oct 19, 2017 at 12:07:58PM -0700, Christopher Collins wrote:
> On Fri, Oct 13, 2017 at 10:18:14AM -0700, Christopher Collins wrote:
> > * 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.
> 
> After some discussion in the pull request page
> (https://github.com/apache/mynewt-core/pull/632), I'm not sure it makes
> sense to try to slowly "phase out" this behavior.  Since this change
> represents a change in behavior, rather than the removal of
> functionality, I don't think there is a good way to deprecate it.  The
> two basic options are:
> 
> 1. Keep deprecated symbols in the code base, but stop using them.  Apps
> will continue to build without errors, but any app relying on the old
> behavior will silently break.
> 
> 2. Remove unused symbols.  This may introduce build errors for some
> apps, but at least there is no silent breakage.
> 
> We could also try some hybrid approach, e.g., send both types of GAP
> events when a connection is cancelled.  However, I think this would do
> more harm than good (and probably introduce some new bugs!).
> 
> The release policy document's section on backwards compatibility
> (https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Policy#ReleaseandSupportPolicy-BackwardsCompatibility)
> is pretty clear - if an API change has the potential to break builds,
> deprecate the old behavior for at least six months before removing it.
> I think this text needs some additional language for changes such as
> this one that can't be reasonably phased in.

I propose we add the following text to the release policy:

Sometimes it is impossible or impractical to retain a deprecated
version of an API alongside the new one.  For example, a change to
a callback function's type, such as the addition of a new parameter,
is difficult to introduce while still maintaining the old API.  For
these types of changes, the `deprecated` state can be bypassed.
Such changes must be voted on by the community before they are
implemented.

If there are no objections, I will make this addition to the wiki.

Thanks,
Chris

[jira] [Created] (MYNEWT-859) Newt crashes on invalid target setting

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-859:
--

 Summary: Newt crashes on invalid target setting
 Key: MYNEWT-859
 URL: https://issues.apache.org/jira/browse/MYNEWT-859
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Newt
Reporter: Christopher Collins
Assignee: Sterling Hughes
 Fix For: v1_3_0_rel


If a target's {{target.yml}} file contains a setting whose value is not a 
string and not an integer, newt panics with a stack trace like this:

{noformat}
goroutine 1 [running]:
mynewt.apache.org/newt/newt/target.(*Target).Load(0xc42052c540, 0xc42049c070, 
0x3000100, 0x0)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:88
 +0x831
mynewt.apache.org/newt/newt/target.LoadTarget(0xc42049c070, 0x8, 0xc42045a680, 
0x6)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:63
 +0x5b
mynewt.apache.org/newt/newt/target.buildTargetMap(0x0, 0x8)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:281
 +0xe9
mynewt.apache.org/newt/newt/target.GetTargets(0x7fff5fbffbfa)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:301
 +0x48
mynewt.apache.org/newt/newt/cli.ResolveTarget(0x7fff5fbffbf3, 0x8, 0x0)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/util.go:86
 +0x9d
mynewt.apache.org/newt/newt/cli.ResolveTargetsOrAll(0xc420041300, 0x1, 0x1, 
0x1103d5d, 0xc42007a16c, 0xc42004fbf0, 0x11035c2, 0xc42007a16c, 0x14fb9d8)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/util.go:125
 +0xda
mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420089440, 0xc420041300, 0x1, 
0x1, 0x0)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:118
 +0x90
mynewt.apache.org/newt/newt/cli.AddBuildCommands.func1(0xc420089440, 
0xc420041300, 0x1, 0x1)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:404
 +0x5f
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420089440,
 0xc4200412c0, 0x1, 0x1, 0xc420089440, 0xc4200412c0)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
 +0x234
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420088fc0,
 0x5, 0x25, 0x14ea8fa)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
 +0x2fe
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420088fc0,
 0x14ea8fa, 0x5)

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
 +0x2b
main.main()

/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/newt.go:170
 +0x1ac
Add Comment
{noformat}

The code responsible for the panic is here in {{func (target *Target) Load()}}
{noformat}
settings := v.AllSettings()
for k, v := range settings {
var ok bool
target.Vars[k], ok = v.(string)
if !ok {
target.Vars[k] = strconv.Itoa(v.(int))
}
}
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-858) Test package lflags ignored by `newt test`

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-858:
---
Description: 
If you add the following to a test package:

{noformat}
pkg.lflags:
- "-foo"
{noformat}

and then test the package with `newt test`, the flag does not get passed to gcc 
during linking.

Newt currently only reads lflags from the following package types:
* target
* app
* bsp
* compiler

At the very least, the test package's lflags should be used when a unit test is 
linked via {{newt test}}.  Alternatively, it may make more sense to gather the 
lflags from all constituent packages during the link phase.


  was:
If you add the following to a test package:

{noformat}
pkg.lflags:
- "-foo"
{noformat}

and then test the package with `newt test`, the flag does not get passed to gcc 
during linking.

Newt currently only reads lflags from the following package types:
* target
* app
* bsp
* compiler

At the very least, the test package's lflags should be used when a unit test is 
linked via {newt test}.  Alternatively, it may make more sense to gather the 
lflags from all constituent packages during the link phase.



> Test package lflags ignored by `newt test`
> --
>
> Key: MYNEWT-858
> URL: https://issues.apache.org/jira/browse/MYNEWT-858
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>      Components: Newt
>Reporter: Christopher Collins
>Assignee: Sterling Hughes
> Fix For: v1_3_0_rel
>
>
> If you add the following to a test package:
> {noformat}
> pkg.lflags:
> - "-foo"
> {noformat}
> and then test the package with `newt test`, the flag does not get passed to 
> gcc during linking.
> Newt currently only reads lflags from the following package types:
> * target
> * app
> * bsp
> * compiler
> At the very least, the test package's lflags should be used when a unit test 
> is linked via {{newt test}}.  Alternatively, it may make more sense to gather 
> the lflags from all constituent packages during the link phase.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYNEWT-857) BLE Controller - incompatibility with iOS 11

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209721#comment-16209721
 ] 

Christopher Collins edited comment on MYNEWT-857 at 10/18/17 5:42 PM:
--

Hmm, that's interesting.  Maybe the problem isn't the type of PDU that gets 
sent, but how early it gets sent.  I have attached a pcap file showing the 
successful connect (with the feature exchange commented out).  The CONNET_REQ 
is at packet #285718.


was (Author: ccollins476):
Hmm, that's interesting.  Maybe the problem isn't the type of PDU that gets 
sent, but how early it gets sent.  I have attached a pcap file showing the 
successful connect (with the feature exchange commented out).

> BLE Controller - incompatibility with iOS 11
> 
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap, 
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but 
> the CoreBluetooth {{didConnect()}} callback does not get called.  A packet 
> trace (see attached) shows that the iPhone never initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature 
> Exchange Procedure immediately after connection establishment. The 
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file, the CONNECT_REQ is at packet #6211.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-857) BLE Controller - incompatibility with iOS 11

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-857:
---
Attachment: ios2nimble-no-feat.pcap

Hmm, that's interesting.  Maybe the problem isn't the type of PDU that gets 
sent, but how early it gets sent.  I have attached a pcap file showing the 
successful connect (with the feature exchange commented out).

> BLE Controller - incompatibility with iOS 11
> 
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap, 
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but 
> the CoreBluetooth {{didConnect()}} callback does not get called.  A packet 
> trace (see attached) shows that the iPhone never initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature 
> Exchange Procedure immediately after connection establishment. The 
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file, the CONNECT_REQ is at packet #6211.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-842.

Resolution: Fixed

> BLE Host - Handle failure to add entry to resolving list
> 
>
> Key: MYNEWT-842
> URL: https://issues.apache.org/jira/browse/MYNEWT-842
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_3_0_rel
>
>
> (Pull request: https://github.com/apache/mynewt-core/pull/596)
> If an attempt to add a peer's IRK to the resolving list fails, the failure is 
> not reported, and the operation is not reattempted.  Adding to the resolving 
> list fails if the host is scanning or advertising at the time, so this is a 
> common occurrence.
> I am not sure what the best solution is to this problem.  I have a few ideas 
> (order of increasing complexity):
> 1. The host stops all active GAP procedures before trying to add the entry to 
> the resolving list.  The application must restart interrupted procedures as 
> needed.
> 2. The host passes the necessary information up to the application.  It is 
> then up to the application to populate the resolving list when possible (or 
> not).
> 3. The host remembers the failed attempt and retries when in a suitable state 
> (i.e., when advertising, scanning, and connecting has stopped).
> 4. The host temporarily suspends all GAP activity, adds the entry to the 
> resolving list, and resumes GAP activity.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYNEWT-851) newt - Private repo password displayed by `git remote -v`

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-851.

Resolution: Fixed

> newt - Private repo password displayed by `git remote -v`
> -
>
> Key: MYNEWT-851
> URL: https://issues.apache.org/jira/browse/MYNEWT-851
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1.3
>
>
> (Pull request: https://github.com/apache/mynewt-newt/pull/101)
> For private repos, the user's login and password are part of the repo URL.  
> E.g.,
> {noformat}
> wes@~/dev/work/repos/private-repo$ git remote -v
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git 
> (fetch)
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git 
> (push)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYNEWT-857) BLE Controller - incompatibility with iOS 11

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-857:
--

 Summary: BLE Controller - incompatibility with iOS 11
 Key: MYNEWT-857
 URL: https://issues.apache.org/jira/browse/MYNEWT-857
 Project: Mynewt
  Issue Type: Task
  Security Level: Public (Viewable by anyone)
  Components: Nimble
Reporter: Christopher Collins
 Fix For: v1.3
 Attachments: ios2nimble.pcap

Master: iPhone running iOS 11
Slave: NimBLE device

The iPhone successfully establishes a connection to the NimBLE device, but the 
CoreBluetooth {{didConnect()}} callback does not get called.  A packet trace 
(see attached) shows that the iPhone never initiates service discovery.

The problem seems to occur when the NimBLE controller initiates the Feature 
Exchange Procedure immediately after connection establishment. The 
{{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.  
When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of 
{{ble_ll_conn_created()}}, the iOS device is able to connect and perform 
service discovery, resulting in the CoreBluetooth callback being executed.

In the attached pcap file, the CONNECT_REQ is at packet #6211.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-842:
---
Fix Version/s: v1_3_0_rel

> BLE Host - Handle failure to add entry to resolving list
> 
>
> Key: MYNEWT-842
> URL: https://issues.apache.org/jira/browse/MYNEWT-842
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_3_0_rel
>
>
> (Pull request: https://github.com/apache/mynewt-core/pull/596)
> If an attempt to add a peer's IRK to the resolving list fails, the failure is 
> not reported, and the operation is not reattempted.  Adding to the resolving 
> list fails if the host is scanning or advertising at the time, so this is a 
> common occurrence.
> I am not sure what the best solution is to this problem.  I have a few ideas 
> (order of increasing complexity):
> 1. The host stops all active GAP procedures before trying to add the entry to 
> the resolving list.  The application must restart interrupted procedures as 
> needed.
> 2. The host passes the necessary information up to the application.  It is 
> then up to the application to populate the resolving list when possible (or 
> not).
> 3. The host remembers the failed attempt and retries when in a suitable state 
> (i.e., when advertising, scanning, and connecting has stopped).
> 4. The host temporarily suspends all GAP activity, adds the entry to the 
> resolving list, and resumes GAP activity.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (MYNEWT-851) newt - Private repo password displayed by `git remote -v`

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reassigned MYNEWT-851:
--

Assignee: Christopher Collins  (was: Sterling Hughes)

> newt - Private repo password displayed by `git remote -v`
> -
>
> Key: MYNEWT-851
> URL: https://issues.apache.org/jira/browse/MYNEWT-851
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1.3
>
>
> (Pull request: https://github.com/apache/mynewt-newt/pull/101)
> For private repos, the user's login and password are part of the repo URL.  
> E.g.,
> {noformat}
> wes@~/dev/work/repos/private-repo$ git remote -v
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git 
> (fetch)
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git 
> (push)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-851) newt - Private repo password displayed by `git remote -v`

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-851:
---
Summary: newt - Private repo password displayed by `git remote -v`  (was: 
newt - Private repo password displayed by `git status`)

> newt - Private repo password displayed by `git remote -v`
> -
>
> Key: MYNEWT-851
> URL: https://issues.apache.org/jira/browse/MYNEWT-851
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>        Reporter: Christopher Collins
>Assignee: Sterling Hughes
> Fix For: v1.3
>
>
> For private repos, the user's login and password are part of the repo URL.  
> E.g.,
> {noformat}
> wes@~/dev/work/repos/private-repo$ git remote -v
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git 
> (fetch)
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git 
> (push)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYNEWT-850) testutil - revisit output options

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-850:
--

 Summary: testutil - revisit output options
 Key: MYNEWT-850
 URL: https://issues.apache.org/jira/browse/MYNEWT-850
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Misc
Reporter: Christopher Collins
 Fix For: v1_3_0_rel


Options for text output during `newt test` are limited or incorrect in many 
cases.

1. Provide a mechanism for miscellaneous output (e.g., intermediate 
calculations).
2. Allow for a "verbose test mode" - Prints all test results and any 
intermediate output contained in the unit tests.  This should be possible 
without newt's `-v` option, which prints out a bunch of unrelated text.
3. The `ts_print_results` option in the `ts_config` struct is redundant.  We 
should just use the pass and fail callbacks to print results.

...and possibly more.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-842:
---
Description: 
(Pull request: 
If an attempt to add a peer's IRK to the resolving list fails, the failure is 
not reported, and the operation is not reattempted.  Adding to the resolving 
list fails if the host is scanning or advertising at the time, so this is a 
common occurrence.

I am not sure what the best solution is to this problem.  I have a few ideas 
(order of increasing complexity):

1. The host stops all active GAP procedures before trying to add the entry to 
the resolving list.  The application must restart interrupted procedures as 
needed.
2. The host passes the necessary information up to the application.  It is then 
up to the application to populate the resolving list when possible (or not).
3. The host remembers the failed attempt and retries when in a suitable state 
(i.e., when advertising, scanning, and connecting has stopped).
4. The host temporarily suspends all GAP activity, adds the entry to the 
resolving list, and resumes GAP activity.

  was:
If an attempt to add a peer's IRK to the resolving list fails, the failure is 
not reported, and the operation is not reattempted.  Adding to the resolving 
list fails if the host is scanning or advertising at the time, so this is a 
common occurrence.

I am not sure what the best solution is to this problem.  I have a few ideas 
(order of increasing complexity):

1. The host stops all active GAP procedures before trying to add the entry to 
the resolving list.  The application must restart interrupted procedures as 
needed.
2. The host passes the necessary information up to the application.  It is then 
up to the application to populate the resolving list when possible (or not).
3. The host remembers the failed attempt and retries when in a suitable state 
(i.e., when advertising, scanning, and connecting has stopped).
4. The host temporarily suspends all GAP activity, adds the entry to the 
resolving list, and resumes GAP activity.


> BLE Host - Handle failure to add entry to resolving list
> 
>
> Key: MYNEWT-842
> URL: https://issues.apache.org/jira/browse/MYNEWT-842
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
>
> (Pull request: 
> If an attempt to add a peer's IRK to the resolving list fails, the failure is 
> not reported, and the operation is not reattempted.  Adding to the resolving 
> list fails if the host is scanning or advertising at the time, so this is a 
> common occurrence.
> I am not sure what the best solution is to this problem.  I have a few ideas 
> (order of increasing complexity):
> 1. The host stops all active GAP procedures before trying to add the entry to 
> the resolving list.  The application must restart interrupted procedures as 
> needed.
> 2. The host passes the necessary information up to the application.  It is 
> then up to the application to populate the resolving list when possible (or 
> not).
> 3. The host remembers the failed attempt and retries when in a suitable state 
> (i.e., when advertising, scanning, and connecting has stopped).
> 4. The host temporarily suspends all GAP activity, adds the entry to the 
> resolving list, and resumes GAP activity.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-842:
---
Description: 
If an attempt to add a peer's IRK to the resolving list fails, the failure is 
not reported, and the operation is not reattempted.  Adding to the resolving 
list fails if the host is scanning or advertising at the time, so this is a 
common occurrence.

I am not sure what the best solution is to this problem.  I have a few ideas 
(order of increasing complexity):

1. The host stops all active GAP procedures before trying to add the entry to 
the resolving list.  The application must restart interrupted procedures as 
needed.
2. The host passes the necessary information up to the application.  It is then 
up to the application to populate the resolving list when possible (or not).
3. The host remembers the failed attempt and retries when in a suitable state 
(i.e., when advertising, scanning, and connecting has stopped).
4. The host temporarily suspends all GAP activity, adds the entry to the 
resolving list, and resumes GAP activity.

  was:
If an attempt to add a peer's IRK to the resolving list fails, the failure is 
not reported, and the operation is not reattempted.  Adding to the resolving 
list fails if the host is scanning or advertising at the time, so this is a 
common occurrence.

I am not sure what the best solution is to this problem.  I have a few ideas 
(order of increasing complexity):

1. The host passes the necessary information up to the application.  It is then 
up to the application to populate the resolving list when possible (or not).
2. The host remembers the failed attempt and retries when in a suitable state 
(i.e., when advertising, scanning, and connecting has stopped).
3. The host temporarily suspends all GAP activity, adds the entry to the 
resolving list, and resumes GAP activity.


> BLE Host - Handle failure to add entry to resolving list
> 
>
> Key: MYNEWT-842
> URL: https://issues.apache.org/jira/browse/MYNEWT-842
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
>
> If an attempt to add a peer's IRK to the resolving list fails, the failure is 
> not reported, and the operation is not reattempted.  Adding to the resolving 
> list fails if the host is scanning or advertising at the time, so this is a 
> common occurrence.
> I am not sure what the best solution is to this problem.  I have a few ideas 
> (order of increasing complexity):
> 1. The host stops all active GAP procedures before trying to add the entry to 
> the resolving list.  The application must restart interrupted procedures as 
> needed.
> 2. The host passes the necessary information up to the application.  It is 
> then up to the application to populate the resolving list when possible (or 
> not).
> 3. The host remembers the failed attempt and retries when in a suitable state 
> (i.e., when advertising, scanning, and connecting has stopped).
> 4. The host temporarily suspends all GAP activity, adds the entry to the 
> resolving list, and resumes GAP activity.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYNEWT-841) BLE Host - Populate resolving list with persisted IRKs at startup

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-841.

Resolution: Fixed

> BLE Host - Populate resolving list with persisted IRKs at startup
> -
>
> Key: MYNEWT-841
> URL: https://issues.apache.org/jira/browse/MYNEWT-841
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
>
> (Pull request: https://github.com/apache/mynewt-core/pull/593)
> Identity information gets persisted during pairing, but it is never restored 
> after a reboot.  At startup (and on stack reset), the host should populate 
> the resolving list with the persisted entries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reassigned MYNEWT-842:
--

Assignee: Christopher Collins

> BLE Host - Handle failure to add entry to resolving list
> 
>
> Key: MYNEWT-842
> URL: https://issues.apache.org/jira/browse/MYNEWT-842
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
>
> If an attempt to add a peer's IRK to the resolving list fails, the failure is 
> not reported, and the operation is not reattempted.  Adding to the resolving 
> list fails if the host is scanning or advertising at the time, so this is a 
> common occurrence.
> I am not sure what the best solution is to this problem.  I have a few ideas 
> (order of increasing complexity):
> 1. The host passes the necessary information up to the application.  It is 
> then up to the application to populate the resolving list when possible (or 
> not).
> 2. The host remembers the failed attempt and retries when in a suitable state 
> (i.e., when advertising, scanning, and connecting has stopped).
> 3. The host temporarily suspends all GAP activity, adds the entry to the 
> resolving list, and resumes GAP activity.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (MYNEWT-841) BLE Host - Populate resolving list with persisted IRKs at startup

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reassigned MYNEWT-841:
--

Assignee: Christopher Collins

> BLE Host - Populate resolving list with persisted IRKs at startup
> -
>
> Key: MYNEWT-841
> URL: https://issues.apache.org/jira/browse/MYNEWT-841
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
>
> (Pull request: https://github.com/apache/mynewt-core/pull/593)
> Identity information gets persisted during pairing, but it is never restored 
> after a reboot.  At startup (and on stack reset), the host should populate 
> the resolving list with the persisted entries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-841) BLE Host - Populate resolving list with persisted IRKs at startup

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-841:
---
Description: 
(Pull request: https://github.com/apache/mynewt-core/pull/593)

Identity information gets persisted during pairing, but it is never restored 
after a reboot.  At startup (and on stack reset), the host should populate the 
resolving list with the persisted entries.

  was:Identity information gets persisted during pairing, but it is never 
restored after a reboot.  At startup (and on stack reset), the host should 
populate the resolving list with the persisted entries.


> BLE Host - Populate resolving list with persisted IRKs at startup
> -
>
> Key: MYNEWT-841
> URL: https://issues.apache.org/jira/browse/MYNEWT-841
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>
> (Pull request: https://github.com/apache/mynewt-core/pull/593)
> Identity information gets persisted during pairing, but it is never restored 
> after a reboot.  At startup (and on stack reset), the host should populate 
> the resolving list with the persisted entries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-842:
---
Description: 
If an attempt to add a peer's IRK to the resolving list fails, the failure is 
not reported, and the operation is not reattempted.  Adding to the resolving 
list fails if the host is scanning or advertising at the time, so this is a 
common occurrence.

I am not sure what the best solution is to this problem.  I have a few ideas 
(order of increasing complexity):

1. The host passes the necessary information up to the application.  It is then 
up to the application to populate the resolving list when possible (or not).
2. The host remembers the failed attempt and retries when in a suitable state 
(i.e., when advertising, scanning, and connecting has stopped).
3. The host temporarily suspends all GAP activity, adds the entry to the 
resolving list, and resumes GAP activity.

  was:
If an attempt to add a peer's IRK to the resolving list fails, the failure is 
not reported, and the operation is not reattempted.  Adding to the resolving 
list fails if the host is scanning or advertising at the time, so this is a 
common occurrence.

I am not sure what the best solution is to this problem.  I have a few ideas 
(order of increasing complexity):

1. The host passes the necessary information up to the application.  It is then 
up to the application to populate the resolving list when possible, if desired.
2. The host remembers the failed attempt and retries when in a suitable state 
(i.e., when advertising, scanning, and connecting has stopped).
3. The host temporarily suspends all GAP activity, adds the entry to the 
resolving list, and resumes GAP activity.


> BLE Host - Handle failure to add entry to resolving list
> 
>
> Key: MYNEWT-842
> URL: https://issues.apache.org/jira/browse/MYNEWT-842
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>
> If an attempt to add a peer's IRK to the resolving list fails, the failure is 
> not reported, and the operation is not reattempted.  Adding to the resolving 
> list fails if the host is scanning or advertising at the time, so this is a 
> common occurrence.
> I am not sure what the best solution is to this problem.  I have a few ideas 
> (order of increasing complexity):
> 1. The host passes the necessary information up to the application.  It is 
> then up to the application to populate the resolving list when possible (or 
> not).
> 2. The host remembers the failed attempt and retries when in a suitable state 
> (i.e., when advertising, scanning, and connecting has stopped).
> 3. The host temporarily suspends all GAP activity, adds the entry to the 
> resolving list, and resumes GAP activity.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-842:
---
Description: 
If an attempt to add a peer's IRK to the resolving list fails, the failure is 
not reported, and the operation is not reattempted.  Adding to the resolving 
list fails if the host is scanning or advertising at the time, so this is a 
common occurrence.

I am not sure what the best solution is to this problem.  I have a few ideas 
(order of increasing complexity):

1. The host passes the necessary information up to the application.  It is then 
up to the application to populate the resolving list when possible, if desired.
2. The host remembers the failed attempt and retries when in a suitable state 
(i.e., when advertising, scanning, and connecting has stopped).
3. The host temporarily suspends all GAP activity, adds the entry to the 
resolving list, and resumes GAP activity.

  was:
If an attempt to add a peer's IRK to the resolving list fails, the failure is 
not reported, and the operation is not reattempted.  Adding to the resolving 
list fails if the host is scanning or advertising at the time, so this is a 
common occurrence.

I am not sure what the best solution is to this problem.  I have a few ideas:

1. The host should pass the necessary information up to the application.  It is 
up to the application to populate the resolving list when possible.

2. The host should remember the failed attempt and retry when it is in a 
suitable state (i.e., when advertising, scanning, and connecting has stopped).


> BLE Host - Handle failure to add entry to resolving list
> 
>
> Key: MYNEWT-842
> URL: https://issues.apache.org/jira/browse/MYNEWT-842
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>
> If an attempt to add a peer's IRK to the resolving list fails, the failure is 
> not reported, and the operation is not reattempted.  Adding to the resolving 
> list fails if the host is scanning or advertising at the time, so this is a 
> common occurrence.
> I am not sure what the best solution is to this problem.  I have a few ideas 
> (order of increasing complexity):
> 1. The host passes the necessary information up to the application.  It is 
> then up to the application to populate the resolving list when possible, if 
> desired.
> 2. The host remembers the failed attempt and retries when in a suitable state 
> (i.e., when advertising, scanning, and connecting has stopped).
> 3. The host temporarily suspends all GAP activity, adds the entry to the 
> resolving list, and resumes GAP activity.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYNEWT-843) BLE Host - Missing local IRK functionality

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-843:
--

 Summary: BLE Host - Missing local IRK functionality
 Key: MYNEWT-843
 URL: https://issues.apache.org/jira/browse/MYNEWT-843
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Nimble
Reporter: Christopher Collins


The host needs a few improvements involving the local identity resolving key 
(IRK):

1. Expose function to set the local IRK to a specified value 
(`ble_hs_test_util_set_our_irk()` is currently private).

2. Create a function to randomly generate a new IRK.

3. When a new local IRK is created, automatically persist it to the store.

4. On startup, restore the persisted IRK from the store.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-842:
--

 Summary: BLE Host - Handle failure to add entry to resolving list
 Key: MYNEWT-842
 URL: https://issues.apache.org/jira/browse/MYNEWT-842
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Nimble
Reporter: Christopher Collins


If an attempt to add a peer's IRK to the resolving list fails, the failure is 
not reported, and the operation is not reattempted.  Adding to the resolving 
list fails if the host is scanning or advertising at the time, so this is a 
common occurrence.

I am not sure what the best solution is to this problem.  I have a few ideas:

1. The host should pass the necessary information up to the application.  It is 
up to the application to populate the resolving list when possible.

2. The host should remember the failed attempt and retry when it is in a 
suitable state (i.e., when advertising, scanning, and connecting has stopped).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-841) BLE Host - Populate resolving list with persisted IRKs at startup

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-841:
---
Component/s: Nimble

> BLE Host - Populate resolving list with persisted IRKs at startup
> -
>
> Key: MYNEWT-841
> URL: https://issues.apache.org/jira/browse/MYNEWT-841
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>
> Identity information gets persisted during pairing, but it is never restored 
> after a reboot.  At startup (and on stack reset), the host should populate 
> the resolving list with the persisted entries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYNEWT-841) BLE Host - Populate resolving list with persisted IRKs at startup

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-841:
--

 Summary: BLE Host - Populate resolving list with persisted IRKs at 
startup
 Key: MYNEWT-841
 URL: https://issues.apache.org/jira/browse/MYNEWT-841
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Reporter: Christopher Collins


Identity information gets persisted during pairing, but it is never restored 
after a reboot.  At startup (and on stack reset), the host should populate the 
resolving list with the persisted entries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Priority violation in syscfg building 1_2_0_dev

[Christopher Collins]

I think you need a newer version of newt.  The syscfg override rules
were relaxed in newt 1.1.  Now, a package can override its own settings.

Unfortunately, it looks like we failed to add the necessary newt
compatibility rules to the core repo in 1.1.  You should have gotten a
clearer error message from newt.

Chris

On Tue, Sep 05, 2017 at 07:16:10PM -0700, Simon Ratner wrote:
> Got the following trying to build my app on 1.2 (moving from pre-1.1):
> 
> Error: Priority violations detected (Packages can only override settings
> defined by packages of lower priority):
> Package: net/nimble/controller overriding setting:
> BLE_LL_CFG_FEAT_LE_CSA2 defined by net/nimble/controller
> Package: net/nimble/controller overriding setting:
> BLE_HW_WHITELIST_ENABLE defined by net/nimble/controller
> Package: net/nimble/controller overriding setting:
> BLE_LL_EXT_ADV_AUX_PTR_CNT defined by net/nimble/controller
> 
> Setting history (newest -> oldest):
> BLE_HW_WHITELIST_ENABLE: [net/nimble/controller:1]
> BLE_LL_CFG_FEAT_LE_CSA2: [net/nimble/controller:0]
> BLE_LL_EXT_ADV_AUX_PTR_CNT: [net/nimble/controller:0]
> 
> Newt seems confused?

[jira] [Resolved] (MYNEWT-185) Clearly Define Linker script requirements

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-185.

Resolution: Fixed

> Clearly Define Linker script requirements
> -
>
> Key: MYNEWT-185
> URL: https://issues.apache.org/jira/browse/MYNEWT-185
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Paul Dietrich
>        Assignee: Christopher Collins
> Fix For: v1_2_0_rel
>
>
> When building a BSP, you need a linker script.  If we move the startup code 
> the MCU, we need to clearly define what variables need to be created in the 
> linker script



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

BSP settings moved from bsp.h to syscfg.yml

[Christopher Collins]

Hello all,

Just a heads up- I will be merging a pull request which moves some BSP
settings from `bsp.h` to `syscfg.yml`
(https://github.com/apache/mynewt-core/pull/499).  If your BSP
uses non-default values for these settings, you'll need to add overrides
to your BSP's `syscfg.yml` file.

The new settings are below:

NFFS_NUM_AREAS:
description: >
Number of areas to allocate in the NFFS disk.  A smaller number is
used if the flash hardware cannot support this value.
value: 8

CONFIG_FCB_NUM_AREAS:
description: >
Number of areas to allocate in the config FCB.  A smaller number is
used if the flash hardware cannot support this value.
value: 8

BOOT_SERIAL_DETECT_PIN:
description: >
Start the serial boot loader if this pin is asserted at boot time.
value:
restrictions:
- '$notnull'

BOOT_SERIAL_DETECT_PIN_CFG:
description: >
GPIO configuration for the serial boot loader detect pin.
value: 'HAL_GPIO_PULL_UP'

BOOT_SERIAL_DETECT_PIN_VAL:
description: >
The value the detect pin must be set to for the serial boot loader
to start.
value: 0

BOOT_SERIAL_REPORT_PIN:
description: >
The GPIO to toggle while the serial boot loader is running.  Set to
-1 to disable reporting.
value: 'LED_BLINK_PIN'

BOOT_SERIAL_REPORT_FREQ:
description: >
The toggle rate, in Hz, of the serial boot loader report pin.
value: 4

Thanks,
Chris

Re: Regarding Arduino M0 zero serial communication implementation

[Christopher Collins]

On Fri, Aug 25, 2017 at 09:53:26AM -0700, marko kiiskila wrote:
> Also note that blinky does not have shell compiled in. It’s a very simple
> app which just blinks an LED. Try the app slinky instead; that one has shell
> enabled.

I believe Jyothi is following this tutorial which adds console and shell
to blinky:
https://mynewt.apache.org/latest/os/tutorials/blinky_console/.

Chris

Re: Regarding Arduino M0 zero serial communication implementation

[Christopher Collins]

Hi Jyothi,

On Fri, Aug 25, 2017 at 12:10:50PM +, jyoth...@aritron.com wrote:
[...]
> After we run the application, cant able to get the shell prompt as
> mentioned by you through minicom.  With Arduino IDE and the arduino
> EDBG boot loader we can able to communicate with the board.  But with
> the arduino_boot and arduino_blinky targets in mynewt cant able to
> communicate.

Did you set the BSP_ARDUINO_ZERO_PRO syscfg setting to 1, as indicated
in https://mynewt.apache.org/latest/os/tutorials/arduino_zero/?  That
step is easy to miss.

Chris

Re: adware solution for leopard

[Christopher Collins]

Hi Fred,

You are actually running Snow Leopard 10.6.8.

If you’re using Chrome, go to the Chrome web Store and download the extension 
Adblock Plus from adblockplus.org . It’s about the 
best ad blocker there is.

Christopher

> On 20 Aug 2017, at 4:55 am, Fred Thiel  wrote:
> 
> I am running Leopard 10.6.8 and am having annoying pop-up ads. Is there an 
> application for 10.6.8 running Google Chrome to fix this? 
> Thanks
> Fred

-- 
You received this message because you are a member of the iMac Group, a group 
for those using Apple iMacs and eMacs.
The list FAQ is at http://lowendmac.com/imac/list.shtml and our netiquette 
guide is at http://www.lowendmac.com/lists/netiquette.shtml
To post to this group, send email to imaclist@googlegroups.com
To leave this group, send email to imaclist+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/imaclist

--- 
You received this message because you are subscribed to the Google Groups "iMac 
Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to imaclist+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jira] [Updated] (MYNEWT-822) newtmgr - Native BLE - reconnect on immediate supervision timeout

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-822:
---
Description: 
(Pull request: https://github.com/apache/mynewt-newtmgr/pull/16)

The first data packet to be exchanged over a BLE connection has a high 
probability of triggering a disconnect.  The sending controller uses this 
packet to determine if the connection attempt was successful in the first 
place, and it does not get retried if it gets dropped.

In the case of newtmgr, the first data packet gets sent during ATT MTU 
negotiation.  The bhd (blehostd) transports recover from a disconnect during 
ATT MTU negotiation by reopening the session.

The ble transports (native BLE) do not recover from such a disconnect.  We 
should add the same recovery logic for the ble transports that has already been 
implemented for bhd.

  was:
The first data packet to be exchanged over a BLE connection has a high 
probability of triggering a disconnect.  The sending controller uses this 
packet to determine if the connection attempt was successful in the first 
place, and it does not get retried if it gets dropped.

In the case of newtmgr, the first data packet gets sent during ATT MTU 
negotiation.  The bhd (blehostd) transports recover from a disconnect during 
ATT MTU negotiation by reopening the session.

The ble transports (native BLE) do not recover from such a disconnect.  We 
should add the same recovery logic for the ble transports that has already been 
implemented for bhd.


> newtmgr - Native BLE - reconnect on immediate supervision timeout
> -
>
> Key: MYNEWT-822
> URL: https://issues.apache.org/jira/browse/MYNEWT-822
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: Newtmgr
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_2_0_rel
>
>
> (Pull request: https://github.com/apache/mynewt-newtmgr/pull/16)
> The first data packet to be exchanged over a BLE connection has a high 
> probability of triggering a disconnect.  The sending controller uses this 
> packet to determine if the connection attempt was successful in the first 
> place, and it does not get retried if it gets dropped.
> In the case of newtmgr, the first data packet gets sent during ATT MTU 
> negotiation.  The bhd (blehostd) transports recover from a disconnect during 
> ATT MTU negotiation by reopening the session.
> The ble transports (native BLE) do not recover from such a disconnect.  We 
> should add the same recovery logic for the ble transports that has already 
> been implemented for bhd.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYNEWT-821) newtmgr - Try harder to recover from disconnect during image upload

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-821:
--

 Summary: newtmgr - Try harder to recover from disconnect during 
image upload
 Key: MYNEWT-821
 URL: https://issues.apache.org/jira/browse/MYNEWT-821
 Project: Mynewt
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: Newtmgr
Reporter: Christopher Collins
Assignee: Christopher Collins


An image upgrade consists of two phases:
1. Erase slot
2. Upload image

On nRF boards, both phases cause the processor to stall while flash is being 
accessed.  Such stalls can cause any established BLE connections to terminate 
due to "supervision timeout."

Currently, the newtmgr tool automatically recovers from a disconnect during the 
first phase (erase).  However, it does not recover from such a disconnect 
during the upload phase.

Newtmgr should be improved to use the same reconnect logic during the second 
phase that it already uses during the first phase.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Mynewt 1.1.0-rc1

[Christopher Collins]

On Wed, Jul 26, 2017 at 02:03:43AM +0200, Szymon Janc wrote:
> Hello all,
> 
> I am pleased to be calling this vote for the source release of
> Apache Mynewt 1.1.0.
> The vote is open for at least 72 hours and passes if a majority of at
> least three +1 PPMC 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)

Chris

Re: Changing eventq for a package

[Christopher Collins]

On Tue, Jul 25, 2017 at 03:20:46PM -0700, Vipul Rahane wrote:
> Hello,
> 
> While working on the sensors framework, I found a limitation which
> seems to be system wide and should be discussed before coming to a
> consensus.
> 
> By default all packages run on the default eventq. Generally,
> everybody uses the default eventq since that’s what initialization
> functions use which get called from sysinit via the package
> initialization functions. We have not seen many use cases where the
> app would like to change the eventq. If a developer would like to
> change the eventq he/she would have to modify the initialization
> function to do this. As we have it today, we allow setting eventqs in
> the app by exposing an API to set eventqs for a package. It is kind of
> bug prone as any timers initialized earlier would still keep using the
> old eventq.
> 
> I can think of three possible solutions to this problem:
> 
> 1. Reinitializing timers and resetting them in the evq_set()
> functions. 
> This solution however seems a bit counter intuitive as setting the
> eventq also resets the timers. 
> 
> 2. Allow reinitialization of modules so that initialization Vs
> re-initialization can be differentiated. This would make resetting
> timers explicit. 
> 
> Initialization generally does the following:
> - Initialize timers, callouts by setting the eventq
> - Create and Initialize mutexes 
> - Initialize module specific parameters(e.g.: Module Eventq, Base
> timestamps, etc)
> 
> Re-initialization would do the following:
> - Set module eventq
> - Re-initialize timers, callouts by stopping the timers, callouts and
> resetting them. 
> 
> IMO, 2. is the best solution.

I wouldn't be surprised if a lot more packages have this same problem.
Option 2 sounds good to me.  I presume each package's set-eventq
function would be removed from its public interface.  When the
application wants to move a package to a different task, it would call
the reinitialize function instead?

Chris

Re: Question regarding exchanging long characteristic values over BLE

[Christopher Collins]

On Tue, Jul 25, 2017 at 10:46:32AM -0700, Pritish Gandhi wrote:
[...]
> Ah I see! I was assuming a call to access_cb() on a read to completely read
> the value of a characteristic so I was using that to trigger an event which
> would change the value of that characteristic again. I guess that
> assumption is incorrect and I should probably read the MTU of the channel
> and know for sure how many reads would be required before the entire value
> is read.

I do see how it would be useful to know when a characteristic has been
fully read.  I don't think there is any good way to know whether a read
is partial or full in the current stack.

Originally, the stack would handle partial reads by asking the
application for the specific portion of the characteristic being read.
If this were still the case, the application would know when the final
portion is being requested.  However, it was deemed that this interface
made the application deal with too many details, so we changed it to how
it is today.

It would be a fairly minor change to have the stack indicate:
* the offset being read, and  
* the maximum amount of data that the response might include.

The application could ignore this information except in cases like yours
where it needs to know when a characteristic has been fully read.

> 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.

> I guess I should handle the case that I cannot negotiate a high enough MTU
> with the peer even though there's a slim chance.

If you have no control over which devices will connect to your
application, then I'm afraid you're right.

Chris

Re: Question regarding exchanging long characteristic values over BLE

[Christopher Collins]

Hi Pritish,

On Mon, Jul 24, 2017 at 04:25:30PM -0700, Pritish Gandhi wrote:
> Hi All,
> So I'm trying to understand who is responsible for handling chunking the
> characteristic value in case the MTU of the connection is smaller than the
> characters ic value size.
> 
> So for example, if I have a characteristic value of size 100B. When an iOS
> App connects to my device and reads the characteristic value it gets the
> entire value in a single read.
> It seems like this may be the case because iOS automatically triggers an
> MTU exchange.
> 
> However, when the Android App tries to read the characteristic value,
> multiple reads are triggered (5 reads for 20B each). This causes the GATT
> server access_cb() handler to be called 5 times for the "same"
> characteristic read.
> 
> My questions are:
> a) Isn't the BLE stack supposed to handle chunking the characteristic value
> of 100B to 5 x 20B reads and supplying them to the Android App?
> 
> b) Does the Application have to save state for each read? check what the
> session MTU is and expect those many callbacks to occur before knowing that
> the entire characteristic value has been read?
> 
> c) Is an MTU exchange required for characteristic values > 20B to work
> correctly?
> 
> d) Is it the responsibility of the peripheral or client to initiate the MTU
> exchange?

The Read Long Characteristic Values GATT procedure consists of a
sequence of Read Blob Request ATT commands.  Each of these commands
specifies the offset to begin the read from.

The NimBLE host does not cache any attribute data after receiving a Read
Blob Request.  Instead, the stack asks the application for the full
attribute value for each read request that it receives.  The stack
extracts the requested portion of data from the full value and includes
it in its response to the peer.

So, your characteristic access callback will get called several times
when a peer performs a long read.  The correct behavior is for the
application to retrieve the full characteristic value each time.

I think this answers the above four questions, but please let me know if
something is missing or unclear.

> e) Is is possible for certain BLE stacks/phones to NOT support increasing
> the MTU?

Yes, it is possible, though unlikely.  The spec only requires devices to
support the default ATT MTU: 23.

Chris

Re: console_queue_char() in interrupt context

[Christopher Collins]

On Wed, Jul 19, 2017 at 09:00:16AM -0700, will sanfilippo wrote:
> I dont know enough about the console code to make an intelligent suggestion. 
> There is no task associated with the console, right? If not, and the purpose 
> of this is to wait some time maybe the only thing to do is set a timer to 
> wake up and deal with this? Not sure that this would work though… And I dont 
> think I have any other ideas :-)

I think this is caused by a recent change.  It appears the console code
writes back to the uart in the middle of a read.  Specifically:


int
console_handle_char(uint8_t byte)
{
/* ... */

/* Handle special control characters */
if (!isprint(byte)) {
handle_ansi(byte, input->line);
switch (byte) {

/* ... */

default:
insert_char(>line[cur], byte, end);
/* Falls through. */
case '\r':
/* Falls through. */
case '\n':
if (byte == '\n' && prev_endl == '\r') {
/* handle double end line chars */
prev_endl = byte;
break;
}
prev_endl = byte;
input->line[cur + end] = '\0';
console_out('\r');  // <--- ***
console_out('\n');  // <--- ***
cur = 0;
end = 0;
os_eventq_put(lines_queue, ev);

It seems the console is normalizing line endings.  Regardless of what
type of newline is read, it always outputs "\r\n".

I don't know what the solution is, but Sterling is correct that the ISR
shouldn't be performing a UART write.

Chris

> 
> 
> > On Jul 18, 2017, at 10:34 PM, Sterling Hughes 
> >  wrote:
> > 
> > Hi,
> > 
> > As I was supporting the Ambiq series of processor, I ran into what I think 
> > is a bug in console_queue_char().
> > 
> > Specifically,
> > 
> > - console_rx_char() is registered as a uart device callback, which operates 
> > in interrupt context
> > 
> > - console_handle_char() is called by console_rx_char() in uart_console.c.
> > 
> > - console_handle_char() calls console_out()
> > 
> > - console_out() calls write_char_cb() which is console_queue_char()
> > 
> > - console_queue_char() calls os_time_delay()
> > 
> > So, in the cases where console_queue_char() is called in interrupt context, 
> > and os_time_delay() is hit, the operating system crashes.  os_time_delay() 
> > is not meant to be called from interrupt context.
> > 
> > I ran into this due to some errors managing the RX interrupt (more than (n) 
> > bytes in a single RX interrupt), but I’m pretty sure the behavior should 
> > not be this way/it will happen rarely.  What do folks think in terms of 
> > potential options for changing it?
> > 
> > Sterling
> > 
> > 
> > 
> 

Re: Newtmgr moved to new repo

[Christopher Collins]

Hi Paul,

On Mon, Jul 10, 2017 at 04:13:30PM -0400, Paul LaCrosse wrote:
> Pauls-MacBook-Pro-2:testgoget paul$  go get mynewt.apache.org/newtmgr/...
> 
> # cd /Users/paul/dev/go/src/mynewt.apache.org/newt; git pull --ff-only
> 
> fatal: repository '
> https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/' not
> found
> 
> package mynewt.apache.org/newtmgr/nmxact/example/ble_loop
> 
> imports mynewt.apache.org/newt/util/unixchild: exit status 1
> 
> Download of latest newtmgr, produces error.

It appears your version of the newt repo was cloned from the old apache
git server (before Mynewt moved to github).  Using "go get" with the
mynewt.apache.org vanity domain helps to avoid problems like this.  To
solve this, I would either:

1. Change the newt repo remote to the github URL:

cd $GOPATH/src/mynewt.apache.org/newt &&
git remote set-url origin 
https://github.com/apache/incubator-mynewt-newt.git

Or,

2. Completely remove $GOPATH/src/mynewt.apache.org and reinstall it with
`go get mynewt.apache.org/newt/...`

Thanks,
Chris

Newtmgr moved to new repo

[Christopher Collins]

Hello all,

The newtmgr tool location has changed:

From: https://github.com/apache/mynewt-newt/tree/master/newtmgr
  To: https://github.com/apache/mynewt-newtmgr/tree/master/newtmgr

To download the latest newtmgr, use the following command:

go get mynewt.apache.org/newtmgr/...

The plan is to remove the "old" newtmgr from the newt repo when Mynewt
1.1 is released.

The "new" newtmgr has improved BLE support.  BLE should now work more
reliably on Linux and macOS.  The particulars are documented here:
http://mynewt.apache.org/latest/newtmgr/command_list/newtmgr_conn/

My preferred way to use BLE is to create a "ble" connection profile with
an empty connstring:

newtmgr conn add ble type=ble connstring=' '

Then, specify the target device name on the command line each time you
send a command:

newtmgr -c ble --name nimble-bleprph echo hello

Rationale:
The reason for the move is to simplify downloading and
building of newt and newtmgr.  The "go get" command works better with
the "mynewt.apache.org" vanity domain when there is one application per
repo.  Since the vanity domain requires the use of the "..." syntax in
the `go get` command, the entire repo gets downloaded, including
applications that weren't requested.

Thanks,
Chris

[jira] [Resolved] (MYNEWT-411) newtmgr needs to be its own git repo

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-411.

Resolution: Fixed

> newtmgr needs to be its own git repo
> 
>
> Key: MYNEWT-411
> URL: https://issues.apache.org/jira/browse/MYNEWT-411
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: v1_0_0_beta1
>Reporter: Sterling Hughes
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> repo created already in ASF.  As a part of the unification efforts, we should 
> breakout newtmgr/connectivity tools from newt build tool.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Why not use -std=gnu99?

[Christopher Collins]

On Thu, Jul 06, 2017 at 06:41:12PM +0100, Jonathan Pallant wrote:
> Hi, I just wanted to jump in here and suggest that -std=c11 is a better 
> choice than -std=gnuXX. If you allow GNU specific extensions then you 
> might have issues using other compilers - certainly I would be surprised 
> to see the project to rule out clang support in the future. I would 
> suggest c11 over c99 as it offers things like atomics which might be 
> useful.

I was under the impression that Mynewt already uses some gnu extensions,
though I could be wrong about that.  Regarding clang- it also supports
the gnuXX "standards".  It would be nice to support other compilers as
well, but I think that would be quite an uphill battle, and these days,
I wonder how many people would want to use a toolchain other than gcc or
clang for Mynewt.

Chris

[jira] [Updated] (MYNEWT-76) Add newt command to show a summary of licenses used in the stack

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-76:
--
Fix Version/s: (was: v1_1_0_rel)

> Add newt command to show a summary of licenses used in the stack
> 
>
> Key: MYNEWT-76
> URL: https://issues.apache.org/jira/browse/MYNEWT-76
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Reporter: Aditi Hilbert
>    Assignee: Christopher Collins
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYNEWT-268) BLE - enable factory reset

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16075574#comment-16075574
 ] 

Christopher Collins commented on MYNEWT-268:


Pull request: https://github.com/apache/mynewt-core/pull/380

> BLE - enable factory reset
> --
>
> Key: MYNEWT-268
> URL: https://issues.apache.org/jira/browse/MYNEWT-268
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>Reporter: Aditi Hilbert
>        Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The settings need to be stored in flash (sysvars).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: ReadDesc: No matching branch for apache-mynewt-core repo

[Christopher Collins]

I don't think this problem will come up anymore with any version of
newt.  Older versions of newt will download the develop branch of
blinky, which correctly references the new URLs now.

Going forward, new versipns of newt will retrieve the blinky tag which
corresponds to the version of newt being used.  Assuming we create the
1.1.0 tag of blinky off of master, this will also reference the correct
URLs.

Chris




On Tue, Jul 04, 2017 at 10:26:13AM -0700, Sheela Kiiskila wrote:
> Would this work for someone who is trying to download say released 
> version1.0?  Newt1.0 pulls from blinky1.0 so who ever is downloading 
> version1.0 might still have to manually change the project.yml and remove 
> “incubator”?
> 
> 
> 
> > On Jul 4, 2017, at 8:55 AM, Christopher Collins <ch...@runtime.io> wrote:
> > 
> > Li-Chun, could you try again?  Delete your project directory, then run
> > "newt new" and "newt install".  I believe the problem should be fixed
> > now.
> > 
> > Some more details: this is a confusing problem.  The "incubator-..."
> > github URLs are supposed to redirect to the new ones, and the
> > redirection seems to work for most people.  For some reason, the
> > redirection fails for some users who get this error instead.
> > 
> > I tried to fix this last week by removing "incubator-" from blinky's
> > project.yml file, but I only made the change to master.  It appears
> > "newt new" retrieves the develop branch of blinky, rather than master.
> > This is not quite right; it must have slipped through when we
> > transitioned to the current branching scheme.
> > 
> > I just fixed the project.yml in develop.  We should fix newt so that it
> > downloads from master instead of develop; I'll create a jira ticket.
> > 
> > Chris
> > 
> > 
> > On Tue, Jul 04, 2017 at 08:31:57AM -0700, Sterling Hughes wrote:
> >> Hi,
> >> 
> >> This is an unfortunate side effect of our exit from incubator, which 
> >> renamed the git repositories.
> >> 
> >> If you go to project.yml and replace “incubator-mynewt-core” with 
> >> “mynewt-core” under the repo field of “apache-mynewt-core” - 
> >> everything should work.
> >> 
> >> Sterling
> >> 
> >> On 4 Jul 2017, at 7:53, Li-Chun Ko wrote:
> >> 
> >>> Hi all,
> >>> 
> >>> When I was following the instructions of the "Create your first 
> >>> project"
> >>> tutorial today, I got "ReadDesc: No matching branch for 
> >>> apache-mynewt-core
> >>> repo" right after I enter "newt install" (no problem  on the "newt new
> >>> myproj" part).
> >>> 
> >>> Is this a problem of the repo or my local computer? The example used 
> >>> to
> >>> work before I upgrade to go 1.7. I tried vers: 1-latest and vers: 
> >>> 0-dev and
> >>> neither worked.
> >>> 
> >>> Br,
> >>> Lichun
> 

[jira] [Commented] (MYNEWT-757) Inconsistent tags among newt, blinky, and core

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073872#comment-16073872
 ] 

Christopher Collins commented on MYNEWT-757:


*newt:*
Change newtutil.go from:
{noformat}
var NewtBlinkyTag string = "develop"
{noformat}

To:
{noformat}
var NewtBlinkyTag string = "mynewt_1_1_0_tag"
{noformat}

*blinky:*
Change project.yml from:
{noformat}
repository.apache-mynewt-core:
type: github
vers: 1-latest
user: apache
repo: mynewt-core
{noformat}

To:
{noformat}
repository.apache-mynewt-core:
type: github
vers: 1.1.0
user: apache
repo: mynewt-core
{noformat}

Of course, this should only be done after the 1.1.0 tag is created in all 
repos, and apache-mynewt-core's repository.yml file is ammended to contain a 
"1.1.0" reference to the proper tag.

> Inconsistent tags among newt, blinky, and core
> --
>
> Key: MYNEWT-757
> URL: https://issues.apache.org/jira/browse/MYNEWT-757
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Reporter: Christopher Collins
>Assignee: Szymon Janc
> Fix For: v1_1_0_rel
>
>
> * "newt install" should download the corresponding version of blinky.
> * Blinky's project.yml should specify the corresponding version of core.
> Currently, the versions don't match up properly:
> * In master: newt specifies blinky's develop tag
> * In develop: blinky's project.yml specifies core's 1-latest tag.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-749) BLE Host - Crash during key persistence if key-dist settings are 0

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-749:
---
Description: 
(Pull request: https://github.com/apache/mynewt-core/pull/370)

If BLE_SM_BONDING is enabled, but one of the the following settings is 0:
* BLE_SM_OUR_KEY_DIST
* BLE_SM_THEIR_KEY_DIST

then Mynewt crashes when pairing completes.  Here is an example stack trace:

{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0, 
e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0  __assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0, 
e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1  0x000181f8 in ble_store_persist_sec (obj_type=, 
value_sec=) at net/nimble/host/src/ble_store.c:92
#2  0x000177ca in ble_sm_persist_keys (proc=0x181f9 <ble_store_persist_sec+20>) 
at net/nimble/host/src/ble_sm.c:565
#3  ble_sm_process_result (conn_handle=conn_handle@entry=1, 
res=res@entry=0x2000165c <os_main_stack+3968>) at 
net/nimble/host/src/ble_sm.c:860
#4  0x0001792c in ble_sm_enc_event_rx (conn_handle=, 
evt_status=, encrypted=1) at net/nimble/host/src/ble_sm.c:1042
#5  0x00017942 in ble_sm_enc_change_rx (evt=evt@entry=0x20001698 
<os_main_stack+4028>) at net/nimble/host/src/ble_sm.c:1051
#6  0x000153be in ble_hs_hci_evt_encrypt_change (event_code=, 
data=0x20004c20 "\b\004", len=) at 
net/nimble/host/src/ble_hs_hci_evt.c:163
#7  0x00015438 in ble_hs_hci_evt_process (data=0x20004c20 "\b\004") at 
net/nimble/host/src/ble_hs_hci_evt.c:593
#8  0x9016 in os_eventq_run (evq=) at 
kernel/os/src/os_eventq.c:172
#9  0x879e in main () at apps/bleprph/src/main.c:301
{noformat}

  was:
# (Pull request: 

If BLE_SM_BONDING is enabled, but one of the the following settings is 0:
* BLE_SM_OUR_KEY_DIST
* BLE_SM_THEIR_KEY_DIST

then Mynewt crashes when pairing completes.  Here is an example stack trace:

{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0, 
e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0  __assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0, 
e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1  0x000181f8 in ble_store_persist_sec (obj_type=, 
value_sec=) at net/nimble/host/src/ble_store.c:92
#2  0x000177ca in ble_sm_persist_keys (proc=0x181f9 <ble_store_persist_sec+20>) 
at net/nimble/host/src/ble_sm.c:565
#3  ble_sm_process_result (conn_handle=conn_handle@entry=1, 
res=res@entry=0x2000165c <os_main_stack+3968>) at 
net/nimble/host/src/ble_sm.c:860
#4  0x0001792c in ble_sm_enc_event_rx (conn_handle=, 
evt_status=, encrypted=1) at net/nimble/host/src/ble_sm.c:1042
#5  0x00017942 in ble_sm_enc_change_rx (evt=evt@entry=0x20001698 
<os_main_stack+4028>) at net/nimble/host/src/ble_sm.c:1051
#6  0x000153be in ble_hs_hci_evt_encrypt_change (event_code=, 
data=0x20004c20 "\b\004", len=) at 
net/nimble/host/src/ble_hs_hci_evt.c:163
#7  0x00015438 in ble_hs_hci_evt_process (data=0x20004c20 "\b\004") at 
net/nimble/host/src/ble_hs_hci_evt.c:593
#8  0x9016 in os_eventq_run (evq=) at 
kernel/os/src/os_eventq.c:172
#9  0x879e in main () at apps/bleprph/src/main.c:301
{noformat}


> BLE Host - Crash during key persistence if key-dist settings are 0
> --
>
> Key: MYNEWT-749
> URL: https://issues.apache.org/jira/browse/MYNEWT-749
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/mynewt-core/pull/370)
> If BLE_SM_BONDING is enabled, but one of the the following settings is 0:
> * BLE_SM_OUR_KEY_DIST
> * BLE_SM_THEIR_KEY_DIST
> then Mynewt crashes when pairing completes.  Here is an example stack trace:
> {noformat}
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0, 
> e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
> 137asm("bkpt");
> (gdb) whe
> #0  __assert_func (file=file@entry=0x0, line=line@entry=0, 
> func=func@entry=0x0, e=e@entry=0x0) at 
> kernel/os/src/arch/cortex_m4/os_fault.c:137
> #1  0x000181f8 in ble_store_persist_sec (obj_type=, 
> value_sec=) at net/nimble/host/src/ble_store.c:92
> #2  0x000

[jira] [Assigned] (MYNEWT-411) newtmgr needs to be its own git repo

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reassigned MYNEWT-411:
--

Assignee: Christopher Collins  (was: Marko Kiiskila)

> newtmgr needs to be its own git repo
> 
>
> Key: MYNEWT-411
> URL: https://issues.apache.org/jira/browse/MYNEWT-411
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: v1_0_0_beta1
>Reporter: Sterling Hughes
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> repo created already in ASF.  As a part of the unification efforts, we should 
> breakout newtmgr/connectivity tools from newt build tool.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-287) Host Flow Control

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-287:
---
Fix Version/s: (was: v1_1_0_rel)
   v1_2_0_rel

> Host Flow Control
> -
>
> Key: MYNEWT-287
> URL: https://issues.apache.org/jira/browse/MYNEWT-287
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
> Environment: Using nimble from an external host stack
>Reporter: Johan Hedberg
>    Assignee: Christopher Collins
> Fix For: v1_2_0_rel
>
>
> If the Nimble controller part is connected to an external host stack the host 
> may need to control the flow of ACL packets from the controller to the host. 
> This is particularly important for resource-constrained hosts that have a 
> limited amount of RX ACL data buffers.
> The Bluetooth core specification provides a standard feature to accomplish 
> this called Host Flow Control. (Vol 2, Part E, Section 4.2). To implement 
> this the controller needs to support the "Set Controller To Host Flow 
> Control", "Host Buffer Size" and "Host Number Of Completed Packets" HCI 
> commands.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYNEWT-791) syscfg - Only apply conditional overrides if condition is true

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-791.

Resolution: Fixed

> syscfg - Only apply conditional overrides if condition is true
> --
>
> Key: MYNEWT-791
> URL: https://issues.apache.org/jira/browse/MYNEWT-791
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-newt/pull/73)
> This commit fixes a bug involving conditional overrides of syscfg values. In 
> the following syscfg listing:
> {noformat}
> syscfg.vals.MY_SETTING:
> LOG_LEVEL: 255
> {noformat}
> LOG_LEVEL should only get set to 255 if MY_SETTING is defined with a true 
> value (nonzero and non-empty-string). However, the actual behavior is that 
> LOG_LEVEL gets overridden if MY_SETTING is defined at all, regardless of its 
> value.
> The fix is to only apply the override if the condition is true.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-790) syscfg - Allow a package to override its own setting

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-790:
---
Description: 
(Pull request: https://github.com/apache/incubator-mynewt-newt/pull/74)

PKG-A can only override a setting defined by PKG-B if PKG-A has a greater 
priority than PKG-B. If PKG-A's priority is less than or equal to PKG-B's, the 
override attempt is rejected and reported as a priority violation.

This commit relaxes that rule slightly: a package can override settings that it 
itself defines.

This behavior is needed for making a setting's default value conditional on 
another setting. For example:

{noformat}
syscfg.defs:
TIMER_0:
description: 'NRF52 Timer 0'
value:  1
TIMER_3:
description: 'NRF52 Timer 3'
value:  0

# Use timer 3 instead of timer 0 if target wants to use the low
# power clock.
syscfg.vals.BLE_LP_CLOCK:
TIMER_0: 0
TIMER_3: 1
{noformat}

  was:
(Pull request: https://github.com/apache/incubator-mynewt-newt/pull/74)

PKG-A can only override a setting defined by PKG-B if PKG-A has a greater 
priority than PKG-B. If PKG-A's priority is less than or equal to PKG-B's, the 
override attempt is rejected and reported as a priority violation.

This commit relaxes that rule slightly: a package can override settings that it 
itself defines.

This behavior is needed for making a setting's default value conditional on 
another setting. For example:

{noformat}
syscfg.defs:
TIMER_0:
description: 'NRF52 Timer 0'
value:  1
TIMER_3:
description: 'NRF52 Timer 3'
value:  0

# Use timer 3 instead of timer 0 if target wants to use the low
# power clock.
syscfg.vals.BLE_LP_CLOCK:
TIMER_0: 0
TIMER_1: 1
{noformat}


> syscfg - Allow a package to override its own setting 
> -
>
> Key: MYNEWT-790
> URL: https://issues.apache.org/jira/browse/MYNEWT-790
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
>  Labels: doc
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-newt/pull/74)
> PKG-A can only override a setting defined by PKG-B if PKG-A has a greater 
> priority than PKG-B. If PKG-A's priority is less than or equal to PKG-B's, 
> the override attempt is rejected and reported as a priority violation.
> This commit relaxes that rule slightly: a package can override settings that 
> it itself defines.
> This behavior is needed for making a setting's default value conditional on 
> another setting. For example:
> {noformat}
> syscfg.defs:
> TIMER_0:
> description: 'NRF52 Timer 0'
> value:  1
> TIMER_3:
> description: 'NRF52 Timer 3'
> value:  0
> # Use timer 3 instead of timer 0 if target wants to use the low
> # power clock.
> syscfg.vals.BLE_LP_CLOCK:
> TIMER_0: 0
> TIMER_3: 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYNEWT-790) syscfg - Allow a package to override its own setting

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-790:
--

 Summary: syscfg - Allow a package to override its own setting 
 Key: MYNEWT-790
 URL: https://issues.apache.org/jira/browse/MYNEWT-790
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Newt
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


(Pull request: https://github.com/apache/incubator-mynewt-newt/pull/74)

PKG-A can only override a setting defined by PKG-B if PKG-A has a greater 
priority than PKG-B. If PKG-A's priority is less than or equal to PKG-B's, the 
override attempt is rejected and reported as a priority violation.

This commit relaxes that rule slightly: a package can override settings that it 
itself defines.

This behavior is needed for making a setting's default value conditional on 
another setting. For example:

{noformat}
syscfg.defs:
TIMER_0:
description: 'NRF52 Timer 0'
value:  1
TIMER_3:
description: 'NRF52 Timer 3'
value:  0

# Use timer 3 instead of timer 0 if target wants to use the low
# power clock.
syscfg.vals.BLE_LP_CLOCK:
TIMER_0: 0
TIMER_1: 1
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYNEWT-756) mpstats (on nrf51) hangs indefinately

[Christopher Collins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYNEWT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16057958#comment-16057958
 ] 

Christopher Collins commented on MYNEWT-756:


I believe it is failing because your newtmgr client is using a lower BLE MTU.  
Incoming data gets distributed among mbufs according to how it was fragmented 
by the sender.  On my macbook, Mac OS uses an MTU of 104, while the "new" 
newtmgr uses something between 256 and 517, depending on how both peers are 
configured.

I was able to get mpstats working on a 16kB nRF51dk using an MTU of 104 with 
the following settings:

{noformat}
MSYS_1_BLOCK_COUNT: 22
MSYS_1_BLOCK_SIZE: 110
{noformat}

Could you give that a try and let me know if it works?

> mpstats (on nrf51) hangs indefinately
> -
>
> Key: MYNEWT-756
> URL: https://issues.apache.org/jira/browse/MYNEWT-756
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>    Reporter: Jacob
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> I believe core is failing before sending the last packet, as neither newtmgr 
> or node-newtmgr receives that packet.
> Jacobs-MacBook-Air:newtmgr jacobrosenthal$ GODEBUG=cgocheck=0 newtmgr mpstats 
> -cnimble_bleprph -t -ldebug
> 2017/05/11 22:28:46 [DEBUG] BLE Connection devaddr:[]
> 2017/05/11 22:28:46 [DEBUG] State:PoweredOn
> 2017/05/11 22:28:46 [DEBUG] scanning...
> 2017/05/11 22:28:46 [DEBUG] Peripheral Discovered: , Address:[0 0 0 0 0 0] 
> Address Type:0
> 2017/05/11 22:28:47 Unhandled event: xpc.Dict{"kCBMsgId":53, 
> "kCBMsgArgs":xpc.Dict{"kCBMsgArgDeviceUUID":xpc.UUID{0x2f, 0xd, 0xcb, 0x60, 
> 0xf, 0x3e, 0x47, 0x52, 0xb7, 0x74, 0x13, 0x29, 0x3a, 0x3, 0xd4, 0xd0}, 
> "kCBMsgArgATTMTU":104}}
> 2017/05/11 22:28:47 [DEBUG] Peripheral Connected
> 2017/05/11 22:28:47 [DEBUG] Newtmgr Service Found 
> 2017/05/11 22:28:47 [DEBUG] Newtmgr Characteristic Found
> 2017/05/11 22:28:47 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:0 
> Group:0 Seq:0 Id:3 Data:[]}
> 2017/05/11 22:28:47 [DEBUG] Serializing request &{Op:0 Flags:0 Len:0 Group:0 
> Seq:0 Id:3 Data:[]} into buffer [0 0 0 0 0 0 0 3]
> 2017/05/11 22:28:47 [DEBUG] Tx packet dump:
>   00 00 00 00 00 00 00 03   ||
> 2017/05/11 22:28:47 [DEBUG] Write BLE Packet:buf:: len::8
> 2017/05/11 22:28:47 [DEBUG] Read BLE 
> Packet:buf::l?brcfmpools?fmsys_1?fblksiz$enblks
>   
>   enfreecmin?wble_hci_ram_evt_hi_pool?fblksizHenblkse len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
>   01 00 02 6c 00 00 00 03  bf 62 72 63 00 66 6d 70  |...l.brc.fmp|
> 0010  6f 6f 6c 73 bf 66 6d 73  79 73 5f 31 bf 66 62 6c  |ools.fmsys_1.fbl|
> 0020  6b 73 69 7a 19 01 24 65  6e 62 6c 6b 73 0c 65 6e  |ksiz..$enblks.en|
> 0030  66 72 65 65 09 63 6d 69  6e 00 ff 77 62 6c 65 5f  |free.cmin..wble_|
> 0040  68 63 69 5f 72 61 6d 5f  65 76 74 5f 68 69 5f 70  |hci_ram_evt_hi_p|
> 0050  6f 6f 6c bf 66 62 6c 6b  73 69 7a 18 48 65 6e 62  |ool.fblksiz.Henb|
> 0060  6c 6b 73 02 65|lks.e|
> 2017/05/11 22:28:47 [DEBUG] Deserialized response &{Op:1 Flags:0 Len:620 
> Group:0 Seq:0 Id:3 Data:[191 98 114 99 0 102 109 112 111 111 108 115 191 102 
> 109 115 121 115 95 49 191 102 98 108 107 115 105 122 25 1 36 101 110 98 108 
> 107 115 12 101 110 102 114 101 101 9 99 109 105 110 0 255 119 98 108 101 95 
> 104 99 105 95 114 97 109 95 101 118 116 95 104 105 95 112 111 111 108 191 102 
> 98 108 107 115 105 122 24 72 101 110 98 108 107 115 2 101]}
> 2017/05/11 22:28:47 [DEBUG] Read BLE 
> Packet:buf::nfreecmin?wble_hci_ram_evt_lo_pool?fblksizHenblkenfrecmi?rble_hs_hci_ev_pool?fblksizenblks
>  len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
>   6e 66 72 65 65 02 63 6d  69 6e 00 ff 77 62 6c 65  |nfree.cmin..wble|
> 0010  5f 68 63 69 5f 72 61 6d  5f 65 76 74 5f 6c 6f 5f  |_hci_ram_evt_lo_|
> 0020  70 6f 6f 6c bf 66 62 6c  6b 73 69 7a 18 48 65 6e  |pool.fblksiz.Hen|
> 0030  62 6c 6b 73 08 65 6e 66  72 65 65 08 63 6d 69 6e  |blks.enfree.cmin|
> 0040  08 ff 72 62 6c 65 5f 68  73 5f 68 63 69 5f 65 76  |..rble_hs_hci_ev|
> 0050  5f 70 6f 6f 6c bf 66 62  6c 6b 73 69 7a 10 65 6e  |_pool.fblksiz.en|
> 0060  62 6c 6b 73 0a|blks.|
> 2017/05/11 22:28:47 [DEBUG] Read BLE Packet:buf::enfree
> cmin  
> ?pble_hs_conn_pool?fblksizTenblksenfreecmin?sble_l2cap_chan_

[jira] [Resolved] (MYNEWT-787) serial boot loader - newtmgr buffer overruns

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-787.

Resolution: Fixed

> serial boot loader - newtmgr buffer overruns
> 
>
> Key: MYNEWT-787
> URL: https://issues.apache.org/jira/browse/MYNEWT-787
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-core/pull/340)
> The serial boot loader fails to process some newtmgr commands:
> 1. The image list response is too large for the outgoing buffer.
> 2. The "new" newtmgr sends large image chunks in its image upload requests.  
> These chunks are too large for the serial boot loader's input buffer.
> The fixes are as follows:
> 1. Increase the outgoing buffer size from 48 to 80.
> 2. Increase the incoming buffer size from 128 to 512.
> 3. Return an error rather than overrun the output buffer.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-787) serial boot loader - newtmgr buffer overruns

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-787:
---
Description: 
(Pull request: https://github.com/apache/incubator-mynewt-core/pull/340)

The serial boot loader fails to process some newtmgr commands:

1. The image list response is too large for the outgoing buffer.
2. The "new" newtmgr sends large image chunks in its image upload requests.  
These chunks are too large for the serial boot loader's input buffer.

The fixes are as follows:
1. Increase the outgoing buffer size from 48 to 80.
2. Increase the incoming buffer size from 128 to 512.
3. Return an error rather than overrun the output buffer.

  was:
(Pull request: https://github.com/apache/incubator-mynewt-core/pull/340)

The serial boot loader fails to process some newtmgr commands:

1. The image list response is too large for the outgoing buffer.
2. The "new" newtmgr sends large image chunks in its image upload requests.  
These chunks are too large for the serial boot loader's input buffer.

The fixes are as follows:
1. Increase the outgoing buffer size from 48 to 128.
2. Increase the incoming buffer size from 128 to 512.
3. Return an error rather than overrun the output buffer.


> serial boot loader - newtmgr buffer overruns
> 
>
> Key: MYNEWT-787
> URL: https://issues.apache.org/jira/browse/MYNEWT-787
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-core/pull/340)
> The serial boot loader fails to process some newtmgr commands:
> 1. The image list response is too large for the outgoing buffer.
> 2. The "new" newtmgr sends large image chunks in its image upload requests.  
> These chunks are too large for the serial boot loader's input buffer.
> The fixes are as follows:
> 1. Increase the outgoing buffer size from 48 to 80.
> 2. Increase the incoming buffer size from 128 to 512.
> 3. Return an error rather than overrun the output buffer.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-787) serial boot loader - newtmgr buffer overruns

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-787:
---
Description: 
(Pull request: https://github.com/apache/incubator-mynewt-core/pull/340)

The serial boot loader fails to process some newtmgr commands:

1. The image list response is too large for the outgoing buffer.
2. The "new" newtmgr sends large image chunks in its image upload requests.  
These chunks are too large for the serial boot loader's input buffer.

The fixes are as follows:
1. Increase the outgoing buffer size from 48 to 128.
2. Increase the incoming buffer size from 128 to 512.
3. Return an error rather than overrun the output buffer.

  was:
The serial boot loader fails to process some newtmgr commands:

1. The image list response is too large for the outgoing buffer.
2. The "new" newtmgr sends large image chunks in its image upload requests.  
These chunks are too large for the serial boot loader's input buffer.

The fixes are as follows:
1. Increase the outgoing buffer size from 48 to 128.
2. Increase the incoming buffer size from 128 to 512.
3. Return an error rather than overrun the output buffer.


> serial boot loader - newtmgr buffer overruns
> 
>
> Key: MYNEWT-787
> URL: https://issues.apache.org/jira/browse/MYNEWT-787
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-core/pull/340)
> The serial boot loader fails to process some newtmgr commands:
> 1. The image list response is too large for the outgoing buffer.
> 2. The "new" newtmgr sends large image chunks in its image upload requests.  
> These chunks are too large for the serial boot loader's input buffer.
> The fixes are as follows:
> 1. Increase the outgoing buffer size from 48 to 128.
> 2. Increase the incoming buffer size from 128 to 512.
> 3. Return an error rather than overrun the output buffer.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYNEWT-787) serial boot loader - newtmgr buffer overruns

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-787:
--

 Summary: serial boot loader - newtmgr buffer overruns
 Key: MYNEWT-787
 URL: https://issues.apache.org/jira/browse/MYNEWT-787
 Project: Mynewt
  Issue Type: New Feature
  Security Level: Public (Viewable by anyone)
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


The serial boot loader fails to process some newtmgr commands:

1. The image list response is too large for the outgoing buffer.
2. The "new" newtmgr sends large image chunks in its image upload requests.  
These chunks are too large for the serial boot loader's input buffer.

The fixes are as follows:
1. Increase the outgoing buffer size from 48 to 128.
2. Increase the incoming buffer size from 128 to 512.
3. Return an error rather than overrun the output buffer.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYNEWT-786) newtmgr - BLE support that doesn't require blehostd

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-786:
--

 Summary: newtmgr - BLE support that doesn't require blehostd
 Key: MYNEWT-786
 URL: https://issues.apache.org/jira/browse/MYNEWT-786
 Project: Mynewt
  Issue Type: New Feature
  Security Level: Public (Viewable by anyone)
  Components: Newtmgr
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


newtmgr currently supports BLE as a transport via blehostd, a NimBLE host 
running in a simulated OS.  This implementation works, but it comes with the 
following issues:

* Inability to use the built-in Bluetooth controller in MacOS.
* Hassle of setting up and configuring blehostd.

The task captured in this ticket is to add a second form of BLE support to 
newtmgr which addresses these shortcomings.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Blinky on nRF52 DEV via Black Magic Probe: SIGSEGV in os_pkg_init

[Christopher Collins]

Hi Peter,

On Fri, Jun 16, 2017 at 04:10:52PM -0700, Peter Jones wrote:
> It's very likely that I'm doing something wrong so I'm reaching out for
> help.  All I want to do right now is to get Blinky working on an nRF52.
> 
> I followed the tutorial and built the boot loader and blinky.  I then
> created an image so the boot loader would be happy about the magic
> number.
> 
> I used GDB and the Black Magic Probe to flash the boot loader ELF file
> to address offset 0x.  Then I used the `restore' command to flash the
> blinky IMG file to offset 0x8000.  (I debugged the jlink shell scripts
> to figure this out.)
> 
> At this point I would expect that resetting the board would cause the
> LED to blink once a second.  Of course, that's not happening.
> 
> So I started GDB, used the `file' command to load symbols from the boot
> loader ELF file, and restarted the boot loader with `run'.  That's when
> I get:
> 
> 
>   Program received signal SIGSEGV, Segmentation fault.
>   os_pkg_init () at repos/apache-mynewt-core/kernel/os/src/os.c:223
>   
> 
> I stepped through the code and I end up inside `os_start' which appears
> to only have `assert(0)' as its body (because `#if
> MYNEWT_VAL(OS_SCHEDULING)').

Your procedure sounds correct to me, so I'm afraid I don't have an
explanation.  I am not familiar with the black magic probe, though.

The behavior you described is definitely unexpected.  The boot loader
should not call os_start() at all; it should jump to the image's start
up code instead.

Could you paste a stack trace at the point of failure?

Thanks,
Chris

Re: What are the best config settings to reduce ram usage, so that an app runs in 16 kb with least impact on functionality?

[Christopher Collins]

On Fri, Jun 16, 2017 at 10:08:21PM +0200, Alfred Schilken wrote:
> BTW:
> every now and then I get this timeout error:
> 
> newtmgr -c ble0c stat ble_gattc
> Error: Timeout waiting for host <-> controller sync
> 
> I’m using a microbit running the blehci, connected via adafruit FT232H with 
> rts/cts.

The BLE host (running in newtmgr) thinks the controller is unresponsive.
I have not seen this happend for a while.  Does the problem eventually
resolve itself?  Does resetting the controller make the problem go away?

Chris

Re: What are the best config settings to reduce ram usage, so that an app runs in 16 kb with least impact on functionality?

[Christopher Collins]

Hi Alfred,

On Fri, Jun 16, 2017 at 07:02:47PM +0200, Alfred Schilken wrote:
> Hello all, I’m experimenting with mynewt for several weeks now and I’m 
> especially impressed by the statistics, logging and image update 
> functionality.
> I’m having problems with getting all the statistics using newtmgr via BLE.
> 
> I  took bleprph as base, added ADC and enabled several stats, logs and so on.
> To reduce flash size I had to switch off debug and reduce the logging.
> 
> When I started the program I got an Assert-reboot-loop.
> The target board is a bbc microbit.
> 
> This seems to be cause of the error:
> ble_att_svr_entry_mem = malloc(
> OS_MEMPOOL_BYTES(ble_hs_max_attrs, sizeof (struct ble_att_svr_entry)));
> if (ble_att_svr_entry_mem == NULL) {
> rc = BLE_HS_ENOMEM;
> goto err;
> }

Fitting BLE and newtmgr into 16kB requires some creativity :).  There
are certainly some memory and mbuf optimizations that could be made, we
just need to go through the exercise of scouring the code.

> I tweaked these four config values to fix the crash-loop.
> BLE_ACL_BUF_COUNT: 4# was 4
> BLE_ACL_BUF_SIZE: 128  # was 255
> MSYS_1_BLOCK_COUNT: 4  # was 12
> MSYS_1_BLOCK_SIZE: 292 # was 292
> 
> The program boots now, I can see and connect to the BLE services and all this 
> is fine.
> 
> If I use newtmgr via ble transport to read the statistics, some of them are 
> responding, others return just Error: 2.
> mpstat and taskstat also don’t work.
> But „image list“ is working, I could even upload a new image.
> 
> 
> My question is:
> What are the best config settings to reduce ram usage, so that an app runs in 
> 16 kb with least impact on functionality? 

I was able to get mpstats working on a 16kB device with the following
mbuf settings:

MSYS_1_BLOCK_COUNT: 11
MSYS_1_BLOCK_SIZE: 200

> Some hints to reduce flash size would also be appreciated :-) 

You might want to look into the split image functionality:
https://mynewt.apache.org/latest/os/modules/split/split.  This allows
you dedicate more flash space to your application code.  I don't think
this will help with your immediates issues, however, since BLE and
newtmgr would both need to go into the loader image.

Chris

[jira] [Resolved] (MYNEWT-755) newtmgr panic: runtime error: cgo argument has Go pointer to Go pointer

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-755.

Resolution: Won't Fix

Ah, I see.  Sorry... somehow I missed that you were using a BLE connection 
profile.

The gatt library (what newtmgr uses for BLE connectivity) doesn't work in Mac 
OS.  That is why you're seeing that ugly crash dump.  We could add a proper 
error message instead of the crash, but I don't think it matters too much in 
this case because we'll be replacing that version of newtmgr with one that 
actually does work in Mac OS: https://github.com/apache/incubator-mynewt-newtmgr

> newtmgr panic: runtime error: cgo argument has Go pointer to Go pointer
> ---
>
> Key: MYNEWT-755
> URL: https://issues.apache.org/jira/browse/MYNEWT-755
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newtmgr
>Reporter: Jacob
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Googling seems to indicate maybe it needs refactoring?
> https://github.com/ry/v8worker/issues/31
> Ive tried back to mynewt_1_0_0_b2_tag and it still happens so I think its 
> tied to again either xcode update or maybe a go point release?
> Jacobs-MacBook-Air:newtmgr jacobrosenthal$ go version
> go version go1.7.5 darwin/amd64
> My xcode is 8.3.2
> But I can confirm the listed workaround is to use GODEBUG=cgocheck=0 works 
> but I get (possibly unrelated?) unhandled xpc events as well



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-310) newt should globally namespace remote repositories

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-310:
---
Fix Version/s: (was: v1_1_0_rel)

> newt should globally namespace remote repositories
> --
>
> Key: MYNEWT-310
> URL: https://issues.apache.org/jira/browse/MYNEWT-310
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>Reporter: Sterling Hughes
>        Assignee: Christopher Collins
>
> Right now remote repositories can have conflicting names (e.g. somebody else 
> could reserve apache-mynewt-core, and newt wouldn't have a way of resolving 
> the conflict.)
> Need some form of global namespacing on repository descriptors, whether using 
> the DNS name (ala go), or some other sort of registry.
> This will become important once inter-repository dependencies and mirroring 
> come into play.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (MYNEWT-190) Support automatically sending failure logs for newt

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reassigned MYNEWT-190:
--

 Assignee: (was: Christopher Collins)
Fix Version/s: (was: v1_1_0_rel)

> Support automatically sending failure logs for newt 
> 
>
> Key: MYNEWT-190
> URL: https://issues.apache.org/jira/browse/MYNEWT-190
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Reporter: Sterling Hughes
>
> When newt fails to build, or users experience newt failures.  There should be 
> an option to create a log bundle that can be sent to Mynewt, or automatically 
> posted and create JIRA ticket in the Mynewt ASF system.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (MYNEWT-120) Add generation of IDE project files into newt

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins reassigned MYNEWT-120:
--

 Assignee: (was: Christopher Collins)
Fix Version/s: (was: v1_1_0_rel)

> Add generation of IDE project files into newt
> -
>
> Key: MYNEWT-120
> URL: https://issues.apache.org/jira/browse/MYNEWT-120
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Reporter: Sterling Hughes
>Priority: Minor
>
> Add support for generating IDE project files from the newt tool: 
> - Eclipse
> - Sublime
> - Makefile



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-325) BLE Host - Allow ECC to be delegated to the controller

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-325:
---
Fix Version/s: (was: v1_1_0_rel)

> BLE Host - Allow ECC to be delegated to the controller
> --
>
> Key: MYNEWT-325
> URL: https://issues.apache.org/jira/browse/MYNEWT-325
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
>Priority: Minor
>
> The host currently does all ECC operations in software using the tinycrypt 
> library.  We need to:
> * Implement the ECC HCI commands in the host and controller.
> * Create a build option which:
> ** Enables ECC functionality in the controller.
> ** Disables ECC functionality in the host.
> ** Makes the host use the HCI commands rather than call into tinycrypt.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-38) Implement ECC correction in NFFS

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-38:
--
Fix Version/s: (was: v1_1_0_rel)

> Implement ECC correction in NFFS
> 
>
> Key: MYNEWT-38
> URL: https://issues.apache.org/jira/browse/MYNEWT-38
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>  Components: NFFS
>Reporter: Sterling Hughes
>    Assignee: Christopher Collins
>
> Data stored in NFFS files should optionally have ECC coding applied to them 
> to correct for data corruption.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-301) nffs corrupt

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-301:
---
Fix Version/s: (was: v1_1_0_rel)

> nffs corrupt
> 
>
> Key: MYNEWT-301
> URL: https://issues.apache.org/jira/browse/MYNEWT-301
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: NFFS
>Affects Versions: v1_0_0_beta2
>Reporter: Marko Kiiskila
>    Assignee: Christopher Collins
> Attachments: bad_arduino_nffs.bin, bad_arduino_nffs.bin2
>
>
> happened on arduino, bootloader does not come up as NFFS is asserting.
> (gdb) bt
> #0  __assert_func (file=0x742a "nffs_restore.c", line=229, func=0x0 
> <_sfixed>, 
> e=0x0 <_sfixed>) at os_fault.c:113
> #1  0x22ac in nffs_restore_find_file_ends () at nffs_restore.c:285
> #2  nffs_restore_full (area_descs=area_descs@entry=0x2000736c)
> at nffs_restore.c:1160
> #3  0x04ca in nffs_detect (area_descs=area_descs@entry=0x2000736c)
> at nffs.c:605
> #4  0x01e8 in setup_for_nffs () at boot.c:80
> #5  main () at boot.c:160
> (gdb) up



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-37) Implement FS compression in NFFS

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-37:
--
Fix Version/s: (was: v1_1_0_rel)

> Implement FS compression in NFFS
> 
>
> Key: MYNEWT-37
> URL: https://issues.apache.org/jira/browse/MYNEWT-37
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>  Components: NFFS
>Reporter: Sterling Hughes
>    Assignee: Christopher Collins
>
> Compression should be supported in NFFS.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-13) NFFS does not work on STM32F3 or NXP MK64F12

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-13:
--
Fix Version/s: (was: v1_1_0_rel)

> NFFS does not work on STM32F3 or NXP MK64F12
> 
>
> Key: MYNEWT-13
> URL: https://issues.apache.org/jira/browse/MYNEWT-13
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: NFFS
>Reporter: Marko Kiiskila
>    Assignee: Christopher Collins
>Priority: Minor
>
> STM32F3 flash writes are done 2 bytes at a time. MK64F12 flash alignment is 
> 8. NFFS should take into account alignment restrictions underlying storage 
> has.
> E.g. add alignment requirement in struct hal_flash. Add an HAL flash API call 
> to query this. NFFS would then use this when writing/reading blocks of data 
> from flash.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-338) NFFS - Can't delete from a completely full file system

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-338:
---
Fix Version/s: (was: v1_1_0_rel)

> NFFS - Can't delete from a completely full file system
> --
>
> Key: MYNEWT-338
> URL: https://issues.apache.org/jira/browse/MYNEWT-338
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: NFFS
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
>
> Deleting a file or directory requires writing an inode to the disk.  If the 
> disk is completely full, there is not room for the deletion record, and the 
> delete attempt will fail with an FS_EFULL error.
> It should be sufficient to always ensure that at least one area has room for 
> a deletion record.  All deletion records are the same size.  Once a deletion 
> record is written, the previous inode entry and all children inodes or 
> constituent data blocks can be removed during garbage collection.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYNEWT-343) nffs crash at bootloader

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-343:
---
Fix Version/s: (was: v1_1_0_rel)

> nffs crash at bootloader
> 
>
> Key: MYNEWT-343
> URL: https://issues.apache.org/jira/browse/MYNEWT-343
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: NFFS
> Environment: Arduino Zero with NFFS
>Reporter: Marko Kiiskila
>    Assignee: Christopher Collins
> Attachments: arduino_nffs.bin, nffs-inode-invalid-id.bin
>
>
> System asserts. I was switching between images.
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __assert_func (file=, line=, 
> func=, e=) at os_fault.c:124
> 124  asm("bkpt");
> (gdb) bt
> #0  __assert_func (file=, line=, 
> func=, e=) at os_fault.c:124
> #1  0x105e in nffs_hash_remove (entry=entry@entry=0x20001ad8)
> at nffs_hash.c:179
> #2  0x2ff2 in nffs_block_delete_from_ram (
> block_entry=block_entry@entry=0x20001ad8) at nffs_block.c:266
> #3  0x26f2 in nffs_restore_sweep () at nffs_restore.c:353
> #4  0x283e in nffs_restore_full (area_descs=area_descs@entry=0x2000736c)
> at nffs_restore.c:1400
> #5  0x04ca in nffs_detect (area_descs=area_descs@entry=0x2000736c)
> at nffs.c:606
> #6  0x01e8 in setup_for_nffs () at boot.c:93
> #7  main () at boot.c:173



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)