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

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-755:
--

Heh. duh. Yeah I actually know that. I was probably using serial transport and 
then switched to ble not thinking.

EXCEPT, it turns out ble does work on ios when I use the GODEBUG=cgocheck=0 
flag :)

Jacobs-MacBook-Air:newt jacobrosenthal$ GODEBUG=cgocheck=0 newtmgr image 
coredownload core.dump -cnimble_bleprph
2017/06/14 19:43:34 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}}
Got response: 6 bytes
No corefile present
Jacobs-MacBook-Air:newt jacobrosenthal$ 


> 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] [Closed] (MYNEWT-747) Impossible to newtmgr upload firmware to nrf51 devices

[Jacob (JIRA)]

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

Jacob closed MYNEWT-747.

Resolution: Fixed

> Impossible to newtmgr upload firmware to nrf51 devices
> --
>
> Key: MYNEWT-747
> URL: https://issues.apache.org/jira/browse/MYNEWT-747
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Image Mgmt, Newtmgr
> Environment: All
>Reporter: Jacob
>Assignee: Marko Kiiskila
> Fix For: v1_1_0_rel
>
>
> It is currently not possible to upload firmware to a nrf51 device.
> Mailing list discussion:
> https://lists.apache.org/thread.html/bc99b1c75790198685d40a12e8e49de12f0b9e8891f93f2fd9a95f0d@%3Cdev.mynewt.apache.org%3E
> Logs show:
> 832:[ts=6499968ssb, mod=4 level=0] Disconnection Complete: status=0 handle=1 
> reason=8
> Appears to be related to the flash erase
> https://github.com/apache/incubator-mynewt-core/blob/cb23f34e9b55de68078c0c2200b268cf536d003b/mgmt/imgmgr/src/imgmgr.c#L324
> Flash erase is blocking and takes a while, so traditionally on nordic 
> softdevic schedule to work outside of radio events as much as possible.  
> newtmgr isnt and probably shouldn't be coupled down to the radio abstraction.
> Nordic forum also talks about altering intervals and latencies, 
> https://devzone.nordicsemi.com/question/24290/slow-flash-erase-performance-with-sd_flash_page_erase/?answer=24361#post-id-24361
> but discussion on the list also found that a lacking solution
> One possible solution discussed solution was to separate erase from upload 
> commands 



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

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

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-755:
--

Last login: Sun Jun 11 16:22:02 on ttys007
Jacobs-MacBook-Air:~ jacobrosenthal$ cd $GOPATH
Jacobs-MacBook-Air:go jacobrosenthal$ cd src/mynewt.apache.org/newt/
Jacobs-MacBook-Air:newt jacobrosenthal$ git branch
  image_erase
* master
  newtmgr-erase
Jacobs-MacBook-Air:newt jacobrosenthal$ git pull origin master
remote: Counting objects: 29, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 29 (delta 20), reused 23 (delta 14), pack-reused 0
Unpacking objects: 100% (29/29), done.
>From https://github.com/apache/incubator-mynewt-newt
 * branch  master -> FETCH_HEAD
   97bb88d6..cd248f80  master -> origin/master
Updating 97bb88d6..cd248f80
Fast-forward
 newt/cli/image_cmds.go | 60 
 newt/cli/run_cmds.go   |  9 +++
 newt/image/image.go| 67 ++
 3 files changed, 131 insertions(+), 5 deletions(-)
Jacobs-MacBook-Air:newt jacobrosenthal$ cd newt
Jacobs-MacBook-Air:newt jacobrosenthal$ go install
Jacobs-MacBook-Air:newt jacobrosenthal$ cd ../newtmgr/
Jacobs-MacBook-Air:newtmgr jacobrosenthal$ go install
Jacobs-MacBook-Air:newtmgr jacobrosenthal$ pwd
/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr
Jacobs-MacBook-Air:newtmgr jacobrosenthal$ newtmgr
Newtmgr helps you manage remote devices running the Mynewt OS

Usage:
  newtmgr [flags]
  newtmgr [command]

Available Commands:
  config  Read or write a config value on a device
  connManage newtmgr connection profiles
  crash   Send a crash command to a device
  datetimeManage datetime on a device
  echoSend data to a device and display the echoed back data
  fs  Access files on a device
  image   Manage images on a device
  log Manage logs on a device
  mpstats Read memory pool statistics from a device
  reset   Send reset request to a device
  run Run test procedures on a device
  statRead statistics from a device
  taskstats   Read task statistics from a device

Flags:
  -c, --conn string   connection profile to use
  -h, --help  Help for newtmgr commands
  -l, --loglevel string   log level to use (default "info")
  -t, --trace print all bytes transmitted and received

Use "newtmgr [command] --help" for more information about a command.
Jacobs-MacBook-Air:newtmgr jacobrosenthal$ newtmgr image list -cnimble_bleprph
panic: runtime error: cgo argument has Go pointer to Go pointer

goroutine 1 [running]:
mynewt.apache.org/newt/newtmgr/vendor/github.com/runtimeco/gatt/xpc.XpcConnect.func2(0x4b00120,
 0xc420149290, 0x4b00120)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/runtimeco/gatt/xpc/xpc_darwin.go:169
 +0xaf
mynewt.apache.org/newt/newtmgr/vendor/github.com/runtimeco/gatt/xpc.XpcConnect(0x4627b26,
 0xf, 0x48973c0, 0xc420144300, 0x0)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/runtimeco/gatt/xpc/xpc_darwin.go:169
 +0xc2
mynewt.apache.org/newt/newtmgr/vendor/github.com/runtimeco/gatt.NewDevice(0x48f1580,
 0x0, 0x0, 0x1, 0x1, 0x0, 0x48d3240)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/runtimeco/gatt/device_darwin.go:67
 +0x239
mynewt.apache.org/newt/newtmgr/transport.(*ConnBLE).Open(0xc42012e660, 
0x489dec0, 0xc42013c230, 0x0, 0x7fff5fbffbad, 0xe)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/transport/connble.go:169
 +0x1ce
mynewt.apache.org/newt/newtmgr/transport.newConn(0x489dec0, 0xc42013c230, 0x0, 
0x0, 0x0, 0xc42012e420, 0xc420132050)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/transport/conn.go:110
 +0x230
mynewt.apache.org/newt/newtmgr/transport.NewConn(0x489dec0, 0xc42013c230, 0xe, 
0xc42013c230, 0x0, 0x0)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/transport/conn.go:75
 +0x3e
mynewt.apache.org/newt/newtmgr/cli.getTargetCmdRunner(0x0, 0x0, 0xc42010dd18)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/cli/common.go:39
 +0x8b
mynewt.apache.org/newt/newtmgr/cli.imageStateListCmd(0xc420151d40, 
0xc420149120, 0x0, 0x1)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/cli/image.go:86 
+0x26
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).execute(0xc420151d40,
 0xc420149110, 0x1, 0x1, 0xc420151d40, 0xc420149110)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:636
 +0x231
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc42015,
 0xc4201518c0, 0xc420151200, 0xc420148e80)

[jira] [Commented] (MYNEWT-747) Impossible to newtmgr upload firmware to nrf51 devices

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-747:
--

Resolved in https://issues.apache.org/jira/browse/MYNEWT-733

> Impossible to newtmgr upload firmware to nrf51 devices
> --
>
> Key: MYNEWT-747
> URL: https://issues.apache.org/jira/browse/MYNEWT-747
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Image Mgmt, Newtmgr
> Environment: All
>Reporter: Jacob
>Assignee: Marko Kiiskila
> Fix For: v1_1_0_rel
>
>
> It is currently not possible to upload firmware to a nrf51 device.
> Mailing list discussion:
> https://lists.apache.org/thread.html/bc99b1c75790198685d40a12e8e49de12f0b9e8891f93f2fd9a95f0d@%3Cdev.mynewt.apache.org%3E
> Logs show:
> 832:[ts=6499968ssb, mod=4 level=0] Disconnection Complete: status=0 handle=1 
> reason=8
> Appears to be related to the flash erase
> https://github.com/apache/incubator-mynewt-core/blob/cb23f34e9b55de68078c0c2200b268cf536d003b/mgmt/imgmgr/src/imgmgr.c#L324
> Flash erase is blocking and takes a while, so traditionally on nordic 
> softdevic schedule to work outside of radio events as much as possible.  
> newtmgr isnt and probably shouldn't be coupled down to the radio abstraction.
> Nordic forum also talks about altering intervals and latencies, 
> https://devzone.nordicsemi.com/question/24290/slow-flash-erase-performance-with-sd_flash_page_erase/?answer=24361#post-id-24361
> but discussion on the list also found that a lacking solution
> One possible solution discussed solution was to separate erase from upload 
> commands 



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

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

[Jacob (JIRA)]

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

Jacob updated MYNEWT-756:
-

switched to nrf51dk pca10031 which i guess in an nrf51422 qfac using
nrf51dk bsp

core Commit a6c5103e6b709423cf9380e9d2e57004bafb2ca9

i can strip sysfg all the way down to here and it always just hangs

Jacobs-MacBook-Air:chippd3 jacobrosenthal$ newt target show bleprph-nrf51dk
targets/bleprph-nrf51dk
app=@apache-mynewt-core/apps/bleprph
bsp=@apache-mynewt-core/hw/bsp/nrf51dk
build_profile=optimized
syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0:BLE_SM_SC=0
Jacobs-MacBook-Air:chippd3 jacobrosenthal$


and it just hangs like ive seen on nrf51dk-16kbram bsps

if i turn logs back on

Jacobs-MacBook-Air:chippd3 jacobrosenthal$ newt target show bleprph-nrf51dk
targets/bleprph-nrf51dk
app=@apache-mynewt-core/apps/bleprph
bsp=@apache-mynewt-core/hw/bsp/nrf51dk
build_profile=optimized

syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0:BLE_SM_SC=0:CONSOLE_COMPAT=1:CONSOLE_ECHO=0:CONSOLE_INPUT=0:CONSOLE_MAX_INPUT_LEN=0:CONSOLE_RTT=1:CONSOLE_UART=0:LOG_LEVEL=0
Jacobs-MacBook-Air:chippd3 jacobrosenthal$



Jacobs-MacBook-Air:node-newtmgr jacobrosenthal$ GODEBUG=cgocheck=0 newtmgr
mpstats -cnimble_bleprph -ldebug -t
2017/06/06 21:01:19 [DEBUG] BLE Connection devaddr:[]
2017/06/06 21:01:19 [DEBUG] State:PoweredOn
2017/06/06 21:01:19 [DEBUG] scanning...
2017/06/06 21:01:19 [DEBUG] Peripheral Discovered: , Address:[0 0 0 0 0 0]
Address Type:0
2017/06/06 21:01:19 [DEBUG] Peripheral Discovered: , Address:[0 0 0 0 0 0]
Address Type:0
2017/06/06 21:01:20 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/06/06 21:01:20 [DEBUG] Peripheral Connected
2017/06/06 21:01:20 [DEBUG] Newtmgr Service Found
2017/06/06 21:01:20 [DEBUG] Newtmgr Characteristic Found
2017/06/06 21:01:20 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:0
Group:0 Seq:0 Id:3 Data:[]}
2017/06/06 21:01:20 [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/06/06 21:01:20 [DEBUG] Tx packet dump:
  00 00 00 00 00 00 00 03   ||

2017/06/06 21:01:20 [DEBUG] Write BLE Packet:buf:: len::8
2017/06/06 21:01:20 [DEBUG] Read BLE
Packet:buf::l?brcfmpools?fmsys_1?fblksiz$enblks

enfree cmi?wble_hci_ram_evt_hi_pool?fblksizHenblkse len::101
2017/06/06 21:01:20 [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 08 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/06/06 21:01:20 [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 8 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/06/06 21:01:20 [DEBUG] Read BLE
Packet:buf::nfreecmin?wble_hci_ram_evt_lo_pool?fblksizHenblkenfrecmi?rble_hs_hci_ev_pool?fblksizenblks
 len::101
2017/06/06 21:01:20 [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/06/06 21:01:20 [DEBUG] Read BLE Packet:buf::enfree
cmin 
?pble_hs_conn_pool?fblksizTenblksenfreecmin?sble_l2cap_chan_pool?fblksizenblksenfr
len::101
2017/06/06 21:01:20 [DEBUG] Rx packet dump:
  65 6e 66 72 65 65 0a 63  6d 69 6e 09 ff 70 62 6c
 |enfree.cmin..pbl|
0010  65 5f 68 73 5f 63 6f 6e  6e 5f 70 6f 6f 6c bf 66
 |e_hs_conn_pool.f|
0020  62 6c 6b 73 69 7a 18 54  65 6e 62 6c 6b 73 01 65
 |blksiz.Tenblks.e|
0030  6e 66 72 65 65 00 63 6d  69 6e 00 ff 73 62 6c 65
 |nfree.cmin..sble|
0040  5f 6c 32 63 61 70 5f 63  68 61 6e 5f 70 6f 6f 6c
 |_l2cap_chan_pool|
0050  bf 66 62 6c 6b 73 69 7a 

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

[Jacob (JIRA)]

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

Jacob updated MYNEWT-756:
-

Maybe my device is weird. Ive got 2 new shipping now.

On Tue, Jun 6, 2017 at 3:24 PM, Christopher Collins (JIRA) 



> 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_pool?fblksizenblksenfr
>  len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
>   65 6e 66 72 65 65 0a 63  6d 69 6e 09 ff 70 62 6c  |enfree.cmin..pbl|
> 0010  65 5f 68 73 5f 63 6f 6e  6e 5f 70 6f 6f 6c bf 66  |e_hs_conn_pool.f|
> 0020  62 6c 6b 73 69 7a 18 54  65 6e 62 6c 6b 73 01 65  |blksiz.Tenblks.e|
> 0030  6e 66 72 65 65 00 63 6d  69 6e 00 ff 73 62 6c 65  |nfree.cmin..sble|
> 0040  5f 6c 32 63 61 70 5f 63  68 61 6e 5f 70 6f 6f 6c  |_l2cap_chan_pool|
> 0050  bf 66 62 6c 6b 73 69 7a  18 1c 65 6e 62 6c 6b 73  |.fblksiz..enblks|
> 0060  03 65 6e 66 72|.enfr|
> 2017/05/11 22:28:47 [DEBUG] Read BLE 
> 

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

[Jacob (JIRA)]

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

Jacob updated MYNEWT-756:
-

yeah I cant use 12 x 292 on a 16kbram device

MSYS_1_BLOCK_COUNT: 8 #12
MSYS_1_BLOCK_SIZE: 149 #292 # 76 lowest, 80 for multi-adv 149?? for
nmgr_uart
p os_msys_init_1_mempool



$1 = {mp_block_size = 152, mp_num_blocks = 8, mp_num_free = 7, mp_min_free
= 0, mp_membuf_addr = 536873848, mp_list = {
stqe_next = 0x20001898 }, {slh_first =
0x2f08 }, name = 0x200eb "msys_1"}


so its definately running out of pools

by increasing blocks I can get it to ENOMEM instead of just dying
but then also .. a 50/50 that doesnt work and it does this hang

during a freeze instead of an enomem return, note there is no disconnect,
just hangs out, not sure there is anything in here, but logs look like this:

001073 [ts=8382788ssb, mod=4 level=0] LE connection complete. handle=1
role=1 paddrtype=0 addr=b8.e8.56.3.d3.ed local_rpa=0.0.0.0.0.0
peer_rpa=0.0.0.0.0.0 itvl=12 latency=0 spvn_tmo=200 mca=5
001074 [ts=8390600ssb, mod=64 level=1] connection established; status=0
handle=1 our_ota_addr_type=0 our_ota_addr=0a:0a:0a:0a:0a:0a
our_id_addr_type=0 our_id_addr=0a:0a:0a:0a:0a:0a peer_ota_addr_type=0
peer_ota_addr=b8:e8:56:03:d3:ed peer_id_addr_type=0
peer_id_addr=b8:e8:56:03:d3:ed conn_itvl=12 conn_latency=0
supervision_timeout=200 encrypted=0 authenticated=0 bonded=0
001075 [ts=8398412ssb, mod=64 level=1]
001077 [ts=8414036ssb, mod=4 level=0] ble_hs_hci_evt_acl_process():
conn_handle=1 pb=2 len=7 data=0x03 0x00 0x04 0x00 0x02 0x68 0x00
001077 [ts=8414036ssb, mod=4 level=0] rxed att command: mtu req; conn=1
mtu=104
001078 [ts=8421848ssb, mod=4 level=0] txed att command: mtu rsp; conn=1
mtu=527
001078 [ts=8421848ssb, mod=4 level=0] host tx hci data; handle=1 length=7
001079 [ts=8429660ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x07
0x00 0x03 0x00 0x04 0x00 0x03 0x0f 0x02
001080 [ts=8437472ssb, mod=64 level=1] mtu update event; conn_handle=1
cid=4 mtu=104
001083 [ts=8460908ssb, mod=4 level=0] ble_hs_hci_evt_acl_process():
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x08 0x01 0x00 0xff 0xff
0x00 0x2a
001083 [ts=8460908ssb, mod=4 level=0] rxed att command: read type req;
conn=1 start_handle=0x0001 end_handle=0x
001084 [ts=8468720ssb, mod=4 level=0] txed att command: read type rsp;
conn=1 length=16
001085 [ts=8476532ssb, mod=4 level=0] host tx hci data; handle=1 length=22
001085 [ts=8476532ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x16
0x00 0x12 0x00 0x04 0x00 0x09 0x10 0x10 0x00 0x6e 0x69 0x6d 0x62 0x6c 0x65
0x2d 0x62 0x6c 0x65 0x70 0x72 0x70 0x68
001086 [ts=8484344ssb, mod=4 level=0] Number of Completed Packets:
num_handles=1
001087 [ts=8492156ssb, mod=4 level=0] handle:1 pkts:1
001092 [ts=8531216ssb, mod=4 level=0] ble_hs_hci_evt_acl_process():
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x10 0x01 0x00 0xff 0xff
0x00 0x28
001093 [ts=8539028ssb, mod=4 level=0] rxed att command: read group type
req; conn=1 start_handle=0x0001 end_handle=0x
001094 [ts=8546840ssb, mod=4 level=0] txed att command: read group type
rsp; conn=1 length=6
001094 [ts=8546840ssb, mod=4 level=0] host tx hci data; handle=1 length=24
001095 [ts=8554652ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x18
0x00 0x14 0x00 0x04 0x00 0x11 0x06 0x01 0x00 0x0d 0x00 0x11 0x18 0x0e 0x00
0x18 0x00 0x00 0x18 0x19 0x00 0x1c 0x00 0x01 0x18
001096 [ts=8562464ssb, mod=4 level=0] Number of Completed Packets:
num_handles=1
001096 [ts=8562464ssb, mod=4 level=0] handle:1 pkts:1
001100 [ts=8593712ssb, mod=4 level=0] ble_hs_hci_evt_acl_process():
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x10 0x1d 0x00 0xff 0xff
0x00 0x28
001101 [ts=8601524ssb, mod=4 level=0] rxed att command: read group type
req; conn=1 start_handle=0x001d end_handle=0x
001101 [ts=8601524ssb, mod=4 level=0] txed att command: read group type
rsp; conn=1 length=20
001102 [ts=8609336ssb, mod=4 level=0] host tx hci data; handle=1 length=26
001102 [ts=8609336ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x1a
0x00 0x16 0x00 0x04 0x00 0x11 0x14 0x1d 0x00 0xff 0xff 0x84 0xaa 0x60 0x74
0x52 0x8a 0x8b 0x86 0xd3 0x4c 0xb7 0x1d 0x1d 0xdc 0x53 0x8d
001104 [ts=8624960ssb, mod=4 level=0] Number of Completed Packets:
num_handles=1
001104 [ts=8624960ssb, mod=4 level=0] handle:1 pkts:1
001108 [ts=8656208ssb, mod=4 level=0] ble_hs_hci_evt_acl_process():
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x08 0x0e 0x00 0x18 0x00
0x03 0x28
001108 [ts=8656208ssb, mod=4 level=0] rxed att command: read type req;
conn=1 start_handle=0x000e end_handle=0x0018
001109 [ts=8664020ssb, mod=4 level=0] txed att command: read type rsp;
conn=1 length=7
001109 [ts=8664020ssb, mod=4 level=0] host tx hci data; handle=1 length=41
001110 [ts=8671832ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x29
0x00 0x25 0x00 0x04 0x00 0x09 0x07 0x0f 0x00 0x02 0x10 0x00 0x00 0x2a 0x11

[jira] [Updated] (MYNEWT-733) newtmgr image upload crashes on nrf51 devices

[Jacob (JIRA)]

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

Jacob updated MYNEWT-733:
-

were working on it right now in slack. Appears to be related to stack
thinking it still has a connection after disconnect and advertise


On Mon, Jun 5, 2017 at 1:47 PM, Marko Kiiskila (JIRA) 



> newtmgr image upload crashes on nrf51 devices
> -
>
> Key: MYNEWT-733
> URL: https://issues.apache.org/jira/browse/MYNEWT-733
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newtmgr
>Reporter: Jacob
>Assignee: Christopher Collins
> Attachments: upload crash.txt
>
>
> Jacobs-MacBook-Air:chippd3 jacobrosenthal$ newt target show split-nrf51dk 
> targets/split-nrf51dk
> app=@apache-mynewt-core/apps/blesplit
> bsp=@apache-mynewt-core/hw/bsp/nrf51dk
> build_profile=optimized
> loader=@apache-mynewt-core/apps/bleprph
> 
> syscfg=BLE_ACL_BUF_SIZE=128:BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0:LOG_LEVEL=0
> [jacobrosenthal@localhost Downloads]$ sudo "$(which newtmgr)" -c ble image 
> upload  blesplit.img -t -ldebug
> 2017/04/14 15:02:08 [DEBUG] BLE Connection devaddr:[]
> 2017/04/14 15:02:08 dev: hci0 up
> 2017/04/14 15:02:08 dev: hci0 down
> 2017/04/14 15:02:08 dev: hci0 opened
> 2017/04/14 15:02:08 [DEBUG] State:PoweredOn
> 2017/04/14 15:02:08 [DEBUG] scanning...
> 2017/04/14 15:02:08 [DEBUG] Peripheral Discovered: nimble-bleprph, 
> Address:[10 10 10 10 10 10] Address Type:0
> 2017/04/14 15:02:08 [DEBUG] Peripheral Connected
> 2017/04/14 15:02:08 [DEBUG] Newtmgr Service Found 
> 2017/04/14 15:02:08 [DEBUG] Newtmgr Characteristic Found
> 2017/04/14 15:02:08 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:99 
> Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 
> 32 0 0 0 72 16 0 0 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64 0 32 41 56 2 0 0 26 
> 128 243 20 136 128 243 16 136 3 33 24 72 2 104 10 67 2 96 23 72 2 104 10 67 2 
> 96 0 26 22 74 22 75 154 66 1 210 1 99 108 101 110 25 16 140 99 111 102 102 0]}
> 2017/04/14 15:02:08 [DEBUG] Serializing request &{Op:2 Flags:0 Len:99 Group:1 
> Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 
> 72 16 0 0 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64 0 32 41 56 2 0 0 26 128 243 
> 20 136 128 243 16 136 3 33 24 72 2 104 10 67 2 96 23 72 2 104 10 67 2 96 0 26 
> 22 74 22 75 154 66 1 210 1 99 108 101 110 25 16 140 99 111 102 102 0]} into 
> buffer [2 0 0 99 0 1 0 1 163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 
> 32 0 0 0 72 16 0 0 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64 0 32 41 56 2 0 0 26 
> 128 243 20 136 128 243 16 136 3 33 24 72 2 104 10 67 2 96 23 72 2 104 10 67 2 
> 96 0 26 22 74 22 75 154 66 1 210 1 99 108 101 110 25 16 140 99 111 102 102 0]
> 2017/04/14 15:02:08 [DEBUG] Tx packet dump:
>   02 00 00 63 00 01 00 01  a3 64 64 61 74 61 58 4f  |...c.ddataXO|
> 0010  3c b8 f3 96 24 00 00 00  20 00 00 00 48 10 00 00  |<...$... ...H...|
> 0020  12 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> 0030  00 40 00 20 29 38 02 00  00 1a 80 f3 14 88 80 f3  |.@. )8..|
> 0040  10 88 03 21 18 48 02 68  0a 43 02 60 17 48 02 68  |...!.H.h.C.`.H.h|
> 0050  0a 43 02 60 00 1a 16 4a  16 4b 9a 42 01 d2 01 63  |.C.`...J.K.B...c|
> 0060  6c 65 6e 19 10 8c 63 6f  66 66 00 |len...coff.|
> 2017/04/14 15:02:08 [DEBUG] Write BLE Packet:buf:: c �ddataXO<���$ H @ )8 �� 
> ��� � ! H h
> C ` H h
> C ` J K�B � clen �coff len::107
> 2017/04/14 15:02:12 [DEBUG] Disconnected%!(EXTRA )
> Ive seen a disconnection with 520
> 832:[ts=6499968ssb, mod=4 level=0] Disconnection Complete: status=0 handle=1 
> reason=8
> 834:[ts=6515592ssb, mod=64 level=1] connection updated; status=520 handle=1 
> our_ota_addr_type=0 our_ota_addr=0a:0a:0a:0a:0a:0a our_id_addr_type=0 
> our_id_addr=0a:0a:0a:0a:0a:0a peer_ota_addr_type=0 
> peer_ota_addr=b8:e8:56:03:d3:ed peer_id_addr_type=0 
> peer_id_addr=b8:e8:56:03:d3:ed conn_itvl=12 conn_latency=0 
> supervision_timeout=200 encrypted=0 authenticated=0 bonded=0
> but more recently I just get a crash in the scheduler
> 1345:[ts=10507780ssb, mod=4 level=0] Number of ComUnhandled interrupt (3), 
> exception sp 0x2998
> 1345: r0:0x24c0  r1:0x0001  r2:0x20002ff0  r3:0x0001
> 1345: r4:0x24c0  r5:0x0001  r6:0x002b  r7:0x2a99
> 1345: r8:0x  r9:0x r10:0x r11:0x
> 1345:r12:0x  lr:0x9279  pc:0x8eda psr:0x2100
> 1345:ICSR:0x00421003
> b * 0x8eda 
> Breakpoint 1 at 0x8eda: file 
> repos/apache-mynewt-core/kernel/os/src/os_sched.c, line 166.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[Jacob (JIRA)]

Jacob created MYNEWT-756:


 Summary: mpstats (on nrf51) hangs indefinately
 Key: MYNEWT-756
 URL: https://issues.apache.org/jira/browse/MYNEWT-756
 Project: Mynewt
  Issue Type: Bug
  Components: Newt
Reporter: Jacob
Assignee: Sterling Hughes


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

enfree  cmin?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_pool?fblksizenblksenfr
 len::101
2017/05/11 22:28:47 [DEBUG] Rx packet dump:
  65 6e 66 72 65 65 0a 63  6d 69 6e 09 ff 70 62 6c  |enfree.cmin..pbl|
0010  65 5f 68 73 5f 63 6f 6e  6e 5f 70 6f 6f 6c bf 66  |e_hs_conn_pool.f|
0020  62 6c 6b 73 69 7a 18 54  65 6e 62 6c 6b 73 01 65  |blksiz.Tenblks.e|
0030  6e 66 72 65 65 00 63 6d  69 6e 00 ff 73 62 6c 65  |nfree.cmin..sble|
0040  5f 6c 32 63 61 70 5f 63  68 61 6e 5f 70 6f 6f 6c  |_l2cap_chan_pool|
0050  bf 66 62 6c 6b 73 69 7a  18 1c 65 6e 62 6c 6b 73  |.fblksiz..enblks|
0060  03 65 6e 66 72|.enfr|

2017/05/11 22:28:47 [DEBUG] Read BLE 
Packet:buf::eecmin?wble_l2cap_sig_proc_pool?fblksizenblksenfreecmin?xle_att_svr_prep_entry_pool?fblksiz

e len::101
2017/05/11 22:28:47 [DEBUG] Rx packet dump:
  65 65 00 63 6d 69 6e 00  ff 77 62 6c 65 5f 6c 32  |ee.cmin..wble_l2|
0010  63 61 70 5f 73 69 67 5f  70 72 6f 63 5f 70 6f 6f  |cap_sig_proc_poo|
0020  6c bf 66 62 6c 6b 73 69  7a 14 65 6e 62 6c 6b 73  |l.fblksiz.enblks|
0030  01 65 6e 66 72 65 65 01  63 6d 69 6e 01 

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

[Jacob (JIRA)]

Jacob created MYNEWT-755:


 Summary: 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
  Components: Newtmgr
Reporter: Jacob
Assignee: Sterling Hughes


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.3.15#6346)

[jira] [Updated] (MYNEWT-526) Gap params update succeeds, but times out immediately after

[Jacob (JIRA)]

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

Jacob updated MYNEWT-526:
-

Thanks for the hard work everyone

On Mon, May 8, 2017 at 2:00 AM, Łukasz Rymanowski (JIRA) 



> Gap params update succeeds, but times out immediately after
> ---
>
> Key: MYNEWT-526
> URL: https://issues.apache.org/jira/browse/MYNEWT-526
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>Affects Versions: v1_0_0_beta1
> Environment: macos sierra, gcc version 5.4.1 20160919
>Reporter: Jacob
>Assignee: Łukasz Rymanowski
> Attachments: polar_mynewt.pcap, polar_mynewt.pcap, 
> polar_mynewt_with_android_param.pcapng
>
>
> Modification of blecent, connecting and subscribing to my polar HRM.
> My monitor (consistently) connects and subscribes and gets notifications for 
> like 30 seconds before it does a successful gap params update, and then 
> promptly times out.
> I havent confirmed this yet but grammar wise you do seem to be mixing terms, 
> timeout_multiplier and supervision_timeout are separate things in the spec
> l2cap_params->timeout_multiplier = params->supervision_timeout; 
> Perhaps the timeout_multiplier should be multiplied by 10ms to get the 
> supervision_timeout?
> 3924:[ts=30656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 3926:[ts=30671832ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=4
> 3928:[ts=30687456ssb, mod=64 level=1] 0x16:0x00:0xee:0x02
> 3929:[ts=30695268ssb, mod=64 level=1] pkthdr_len=16; om_len=4  
> ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=13 data=0x09 0x00 0x04 0x00 
> 0x1b 0x11 0x00 0x16 0x55 0xda 0x02 0xc9 0x02 
> 4052:[ts=31656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 4054:[ts=31671832ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=6
> 4056:[ts=31687456ssb, mod=64 level=1] 0x16:0x55:0xda:0x02:0xc9:0x02
> 4057:[ts=31695268ssb, mod=64 level=1] pkthdr_len=16; om_len=6  
> ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=16 data=0x0c 0x00 0x05 0x00 
> 0x12 0x01 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
> 4148:[ts=32406224ssb, mod=4 level=0] L2CAP - rxed signalling msg: 0x12 0x01 
> 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
> 4151:[ts=32429660ssb, mod=4 level=1] GAP procedure initiated: connection 
> parameter update; conn_handle=1 itvl_min=250 itvl_max=400 latency=1 
> supervision_timeout=600 min_ce_len=16 max_ce_len
> 4156:[ts=32468720ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x13 
> len=14
> 4158:[ts=32484344ssb, mod=4 level=0] 0x13 0x20 0x0e 0x01 0x00 0xfa 0x00 0x90 
> 0x01 0x01 0x00 0x58 0x02 0x10 0x00 0x00 0x03 
> 4159:[ts=32492156ssb, mod=4 level=0] Command Status: status=0 cmd_pkts=1 
> ocf=0x13 ogf=0x8
> 4162:[ts=32515592ssb, mod=4 level=0] host tx hci data; handle=1 length=10
> 4163:[ts=32523404ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0a 0x00 
> 0x06 0x00 0x05 0x00 0x13 0x01 0x02 0x00 0x00 0x00 
> 4171:[ts=32585900ssb, mod=4 level=0] Number of Completed Packets: 
> num_handles=1
> 4173:[ts=32601524ssb, mod=4 level=0] handle:1 pkts:1
> 4178:[ts=32640584ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1 
> pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x56 0xc0 0x02 
> 4181:[ts=32664020ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 4183:[ts=32679644ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=4
> 4185:[ts=32695268ssb, mod=64 level=1] 0x16:0x56:0xc0:0x02
> 4186:[ts=32703080ssb, mod=64 level=1] pkthdr_len=16; om_len=4  LE Connection 
> Update Complete. handle=1 itvl=400 latency=1 timeout=600
> 4978:[ts=38890568ssb, mod=4 level=0] Disconnection Complete: status=0 
> handle=1 reason=8
> 4980:[ts=38906192ssb, mod=64 level=1] disconnect; reason=520 handle=1 
> our_ota_addr_type=0 our_ota_addr=0c:0c:0c:0c:0c:0c our_id_addr_type=0 
> our_id_addr=0c:0c:0c:0c:0c:0c peer_ota_addr_type=0 
> peer_ota_addr=00:22:d0:2a:e4:a3 peer_id_addr_type=0 
> peer_id_addr=00:22:d0:2a:e4:a3 conn_itvl=400 conn_latency=1 
> supervision_timeout=600 encrypted=0 authenticated=0 bonded=0
> 4988:[ts=38968688ssb, mod=4 level=1] GAP procedure initiated: discovery; 
> own_addr_type=0 filter_policy=0 passive=1 limited=0 filter_duplicates=1 
> duration=forever



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYNEWT-733) newtmgr image upload crashes on nrf51 devices

[Jacob (JIRA)]

Jacob created MYNEWT-733:


 Summary: newtmgr image upload crashes on nrf51 devices
 Key: MYNEWT-733
 URL: https://issues.apache.org/jira/browse/MYNEWT-733
 Project: Mynewt
  Issue Type: Bug
  Components: Newtmgr
Reporter: Jacob
Assignee: Sterling Hughes
 Attachments: upload crash.txt

Jacobs-MacBook-Air:chippd3 jacobrosenthal$ newt target show split-nrf51dk 
targets/split-nrf51dk
app=@apache-mynewt-core/apps/blesplit
bsp=@apache-mynewt-core/hw/bsp/nrf51dk
build_profile=optimized
loader=@apache-mynewt-core/apps/bleprph

syscfg=BLE_ACL_BUF_SIZE=128:BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0:LOG_LEVEL=0


[jacobrosenthal@localhost Downloads]$ sudo "$(which newtmgr)" -c ble image 
upload  blesplit.img -t -ldebug
2017/04/14 15:02:08 [DEBUG] BLE Connection devaddr:[]
2017/04/14 15:02:08 dev: hci0 up
2017/04/14 15:02:08 dev: hci0 down
2017/04/14 15:02:08 dev: hci0 opened
2017/04/14 15:02:08 [DEBUG] State:PoweredOn
2017/04/14 15:02:08 [DEBUG] scanning...
2017/04/14 15:02:08 [DEBUG] Peripheral Discovered: nimble-bleprph, Address:[10 
10 10 10 10 10] Address Type:0
2017/04/14 15:02:08 [DEBUG] Peripheral Connected
2017/04/14 15:02:08 [DEBUG] Newtmgr Service Found 
2017/04/14 15:02:08 [DEBUG] Newtmgr Characteristic Found
2017/04/14 15:02:08 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:99 
Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 
0 0 0 72 16 0 0 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64 0 32 41 56 2 0 0 26 128 
243 20 136 128 243 16 136 3 33 24 72 2 104 10 67 2 96 23 72 2 104 10 67 2 96 0 
26 22 74 22 75 154 66 1 210 1 99 108 101 110 25 16 140 99 111 102 102 0]}
2017/04/14 15:02:08 [DEBUG] Serializing request &{Op:2 Flags:0 Len:99 Group:1 
Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 
72 16 0 0 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64 0 32 41 56 2 0 0 26 128 243 20 
136 128 243 16 136 3 33 24 72 2 104 10 67 2 96 23 72 2 104 10 67 2 96 0 26 22 
74 22 75 154 66 1 210 1 99 108 101 110 25 16 140 99 111 102 102 0]} into buffer 
[2 0 0 99 0 1 0 1 163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 
72 16 0 0 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64 0 32 41 56 2 0 0 26 128 243 20 
136 128 243 16 136 3 33 24 72 2 104 10 67 2 96 23 72 2 104 10 67 2 96 0 26 22 
74 22 75 154 66 1 210 1 99 108 101 110 25 16 140 99 111 102 102 0]
2017/04/14 15:02:08 [DEBUG] Tx packet dump:
  02 00 00 63 00 01 00 01  a3 64 64 61 74 61 58 4f  |...c.ddataXO|
0010  3c b8 f3 96 24 00 00 00  20 00 00 00 48 10 00 00  |<...$... ...H...|
0020  12 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0030  00 40 00 20 29 38 02 00  00 1a 80 f3 14 88 80 f3  |.@. )8..|
0040  10 88 03 21 18 48 02 68  0a 43 02 60 17 48 02 68  |...!.H.h.C.`.H.h|
0050  0a 43 02 60 00 1a 16 4a  16 4b 9a 42 01 d2 01 63  |.C.`...J.K.B...c|
0060  6c 65 6e 19 10 8c 63 6f  66 66 00 |len...coff.|

2017/04/14 15:02:08 [DEBUG] Write BLE Packet:buf:: c �ddataXO<���$ H @ )8 �� 
��� � ! H h
C ` H h
C ` J K�B � clen �coff len::107
2017/04/14 15:02:12 [DEBUG] Disconnected%!(EXTRA )


Ive seen a disconnection with 520
832:[ts=6499968ssb, mod=4 level=0] Disconnection Complete: status=0 handle=1 
reason=8
834:[ts=6515592ssb, mod=64 level=1] connection updated; status=520 handle=1 
our_ota_addr_type=0 our_ota_addr=0a:0a:0a:0a:0a:0a our_id_addr_type=0 
our_id_addr=0a:0a:0a:0a:0a:0a peer_ota_addr_type=0 
peer_ota_addr=b8:e8:56:03:d3:ed peer_id_addr_type=0 
peer_id_addr=b8:e8:56:03:d3:ed conn_itvl=12 conn_latency=0 
supervision_timeout=200 encrypted=0 authenticated=0 bonded=0

but more recently I just get a crash in the scheduler
1345:[ts=10507780ssb, mod=4 level=0] Number of ComUnhandled interrupt (3), 
exception sp 0x2998
1345: r0:0x24c0  r1:0x0001  r2:0x20002ff0  r3:0x0001
1345: r4:0x24c0  r5:0x0001  r6:0x002b  r7:0x2a99
1345: r8:0x  r9:0x r10:0x r11:0x
1345:r12:0x  lr:0x9279  pc:0x8eda psr:0x2100
1345:ICSR:0x00421003

b * 0x8eda 
Breakpoint 1 at 0x8eda: file repos/apache-mynewt-core/kernel/os/src/os_sched.c, 
line 166.






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYNEWT-526) Gap params update succeeds, but times out immediately after

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-526:
--

And can confirm same error just now on a pca10031, nrf51422 qfac with:

syscfg.vals:
BLE_HS_DEBUG: 1
OS_MAIN_STACK_SIZE: 428
SHELL_TASK: 1
LOG_LEVEL: 0
BLE_SM_LEGACY: 0
 


> Gap params update succeeds, but times out immediately after
> ---
>
> Key: MYNEWT-526
> URL: https://issues.apache.org/jira/browse/MYNEWT-526
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>Affects Versions: v1_0_0_beta1
> Environment: macos sierra, gcc version 5.4.1 20160919
>Reporter: Jacob
>Assignee: Łukasz Rymanowski
>
> Modification of blecent, connecting and subscribing to my polar HRM.
> My monitor (consistently) connects and subscribes and gets notifications for 
> like 30 seconds before it does a successful gap params update, and then 
> promptly times out.
> I havent confirmed this yet but grammar wise you do seem to be mixing terms, 
> timeout_multiplier and supervision_timeout are separate things in the spec
> l2cap_params->timeout_multiplier = params->supervision_timeout; 
> Perhaps the timeout_multiplier should be multiplied by 10ms to get the 
> supervision_timeout?
> 3924:[ts=30656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 3926:[ts=30671832ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=4
> 3928:[ts=30687456ssb, mod=64 level=1] 0x16:0x00:0xee:0x02
> 3929:[ts=30695268ssb, mod=64 level=1] pkthdr_len=16; om_len=4  
> ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=13 data=0x09 0x00 0x04 0x00 
> 0x1b 0x11 0x00 0x16 0x55 0xda 0x02 0xc9 0x02 
> 4052:[ts=31656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 4054:[ts=31671832ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=6
> 4056:[ts=31687456ssb, mod=64 level=1] 0x16:0x55:0xda:0x02:0xc9:0x02
> 4057:[ts=31695268ssb, mod=64 level=1] pkthdr_len=16; om_len=6  
> ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=16 data=0x0c 0x00 0x05 0x00 
> 0x12 0x01 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
> 4148:[ts=32406224ssb, mod=4 level=0] L2CAP - rxed signalling msg: 0x12 0x01 
> 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
> 4151:[ts=32429660ssb, mod=4 level=1] GAP procedure initiated: connection 
> parameter update; conn_handle=1 itvl_min=250 itvl_max=400 latency=1 
> supervision_timeout=600 min_ce_len=16 max_ce_len
> 4156:[ts=32468720ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x13 
> len=14
> 4158:[ts=32484344ssb, mod=4 level=0] 0x13 0x20 0x0e 0x01 0x00 0xfa 0x00 0x90 
> 0x01 0x01 0x00 0x58 0x02 0x10 0x00 0x00 0x03 
> 4159:[ts=32492156ssb, mod=4 level=0] Command Status: status=0 cmd_pkts=1 
> ocf=0x13 ogf=0x8
> 4162:[ts=32515592ssb, mod=4 level=0] host tx hci data; handle=1 length=10
> 4163:[ts=32523404ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0a 0x00 
> 0x06 0x00 0x05 0x00 0x13 0x01 0x02 0x00 0x00 0x00 
> 4171:[ts=32585900ssb, mod=4 level=0] Number of Completed Packets: 
> num_handles=1
> 4173:[ts=32601524ssb, mod=4 level=0] handle:1 pkts:1
> 4178:[ts=32640584ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1 
> pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x56 0xc0 0x02 
> 4181:[ts=32664020ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 4183:[ts=32679644ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=4
> 4185:[ts=32695268ssb, mod=64 level=1] 0x16:0x56:0xc0:0x02
> 4186:[ts=32703080ssb, mod=64 level=1] pkthdr_len=16; om_len=4  LE Connection 
> Update Complete. handle=1 itvl=400 latency=1 timeout=600
> 4978:[ts=38890568ssb, mod=4 level=0] Disconnection Complete: status=0 
> handle=1 reason=8
> 4980:[ts=38906192ssb, mod=64 level=1] disconnect; reason=520 handle=1 
> our_ota_addr_type=0 our_ota_addr=0c:0c:0c:0c:0c:0c our_id_addr_type=0 
> our_id_addr=0c:0c:0c:0c:0c:0c peer_ota_addr_type=0 
> peer_ota_addr=00:22:d0:2a:e4:a3 peer_id_addr_type=0 
> peer_id_addr=00:22:d0:2a:e4:a3 conn_itvl=400 conn_latency=1 
> supervision_timeout=600 encrypted=0 authenticated=0 bonded=0
> 4988:[ts=38968688ssb, mod=4 level=1] GAP procedure initiated: discovery; 
> own_addr_type=0 filter_policy=0 passive=1 limited=0 filter_duplicates=1 
> duration=forever



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYNEWT-526) Gap params update succeeds, but times out immediately after

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-526:
--

1. Ive seen this on both a tinyble and a pca1 dongle, so different boards, 
but largely the same chip (qfaa nrf51)

2. from the DIS reporting
2a24 h7
2a25 1312150781
2a26 1.1a
2a27 39044024.04
2a28 h7 1.1.0

3. Monitor works great on ios and android. I sent a log over email again as Im 
not sure how to attach here.

3(sic) Tried this but disconnects in what looks like the exact same fashion.I 
cant catch a connect on my logger atm.. But here are the newt logs:

3944:[ts=30812448ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=16 data=0x0c 0x00 0x05 0x00 0x12 0x54 0x08 0x00 0xfa 
0x00 0x90 0x01 0x01 0x00 0x58 0x02 
3948:[ts=30843696ssb, mod=4 level=0] L2CAP - rxed signalling msg: 0x12 0x54 
0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
3950:[ts=30859320ssb, mod=4 level=1] GAP procedure initiated: connection 
parameter update; conn_handle=1 itvl_min=250 itvl_max=400 latency=0 
supervision_timeout=600 min_ce_len=16 max_ce_len
3955:[ts=30898380ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x0013 
len=14
3957:[ts=30914004ssb, mod=4 level=0] 0x13 0x20 0x0e 0x01 0x00 0xfa 0x00 0x90 
0x01 0x00 0x00 0x58 0x02 0x10 0x00 0x00 0x03 
3958:[ts=30921816ssb, mod=4 level=0] Command Status: status=0 cmd_pkts=1 
ocf=0x13 ogf=0x8
3960:[ts=30937440ssb, mod=4 level=0] host tx hci data; handle=1 length=10
3961:[ts=30945252ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0a 0x00 
0x06 0x00 0x05 0x00 0x13 0x54 0x02 0x00 0x00 0x00 
3963:[ts=30960876ssb, mod=4 level=0] Number of Completed Packets: num_handles=1
3965:[ts=30976500ssb, mod=4 level=0] handle:1 pkts:1
4008:[ts=31312480ssb, mod=4 level=0] LE Connection Update Complete. handle=1 
itvl=400 latency=0 timeout=600
4776:[ts=37312480ssb, mod=4 level=0] Disconnection Complete: status=0 handle=1 
reason=8
4779:[ts=37335916ssb, mod=64 level=1] disconnect; reason=520 handle=1 
our_ota_addr_type=0 our_ota_addr=0a:0a:0a:0a:0a:0a our_id_addr_type=0 
our_id_addr=0a:0a:0a:0a:0a:0a peer_ota_addr_type=0 
peer_ota_addr=00:22:d0:2a:e4:a3 peer_id_addr_type=0 
peer_id_addr=00:22:d0:2a:e4:a3 conn_itvl=400 conn_latency=0 
supervision_timeout=600 encrypted=0 authenticated=0 bonded=0

> Gap params update succeeds, but times out immediately after
> ---
>
> Key: MYNEWT-526
> URL: https://issues.apache.org/jira/browse/MYNEWT-526
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>Affects Versions: v1_0_0_beta1
> Environment: macos sierra, gcc version 5.4.1 20160919
>Reporter: Jacob
>Assignee: Łukasz Rymanowski
>
> Modification of blecent, connecting and subscribing to my polar HRM.
> My monitor (consistently) connects and subscribes and gets notifications for 
> like 30 seconds before it does a successful gap params update, and then 
> promptly times out.
> I havent confirmed this yet but grammar wise you do seem to be mixing terms, 
> timeout_multiplier and supervision_timeout are separate things in the spec
> l2cap_params->timeout_multiplier = params->supervision_timeout; 
> Perhaps the timeout_multiplier should be multiplied by 10ms to get the 
> supervision_timeout?
> 3924:[ts=30656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 3926:[ts=30671832ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=4
> 3928:[ts=30687456ssb, mod=64 level=1] 0x16:0x00:0xee:0x02
> 3929:[ts=30695268ssb, mod=64 level=1] pkthdr_len=16; om_len=4  
> ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=13 data=0x09 0x00 0x04 0x00 
> 0x1b 0x11 0x00 0x16 0x55 0xda 0x02 0xc9 0x02 
> 4052:[ts=31656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 4054:[ts=31671832ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=6
> 4056:[ts=31687456ssb, mod=64 level=1] 0x16:0x55:0xda:0x02:0xc9:0x02
> 4057:[ts=31695268ssb, mod=64 level=1] pkthdr_len=16; om_len=6  
> ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=16 data=0x0c 0x00 0x05 0x00 
> 0x12 0x01 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
> 4148:[ts=32406224ssb, mod=4 level=0] L2CAP - rxed signalling msg: 0x12 0x01 
> 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
> 4151:[ts=32429660ssb, mod=4 level=1] GAP procedure initiated: connection 
> parameter update; conn_handle=1 itvl_min=250 itvl_max=400 latency=1 
> supervision_timeout=600 min_ce_len=16 max_ce_len
> 4156:[ts=32468720ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x13 
> len=14
> 4158:[ts=32484344ssb, mod=4 level=0] 0x13 0x20 0x0e 0x01 0x00 0xfa 0x00 0x90 
> 0x01 0x01 0x00 0x58 0x02 0x10 0x00 0x00 0x03 
> 4159:[ts=32492156ssb, mod=4 level=0] Command Status: status=0 

[jira] [Commented] (MYNEWT-526) Gap params update succeeds, but times out immediately after

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-526:
--

OK. TLDR I still think theres some bad math in here.


OK. so the output has been looking different with the recent changes to the 
stack around here.

As I said above, I get error code now? 571 or 59 on top of HCI error (512)? Not 
sure whats up with that, but Łukasz asked me to wireshark

I have some wireshark pcap if you like, but it shows Connection Parameter 
Update Response Rejected

wireshark says requested
min interval 250 (312.5msec)
max interval 400 (500msec)
latency 1ll connection event
multiplier 600 (6sec)


Hard to tell with optimizations on, but were being thrown out of 
ble_gap_validate_conn_params
here
if (params->supervision_timeout <=
   (((1 + params->latency) * params->itvl_max) * 6 / 4)) {
return false;
}


(gdb) set $foo = (((1 + params->latency) * params->itvl_max) * 6 / 4)
(gdb) p $foo
$3 = 1200
(gdb) set $foo2 = params->supervision_timeout <= (((1 + params->latency) * 
params->itvl_max) * 6 / 4)
(gdb) p $foo2
$4 = 1

and 600 is indeed <= 1200

can I confirm that the min is 1200?


"The Supervision_Timeout parameter shall define the link supervision timeout
for the LE link. The Supervision_Timeout in milliseconds shall be larger than (1
+ Conn_Latency) * Conn_Interval_Max * 2, where Conn_Interval_Max is given
in milliseconds. ""


were definitely mixing ms and intervals in this calculation



timeout_MS >= (1 + Conn_Latency) * Conn_Interval_Max_MS * 2
6000 >= 2 * 500 * 2
6000 >= 2000

so left should be  * 10 so right should be /10

timeout >= (1 + Conn_Latency) * Conn_Interval_Max_MS * 2 /100

and Conn_Interval_Max_MS =  conn_interval * 1.25

timeout >= (1 + Conn_Latency) * conn_interval * 1.25 * 2 /10

timeout >= (1 + Conn_Latency) * conn_interval / 4


600  >=  (1 + 1) * 400 / 4
600  >=  200

ratios work out

so should be
if (params->supervision_timeout <=
   (((1 + params->latency) * params->itvl_max) / 4)) {
return false;
}


When implemented, we do pass validation and receive the LE Connection Update 
Complete before it fails again with reason 520, which is what it was failing 
with when I originally reported this


5832:[ts=45562464ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=16 data=0x0c 0x00 0x05 0x00 0x12 0x02 0x08 0x00 0xfa 
0x00 0x90 0x01 0x01 0x00 0x58 0x02 
5836:[ts=45593712ssb, mod=4 level=0] L2CAP - rxed signalling msg: 0x12 0x02 
0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
5838:[ts=45609336ssb, mod=4 level=1] GAP procedure initiated: connection 
parameter update; conn_handle=1 itvl_min=250 itvl_max=400 latency=1 
supervision_timeout=600 min_ce_len=16 max_ce_len
5843:[ts=45648396ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x0013 
len=14
5845:[ts=45664020ssb, mod=4 level=0] 0x13 0x20 0x0e 0x01 0x00 0xfa 0x00 0x90 
0x01 0x01 0x00 0x58 0x02 0x10 0x00 0x00 0x03 
5846:[ts=45671832ssb, mod=4 level=0] Command Status: status=0 cmd_pkts=1 
ocf=0x13 ogf=0x8
5848:[ts=45687456ssb, mod=4 level=0] host tx hci data; handle=1 length=10
5849:[ts=45695268ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0a 0x00 
0x06 0x00 0x05 0x00 0x13 0x02 0x02 0x00 0x00 0x00 
5851:[ts=45710892ssb, mod=4 level=0] Number of Completed Packets: num_handles=1
5853:[ts=45726516ssb, mod=4 level=0] handle:1 pkts:1
5896:[ts=46062496ssb, mod=4 level=0] LE Connection Update Complete. handle=1 
itvl=400 latency=1 timeout=600
6664:[ts=52062496ssb, mod=4 level=0] Disconnection Complete: status=0 handle=1 
reason=8
6667:[ts=52085932ssb, mod=64 level=1] disconnect; reason=520 handle=1 
our_ota_addr_type=0 our_ota_addr=0a:0a:0a:0a:0a:0a our_id_addr_type=0 
our_id_addr=0a:0a:0a:0a:0a:0a peer_ota_addr_type=0 
peer_ota_addr=00:22:d0:2a:e4:a3 peer_id_addr_type=0 
peer_id_addr=00:22:d0:2a:e4:a3 conn_itvl=400 conn_latency=1 
supervision_timeout=600 encrypted=0 authenticated=0 bonded=0

I havent dug further yet, but I still think theres more bad math around timeouts

> Gap params update succeeds, but times out immediately after
> ---
>
> Key: MYNEWT-526
> URL: https://issues.apache.org/jira/browse/MYNEWT-526
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>Affects Versions: v1_0_0_beta1
> Environment: macos sierra, gcc version 5.4.1 20160919
>Reporter: Jacob
>Assignee: Łukasz Rymanowski
>
> Modification of blecent, connecting and subscribing to my polar HRM.
> My monitor (consistently) connects and subscribes and gets notifications for 
> like 30 seconds before it does a successful gap params update, and then 
> promptly times out.
> I havent confirmed this yet but grammar wise you do seem to be mixing terms, 
> timeout_multiplier 

[jira] [Resolved] (MYNEWT-634) blecent ble_gap_connect failing with rc 21

[Jacob (JIRA)]

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

Jacob resolved MYNEWT-634.
--
Resolution: Fixed

Fixed in https://github.com/apache/incubator-mynewt-core/pull/187

> blecent ble_gap_connect failing with rc 21
> --
>
> Key: MYNEWT-634
> URL: https://issues.apache.org/jira/browse/MYNEWT-634
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>Affects Versions: v1_0_0_beta2
>Reporter: Jacob
>Assignee: Szymon Janc
> Fix For: v1_0_0_rel
>
>
> blecent ble_gap_connect used to work with my heartrate device but is now 
> failing with rc 21
> Tracked back to  ble_hs_id_addr
>│156 if (memcmp(id_addr, ble_hs_misc_null_addr, 6) == 0) {
>│157 return BLE_HS_ENOADDR;
>│158 }
> (gdb) p id_addr_type
> $8 = 0 '\000'
> (gdb) p ble_hs_id_pub
> $9 = "\000\000\000\000\000"
> (gdb) p ble_hs_misc_null_addr
> $3 = "\000\000\000\000\000"
> (gdb) p *id_addr
> $5 = 0 '\000'
> (gdb) set $foo = memcmp(id_addr, ble_hs_misc_null_addr, 6)
> (gdb) p $foo
> $6 = 0
> There was some recent address changes I dont currently understand, maybe that 
> has to do with it?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYNEWT-572) newtmgr reset command succeeds under the hood, yet fails to recover

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-572:
--

This was indeed this issue!

> newtmgr reset command succeeds under the hood, yet fails to recover
> ---
>
> Key: MYNEWT-572
> URL: https://issues.apache.org/jira/browse/MYNEWT-572
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
> Environment: develop branch
> macos
> nrf51-16kbram target
>Reporter: Jacob
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The reset after image confirm is successful, but newtmgr is having trouble 
> recovering from the command:
> Ive seen it error like this:
> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr reset -cserial1 
> -t -ldebug
> 2017/01/25 17:13:31 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:2 
> Group:0 Seq:0 Id:5 Data:[123 125]}
> 2017/01/25 17:13:31 [DEBUG] Serializing request &{Op:2 Flags:0 Len:2 Group:0 
> Seq:0 Id:5 Data:[123 125]} into buffer [2 0 0 2 0 0 0 5 123 125]
> 2017/01/25 17:13:31 [DEBUG] Tx packet dump:
>   02 00 00 02 00 00 00 05  7b 7d|{}|
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   06 09 |..|
> 2017/01/25 17:13:31 [DEBUG] Writing [6 9] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   41 41 77 43 41 41 41 43  41 41 41 41 42 58 74 39  |AAwCAAACBXt9|
> 0010  4c 67 41 3d   |LgA=|
> 2017/01/25 17:13:31 [DEBUG] Writing [65 65 119 67 65 65 65 67 65 65 65 65 66 
> 88 116 57 76 103 65 61] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   0a|.|
> 2017/01/25 17:13:31 [DEBUG] Writing [10] to data channel
> 2017/01/25 17:13:44 [INFO] Incoming:
>   06 09 41 41 77 43 41 41  41 43 41 41 41 41 42 58  |..AAwCAAACBX|
> 0010  74 39 4c 67 41 3d 31 3a   |t9LgA=1:|
> 2017/01/25 17:13:44 [DEBUG] Reading [6 9 65 65 119 67 65 65 65 67 65 65 65 65 
> 66 88 116 57 76 103 65 61 49 58] from data channel
> 2017/01/25 17:13:44 [INFO] Message: base64 decode error
> 2017/01/25 17:13:44 [DEBUG] goroutine 1 [running]:
> mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util.NewNewtError(0xc420160380,
>  0xdd, 0xc42004bb50)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util/util.go:75
>  +0x111
> mynewt.apache.org/newt/newtmgr/transport.(*ConnSerial).ReadPacket(0xc420140870,
>  0xc420146c00, 0x4080a8a, 0xc420140870)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/transport/connserial.go:149
>  +0x7b2
> mynewt.apache.org/newt/newtmgr/protocol.(*CmdRunner).ReadResp(0xc42015f210, 
> 0xc4201468c0, 0x0, 0x0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/protocol/cmdrunner.go:42
>  +0x9c
> mynewt.apache.org/newt/newtmgr/cli.resetRunCmd(0xc42016c240, 0xc420140630, 
> 0x0, 0x3)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/cli/reset.go:50
>  +0x1ab
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).execute(0xc42016c240,
>  0xc420140480, 0x3, 0x3, 0xc42016c240, 0xc420140480)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:636
>  +0x443
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420166000,
>  0xc420166b40, 0xc420166240, 0xc42015eec0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:722
>  +0x367
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420166000,
>  0x40d65bc, 0xc421a0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:681
>  +0x2b
> main.main()
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/newtmgr.go:25 
> +0x2f
> goroutine 17 [syscall, locked to thread]:
> runtime.goexit()
>   /usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/asm_amd64.s:2086 +0x1
> goroutine 5 [syscall]:
> os/signal.signal_recv(0x0)
>   /usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/sigqueue.go:116 +0x157
> os/signal.loop()
>   /usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:22 
> +0x22
> created by os/signal.init.1
>   /usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:28 
> +0x41
> Error: Couldn't decode base64 string: AAwCAAACBXt9LgA=1:
> Packet hex dump:
>   06 09 41 41 77 43 41 41  41 43 41 41 41 41 42 58  |..AAwCAAACBX|
> 0010  74 39 4c 67 41 3d 31 3a   

[jira] [Commented] (MYNEWT-572) newtmgr reset command succeeds under the hood, yet fails to recover

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-572:
--

Im still getting this..Im only tested with the nmgr_shell. Blesplit and 
bleprph, config below.

Actually also happens on newtmgr image list. It turns out it only happens after 
a newtmgr image test command I believe.



### Package: targets/split-nrf51dk
pkg.name: "targets/split-nrf51dk"
pkg.type: "target"
pkg.description: 
pkg.author: 
pkg.homepage: 

pkg.deps: 
 - "@apache-mynewt-core/mgmt/newtmgr/transport/nmgr_shell"



### Package: targets/split-nrf51dk

syscfg.vals:

SHELL_TASK: 1 #needed for nmgr_shell

#space and ram savings
BLE_LL_CFG_FEAT_LE_ENCRYPTION: 0
BLE_SM_LEGACY: 0
MSYS_1_BLOCK_COUNT: 8 #12
MSYS_1_BLOCK_SIZE: 76 #292 # 76 lowest, 80 for multi-adv
BLE_LL_NUM_SCAN_DUP_ADVS: 0 #8 tested safe
BLE_LL_NUM_SCAN_RSP_ADVS: 0 #8 tested safe
BLE_LL_WHITELIST_SIZE: 0 #8
BLE_LL_RESOLV_LIST_SIZE: 0 #4


### Target: targets/split-nrf51dk
target.app: "@apache-mynewt-core/apps/blesplit"
target.bsp: "@apache-mynewt-core/hw/bsp/nrf51dk-16kbram"
target.build_profile: "optimized"
target.loader: "@apache-mynewt-core/apps/bleprph"


> newtmgr reset command succeeds under the hood, yet fails to recover
> ---
>
> Key: MYNEWT-572
> URL: https://issues.apache.org/jira/browse/MYNEWT-572
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
> Environment: develop branch
> macos
> nrf51-16kbram target
>Reporter: Jacob
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The reset after image confirm is successful, but newtmgr is having trouble 
> recovering from the command:
> Ive seen it error like this:
> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr reset -cserial1 
> -t -ldebug
> 2017/01/25 17:13:31 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:2 
> Group:0 Seq:0 Id:5 Data:[123 125]}
> 2017/01/25 17:13:31 [DEBUG] Serializing request &{Op:2 Flags:0 Len:2 Group:0 
> Seq:0 Id:5 Data:[123 125]} into buffer [2 0 0 2 0 0 0 5 123 125]
> 2017/01/25 17:13:31 [DEBUG] Tx packet dump:
>   02 00 00 02 00 00 00 05  7b 7d|{}|
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   06 09 |..|
> 2017/01/25 17:13:31 [DEBUG] Writing [6 9] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   41 41 77 43 41 41 41 43  41 41 41 41 42 58 74 39  |AAwCAAACBXt9|
> 0010  4c 67 41 3d   |LgA=|
> 2017/01/25 17:13:31 [DEBUG] Writing [65 65 119 67 65 65 65 67 65 65 65 65 66 
> 88 116 57 76 103 65 61] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   0a|.|
> 2017/01/25 17:13:31 [DEBUG] Writing [10] to data channel
> 2017/01/25 17:13:44 [INFO] Incoming:
>   06 09 41 41 77 43 41 41  41 43 41 41 41 41 42 58  |..AAwCAAACBX|
> 0010  74 39 4c 67 41 3d 31 3a   |t9LgA=1:|
> 2017/01/25 17:13:44 [DEBUG] Reading [6 9 65 65 119 67 65 65 65 67 65 65 65 65 
> 66 88 116 57 76 103 65 61 49 58] from data channel
> 2017/01/25 17:13:44 [INFO] Message: base64 decode error
> 2017/01/25 17:13:44 [DEBUG] goroutine 1 [running]:
> mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util.NewNewtError(0xc420160380,
>  0xdd, 0xc42004bb50)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util/util.go:75
>  +0x111
> mynewt.apache.org/newt/newtmgr/transport.(*ConnSerial).ReadPacket(0xc420140870,
>  0xc420146c00, 0x4080a8a, 0xc420140870)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/transport/connserial.go:149
>  +0x7b2
> mynewt.apache.org/newt/newtmgr/protocol.(*CmdRunner).ReadResp(0xc42015f210, 
> 0xc4201468c0, 0x0, 0x0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/protocol/cmdrunner.go:42
>  +0x9c
> mynewt.apache.org/newt/newtmgr/cli.resetRunCmd(0xc42016c240, 0xc420140630, 
> 0x0, 0x3)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/cli/reset.go:50
>  +0x1ab
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).execute(0xc42016c240,
>  0xc420140480, 0x3, 0x3, 0xc42016c240, 0xc420140480)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:636
>  +0x443
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420166000,
>  0xc420166b40, 0xc420166240, 0xc42015eec0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:722
>  +0x367
> 

[jira] [Commented] (MYNEWT-634) blecent ble_gap_connect failing with rc 21

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-634:
--

Confirm this fixes

> blecent ble_gap_connect failing with rc 21
> --
>
> Key: MYNEWT-634
> URL: https://issues.apache.org/jira/browse/MYNEWT-634
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>Affects Versions: v1_0_0_beta2
>Reporter: Jacob
>Assignee: Szymon Janc
> Fix For: v1_0_0_rel
>
>
> blecent ble_gap_connect used to work with my heartrate device but is now 
> failing with rc 21
> Tracked back to  ble_hs_id_addr
>│156 if (memcmp(id_addr, ble_hs_misc_null_addr, 6) == 0) {
>│157 return BLE_HS_ENOADDR;
>│158 }
> (gdb) p id_addr_type
> $8 = 0 '\000'
> (gdb) p ble_hs_id_pub
> $9 = "\000\000\000\000\000"
> (gdb) p ble_hs_misc_null_addr
> $3 = "\000\000\000\000\000"
> (gdb) p *id_addr
> $5 = 0 '\000'
> (gdb) set $foo = memcmp(id_addr, ble_hs_misc_null_addr, 6)
> (gdb) p $foo
> $6 = 0
> There was some recent address changes I dont currently understand, maybe that 
> has to do with it?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYNEWT-526) Gap params update succeeds, but times out immediately after

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-526:
--

Yes I can confirm it still disconnects. It happens every time, after about 30 
seconds of being connected, presumably after attempting to update something 
about the connection.

Though I get a different error code now? 571 or 59 on top of HCI error (512)?
```
6518:[ts=50921816ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x41 
0xbd 0x03 
6522:[ts=50953064ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
6524:[ts=50968688ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=4
6526:[ts=50984312ssb, mod=64 level=1] sensor_contact=1

6527:[ts=50992124ssb, mod=64 level=1] measurement=65

6528:[ts=5100ssb, mod=64 level=1] rr=189

6557:[ts=51226548ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=16 data=0x0c 0x00 0x05 0x00 0x12 0x0f 0x08 0x00 0xfa 
0x00 0x90 0x01 0x01 0x00 0x58 0x02 
6560:[ts=51249984ssb, mod=4 level=0] L2CAP - rxed signalling msg: 0x12 0x0f 
0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
6562:[ts=51265608ssb, mod=4 level=0] host tx hci data; handle=1 length=10
6563:[ts=51273420ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0a 0x00 
0x06 0x00 0x05 0x00 0x13 0x0f 0x02 0x00 0x01 0x00 
6569:[ts=51320292ssb, mod=4 level=0] Number of Completed Packets: num_handles=1
6571:[ts=51335916ssb, mod=4 level=0] handle:1 pkts:1
6646:[ts=51921816ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x3f 
0xd8 0x03 
6650:[ts=51953064ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
6652:[ts=51968688ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=4
6654:[ts=51984312ssb, mod=64 level=1] sensor_contact=1

6655:[ts=51992124ssb, mod=64 level=1] measurement=63

6656:[ts=5200ssb, mod=64 level=1] rr=216

6774:[ts=52921816ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x41 
0xa0 0x03 
6778:[ts=52953064ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
6780:[ts=52968688ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=4
6782:[ts=52984312ssb, mod=64 level=1] sensor_contact=1

6783:[ts=52992124ssb, mod=64 level=1] measurement=65

6784:[ts=5300ssb, mod=64 level=1] rr=160

6902:[ts=53921816ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x41 
0xa9 0x03 
6906:[ts=53953064ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
6908:[ts=53968688ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=4
6910:[ts=53984312ssb, mod=64 level=1] sensor_contact=1

6911:[ts=53992124ssb, mod=64 level=1] measurement=65

6912:[ts=5400ssb, mod=64 level=1] rr=169

7030:[ts=54921816ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x3f 
0x00 0x04 
7034:[ts=54953064ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
7036:[ts=54968688ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=4
7038:[ts=54984312ssb, mod=64 level=1] sensor_contact=1

7039:[ts=54992124ssb, mod=64 level=1] measurement=63

7040:[ts=5500ssb, mod=64 level=1] rr=0

7158:[ts=55921816ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x3c 
0x22 0x04 
7162:[ts=55953064ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
7164:[ts=55968688ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=4
7166:[ts=55984312ssb, mod=64 level=1] sensor_contact=1

7167:[ts=55992124ssb, mod=64 level=1] measurement=60

7168:[ts=5600ssb, mod=64 level=1] rr=34

7286:[ts=56921816ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x3e 
0xd3 0x03 
7290:[ts=56953064ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
7292:[ts=56968688ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=4
7294:[ts=56984312ssb, mod=64 level=1] sensor_contact=1

7295:[ts=56992124ssb, mod=64 level=1] measurement=62

7296:[ts=5700ssb, mod=64 level=1] rr=211

7414:[ts=57921816ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x3e 
0xda 0x03 
7418:[ts=57953064ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
7420:[ts=57968688ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=4

[jira] [Created] (MYNEWT-634) blecent ble_gap_connect failing with rc 21

[Jacob (JIRA)]

Jacob created MYNEWT-634:


 Summary: blecent ble_gap_connect failing with rc 21
 Key: MYNEWT-634
 URL: https://issues.apache.org/jira/browse/MYNEWT-634
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Affects Versions: v1_0_0_beta2
Reporter: Jacob


blecent ble_gap_connect used to work with my heartrate device but is now 
failing with rc 21

Tracked back to  ble_hs_id_addr
   │156 if (memcmp(id_addr, ble_hs_misc_null_addr, 6) == 0) {
   │157 return BLE_HS_ENOADDR;
   │158 }

(gdb) p id_addr_type
$8 = 0 '\000'
(gdb) p ble_hs_id_pub
$9 = "\000\000\000\000\000"
(gdb) p ble_hs_misc_null_addr
$3 = "\000\000\000\000\000"
(gdb) p *id_addr
$5 = 0 '\000'
(gdb) set $foo = memcmp(id_addr, ble_hs_misc_null_addr, 6)
(gdb) p $foo
$6 = 0

There was some recent address changes I dont currently understand, maybe that 
has to do with it?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYNEWT-526) Gap params update succeeds, but times out immediately after

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-526:
--

I havent tested, but i just saw a246f526267bc81199e57a22535b5d3f0173a660 come 
across that might address this? [~rymanluk]

> Gap params update succeeds, but times out immediately after
> ---
>
> Key: MYNEWT-526
> URL: https://issues.apache.org/jira/browse/MYNEWT-526
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>Affects Versions: v1_0_0_beta1
> Environment: macos sierra, gcc version 5.4.1 20160919
>Reporter: Jacob
>
> Modification of blecent, connecting and subscribing to my polar HRM.
> My monitor (consistently) connects and subscribes and gets notifications for 
> like 30 seconds before it does a successful gap params update, and then 
> promptly times out.
> I havent confirmed this yet but grammar wise you do seem to be mixing terms, 
> timeout_multiplier and supervision_timeout are separate things in the spec
> l2cap_params->timeout_multiplier = params->supervision_timeout; 
> Perhaps the timeout_multiplier should be multiplied by 10ms to get the 
> supervision_timeout?
> 3924:[ts=30656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 3926:[ts=30671832ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=4
> 3928:[ts=30687456ssb, mod=64 level=1] 0x16:0x00:0xee:0x02
> 3929:[ts=30695268ssb, mod=64 level=1] pkthdr_len=16; om_len=4  
> ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=13 data=0x09 0x00 0x04 0x00 
> 0x1b 0x11 0x00 0x16 0x55 0xda 0x02 0xc9 0x02 
> 4052:[ts=31656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 4054:[ts=31671832ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=6
> 4056:[ts=31687456ssb, mod=64 level=1] 0x16:0x55:0xda:0x02:0xc9:0x02
> 4057:[ts=31695268ssb, mod=64 level=1] pkthdr_len=16; om_len=6  
> ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=16 data=0x0c 0x00 0x05 0x00 
> 0x12 0x01 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
> 4148:[ts=32406224ssb, mod=4 level=0] L2CAP - rxed signalling msg: 0x12 0x01 
> 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
> 4151:[ts=32429660ssb, mod=4 level=1] GAP procedure initiated: connection 
> parameter update; conn_handle=1 itvl_min=250 itvl_max=400 latency=1 
> supervision_timeout=600 min_ce_len=16 max_ce_len
> 4156:[ts=32468720ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x13 
> len=14
> 4158:[ts=32484344ssb, mod=4 level=0] 0x13 0x20 0x0e 0x01 0x00 0xfa 0x00 0x90 
> 0x01 0x01 0x00 0x58 0x02 0x10 0x00 0x00 0x03 
> 4159:[ts=32492156ssb, mod=4 level=0] Command Status: status=0 cmd_pkts=1 
> ocf=0x13 ogf=0x8
> 4162:[ts=32515592ssb, mod=4 level=0] host tx hci data; handle=1 length=10
> 4163:[ts=32523404ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0a 0x00 
> 0x06 0x00 0x05 0x00 0x13 0x01 0x02 0x00 0x00 0x00 
> 4171:[ts=32585900ssb, mod=4 level=0] Number of Completed Packets: 
> num_handles=1
> 4173:[ts=32601524ssb, mod=4 level=0] handle:1 pkts:1
> 4178:[ts=32640584ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1 
> pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x56 0xc0 0x02 
> 4181:[ts=32664020ssb, mod=4 level=0] rxed att command: notify req; conn=1 
> handle=0x0011
> 4183:[ts=32679644ssb, mod=64 level=1] received notification; conn_handle=1 
> attr_handle=17 attr_len=4
> 4185:[ts=32695268ssb, mod=64 level=1] 0x16:0x56:0xc0:0x02
> 4186:[ts=32703080ssb, mod=64 level=1] pkthdr_len=16; om_len=4  LE Connection 
> Update Complete. handle=1 itvl=400 latency=1 timeout=600
> 4978:[ts=38890568ssb, mod=4 level=0] Disconnection Complete: status=0 
> handle=1 reason=8
> 4980:[ts=38906192ssb, mod=64 level=1] disconnect; reason=520 handle=1 
> our_ota_addr_type=0 our_ota_addr=0c:0c:0c:0c:0c:0c our_id_addr_type=0 
> our_id_addr=0c:0c:0c:0c:0c:0c peer_ota_addr_type=0 
> peer_ota_addr=00:22:d0:2a:e4:a3 peer_id_addr_type=0 
> peer_id_addr=00:22:d0:2a:e4:a3 conn_itvl=400 conn_latency=1 
> supervision_timeout=600 encrypted=0 authenticated=0 bonded=0
> 4988:[ts=38968688ssb, mod=4 level=1] GAP procedure initiated: discovery; 
> own_addr_type=0 filter_policy=0 passive=1 limited=0 filter_duplicates=1 
> duration=forever



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYNEWT-570) Enabling newtmgr uart transport introduces compile errors

[Jacob (JIRA)]

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

Jacob commented on MYNEWT-570:
--

I also believe this has an unlisted dependency on util/crc

On Fri, Jan 27, 2017 at 12:13 PM, Marko Kiiskila (JIRA) 



> Enabling newtmgr uart transport introduces compile errors
> -
>
> Key: MYNEWT-570
> URL: https://issues.apache.org/jira/browse/MYNEWT-570
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
>Affects Versions: v1_0_0_beta1
>Reporter: Jacob
>Assignee: Marko Kiiskila
>
> - "@apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart"
> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newt run split-nrf51dk 0
> .
> Error: 
> repos/apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c: In 
> function 'nmgr_uart_out':
> repos/apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c:114:13:
>  error: dereferencing type-punned pointer will break strict-aliasing rules 
> [-Werror=strict-aliasing]
>  *(uint16_t *)tmp_buf = htons(mpkt->omp_len);
>  ^
> repos/apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c: In 
> function 'nmgr_uart_rx_char':
> repos/apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c:330:23:
>  error: 'g_mgmt_evq' undeclared (first use in this function)
>  os_eventq_put(g_mgmt_evq, >nus_cb_ev);
>^
> repos/apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c:330:23:
>  note: each undeclared identifier is reported only once for each function it 
> appears in
> cc1: all warnings being treated as errors



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-572) newtmgr reset command succeeds under the hood, yet fails to recover

[Jacob (JIRA)]

Jacob created MYNEWT-572:


 Summary: newtmgr reset command succeeds under the hood, yet fails 
to recover
 Key: MYNEWT-572
 URL: https://issues.apache.org/jira/browse/MYNEWT-572
 Project: Mynewt
  Issue Type: Bug
  Components: Newtmgr
 Environment: develop branch
macos
nrf51-16kbram target
Reporter: Jacob
Assignee: Sterling Hughes


The reset after image confirm is successful, but newtmgr is having trouble 
recovering from the command:

Ive seen it error like this:
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr reset -cserial1 
-t -ldebug
2017/01/25 17:13:31 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:2 
Group:0 Seq:0 Id:5 Data:[123 125]}
2017/01/25 17:13:31 [DEBUG] Serializing request &{Op:2 Flags:0 Len:2 Group:0 
Seq:0 Id:5 Data:[123 125]} into buffer [2 0 0 2 0 0 0 5 123 125]
2017/01/25 17:13:31 [DEBUG] Tx packet dump:
  02 00 00 02 00 00 00 05  7b 7d|{}|

2017/01/25 17:13:31 [INFO] Outgoing:
  06 09 |..|

2017/01/25 17:13:31 [DEBUG] Writing [6 9] to data channel
2017/01/25 17:13:31 [INFO] Outgoing:
  41 41 77 43 41 41 41 43  41 41 41 41 42 58 74 39  |AAwCAAACBXt9|
0010  4c 67 41 3d   |LgA=|

2017/01/25 17:13:31 [DEBUG] Writing [65 65 119 67 65 65 65 67 65 65 65 65 66 88 
116 57 76 103 65 61] to data channel
2017/01/25 17:13:31 [INFO] Outgoing:
  0a|.|

2017/01/25 17:13:31 [DEBUG] Writing [10] to data channel
2017/01/25 17:13:44 [INFO] Incoming:
  06 09 41 41 77 43 41 41  41 43 41 41 41 41 42 58  |..AAwCAAACBX|
0010  74 39 4c 67 41 3d 31 3a   |t9LgA=1:|

2017/01/25 17:13:44 [DEBUG] Reading [6 9 65 65 119 67 65 65 65 67 65 65 65 65 
66 88 116 57 76 103 65 61 49 58] from data channel
2017/01/25 17:13:44 [INFO] Message: base64 decode error


2017/01/25 17:13:44 [DEBUG] goroutine 1 [running]:
mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util.NewNewtError(0xc420160380,
 0xdd, 0xc42004bb50)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util/util.go:75
 +0x111
mynewt.apache.org/newt/newtmgr/transport.(*ConnSerial).ReadPacket(0xc420140870, 
0xc420146c00, 0x4080a8a, 0xc420140870)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/transport/connserial.go:149
 +0x7b2
mynewt.apache.org/newt/newtmgr/protocol.(*CmdRunner).ReadResp(0xc42015f210, 
0xc4201468c0, 0x0, 0x0)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/protocol/cmdrunner.go:42
 +0x9c
mynewt.apache.org/newt/newtmgr/cli.resetRunCmd(0xc42016c240, 0xc420140630, 0x0, 
0x3)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/cli/reset.go:50 
+0x1ab
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).execute(0xc42016c240,
 0xc420140480, 0x3, 0x3, 0xc42016c240, 0xc420140480)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:636
 +0x443
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420166000,
 0xc420166b40, 0xc420166240, 0xc42015eec0)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:722
 +0x367
mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420166000,
 0x40d65bc, 0xc421a0)

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:681
 +0x2b
main.main()

/Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/newtmgr.go:25 
+0x2f

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/asm_amd64.s:2086 +0x1

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
/usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/sigqueue.go:116 +0x157
os/signal.loop()
/usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:22 
+0x22
created by os/signal.init.1
/usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:28 
+0x41

Error: Couldn't decode base64 string: AAwCAAACBXt9LgA=1:
Packet hex dump:
  06 09 41 41 77 43 41 41  41 43 41 41 41 41 42 58  |..AAwCAAACBX|
0010  74 39 4c 67 41 3d 31 3a   |t9LgA=1:|


reset - Send reset request to remote endpoint using newtmgr

Usage:
  newtmgr reset [flags]

Global Flags:
  -c, --conn string   connection profile to use.
  -l, --loglevel string   log level to use (default INFO.) (default "info")
  -t, --trace print all bytes transmitted and received
Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ 

And Ive seen it hang forever:

[jira] [Created] (MYNEWT-571) sys/log/stub is incomplete or doesnt work with deep defines of reboot_log

[Jacob (JIRA)]

Jacob created MYNEWT-571:


 Summary: sys/log/stub is incomplete or doesnt work with deep 
defines of reboot_log
 Key: MYNEWT-571
 URL: https://issues.apache.org/jira/browse/MYNEWT-571
 Project: Mynewt
  Issue Type: Bug
  Components: OS
Reporter: Jacob


Stubbing bleprph for log doesnt compile. I think a few things need to be 
stubbed out yet.

REBOOT_LOG_FCB: 0
LOG_FCB: 0
SHELL_TASK: 1 
STATS_NEWTMGR: 0
STATS_NAMES: 0
CONFIG_NEWTMGR: 0
LOG_NEWTMGR: 0
LOG_CLI: 0
LOG_LEVEL: 255


Error: repos/apache-mynewt-core/sys/reboot/src/log_reboot.c: In function 
'reboot_init_handler':
repos/apache-mynewt-core/sys/reboot/src/log_reboot.c:109:13: error: 
'LOG_STORE_CONSOLE' undeclared (first use in this function)
case LOG_STORE_CONSOLE:
 ^
repos/apache-mynewt-core/sys/reboot/src/log_reboot.c:109:13: note: each 
undeclared identifier is reported only once for each function it appears in
repos/apache-mynewt-core/sys/reboot/src/log_reboot.c: In function 
'log_reboot_pkg_init':
repos/apache-mynewt-core/sys/reboot/src/log_reboot.c:248:12: error: 
'LOG_STORE_CONSOLE' undeclared (first use in this function)
 type = LOG_STORE_CONSOLE;
^



If I add those defines to the stub I run into deeper needs so just reporting 
for now:

Linking 
/Users/jacobrosenthal/Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/app/apps/blesplit/blesplit_tmp.elf
Error: 
/Users/jacobrosenthal/Downloads/mynewt-hr-observer/bin/targets/split-nrf51dk/app/sys/reboot/sys_reboot.a(log_reboot.o):
 In function `reboot_init_handler':
/Users/jacobrosenthal/Downloads/mynewt-hr-observer/repos/apache-mynewt-core/sys/reboot/src/log_reboot.c:125:
 undefined reference to `log_console_handler'
collect2: error: ld returned 1 exit status





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-570) Enabling newtmgr uart transport introduces compile errors

[Jacob (JIRA)]

Jacob created MYNEWT-570:


 Summary: Enabling newtmgr uart transport introduces compile errors
 Key: MYNEWT-570
 URL: https://issues.apache.org/jira/browse/MYNEWT-570
 Project: Mynewt
  Issue Type: Bug
  Components: Newtmgr
Affects Versions: v1_0_0_beta1
Reporter: Jacob
Assignee: Sterling Hughes



- "@apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart"

Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newt run split-nrf51dk 0
.
Error: 
repos/apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c: In 
function 'nmgr_uart_out':
repos/apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c:114:13:
 error: dereferencing type-punned pointer will break strict-aliasing rules 
[-Werror=strict-aliasing]
 *(uint16_t *)tmp_buf = htons(mpkt->omp_len);
 ^
repos/apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c: In 
function 'nmgr_uart_rx_char':
repos/apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c:330:23:
 error: 'g_mgmt_evq' undeclared (first use in this function)
 os_eventq_put(g_mgmt_evq, >nus_cb_ev);
   ^
repos/apache-mynewt-core/mgmt/newtmgr/transport/nmgr_uart/src/nmgr_uart.c:330:23:
 note: each undeclared identifier is reported only once for each function it 
appears in
cc1: all warnings being treated as errors






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-526) Gap params update succeeds, but times out immediately after

[Jacob (JIRA)]

Jacob created MYNEWT-526:


 Summary: Gap params update succeeds, but times out immediately 
after
 Key: MYNEWT-526
 URL: https://issues.apache.org/jira/browse/MYNEWT-526
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Affects Versions: v1_0_0_beta1
 Environment: macos sierra, gcc version 5.4.1 20160919
Reporter: Jacob


Modification of blecent, connecting and subscribing to my polar HRM.

My monitor (consistently) connects and subscribes and gets notifications for 
like 30 seconds before it does a successful gap params update, and then 
promptly times out.

I havent confirmed this yet but grammar wise you do seem to be mixing terms, 
timeout_multiplier and supervision_timeout are separate things in the spec

l2cap_params->timeout_multiplier = params->supervision_timeout; 

Perhaps the timeout_multiplier should be multiplied by 10ms to get the 
supervision_timeout?



3924:[ts=30656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
3926:[ts=30671832ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=4
3928:[ts=30687456ssb, mod=64 level=1] 0x16:0x00:0xee:0x02
3929:[ts=30695268ssb, mod=64 level=1] pkthdr_len=16; om_len=4  
ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=13 data=0x09 0x00 0x04 0x00 
0x1b 0x11 0x00 0x16 0x55 0xda 0x02 0xc9 0x02 
4052:[ts=31656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
4054:[ts=31671832ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=6
4056:[ts=31687456ssb, mod=64 level=1] 0x16:0x55:0xda:0x02:0xc9:0x02
4057:[ts=31695268ssb, mod=64 level=1] pkthdr_len=16; om_len=6  
ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=16 data=0x0c 0x00 0x05 0x00 
0x12 0x01 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
4148:[ts=32406224ssb, mod=4 level=0] L2CAP - rxed signalling msg: 0x12 0x01 
0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 
4151:[ts=32429660ssb, mod=4 level=1] GAP procedure initiated: connection 
parameter update; conn_handle=1 itvl_min=250 itvl_max=400 latency=1 
supervision_timeout=600 min_ce_len=16 max_ce_len
4156:[ts=32468720ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x13 
len=14
4158:[ts=32484344ssb, mod=4 level=0] 0x13 0x20 0x0e 0x01 0x00 0xfa 0x00 0x90 
0x01 0x01 0x00 0x58 0x02 0x10 0x00 0x00 0x03 
4159:[ts=32492156ssb, mod=4 level=0] Command Status: status=0 cmd_pkts=1 
ocf=0x13 ogf=0x8
4162:[ts=32515592ssb, mod=4 level=0] host tx hci data; handle=1 length=10
4163:[ts=32523404ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0a 0x00 
0x06 0x00 0x05 0x00 0x13 0x01 0x02 0x00 0x00 0x00 
4171:[ts=32585900ssb, mod=4 level=0] Number of Completed Packets: num_handles=1
4173:[ts=32601524ssb, mod=4 level=0] handle:1 pkts:1
4178:[ts=32640584ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1 
pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x56 0xc0 0x02 
4181:[ts=32664020ssb, mod=4 level=0] rxed att command: notify req; conn=1 
handle=0x0011
4183:[ts=32679644ssb, mod=64 level=1] received notification; conn_handle=1 
attr_handle=17 attr_len=4
4185:[ts=32695268ssb, mod=64 level=1] 0x16:0x56:0xc0:0x02
4186:[ts=32703080ssb, mod=64 level=1] pkthdr_len=16; om_len=4  LE Connection 
Update Complete. handle=1 itvl=400 latency=1 timeout=600
4978:[ts=38890568ssb, mod=4 level=0] Disconnection Complete: status=0 handle=1 
reason=8
4980:[ts=38906192ssb, mod=64 level=1] disconnect; reason=520 handle=1 
our_ota_addr_type=0 our_ota_addr=0c:0c:0c:0c:0c:0c our_id_addr_type=0 
our_id_addr=0c:0c:0c:0c:0c:0c peer_ota_addr_type=0 
peer_ota_addr=00:22:d0:2a:e4:a3 peer_id_addr_type=0 
peer_id_addr=00:22:d0:2a:e4:a3 conn_itvl=400 conn_latency=1 
supervision_timeout=600 encrypted=0 authenticated=0 bonded=0
4988:[ts=38968688ssb, mod=4 level=1] GAP procedure initiated: discovery; 
own_addr_type=0 filter_policy=0 passive=1 limited=0 filter_duplicates=1 
duration=forever





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)