[jira] [Updated] (MYNEWT-762) newtmgr conn add need to be updated for 1.1

[Wanda Chiu (JIRA)]

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

Wanda Chiu updated MYNEWT-762:
--
Summary:  newtmgr conn add need to be updated for 1.1  (was: ble addressing 
in newtmgr conn add need to be updated for 1.1)

>  newtmgr conn add need to be updated for 1.1
> 
>
> Key: MYNEWT-762
> URL: https://issues.apache.org/jira/browse/MYNEWT-762
> Project: Mynewt
>  Issue Type: Task
>  Security Level: Public(Viewable by anyone) 
>  Components: Documentation
>Affects Versions: v1_1_0_rel
>Reporter: Wanda Chiu
>Assignee: Wanda Chiu
>Priority: Minor
> Fix For: v1_1_0_rel
>
>
> Need to update 1.1 documentation for  **newtmgr conn add**  and remove 
> **addr** and **addrtype** as valid parameters. 



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

[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] [Commented] (MYNEWT-550) ble_gattc_indicate_custom to parallel ble_gattc_notify_custom

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-550:


I have created a pull request which implements this feature: 
https://github.com/apache/incubator-mynewt-core/pull/310

> ble_gattc_indicate_custom to parallel ble_gattc_notify_custom
> -
>
> Key: MYNEWT-550
> URL: https://issues.apache.org/jira/browse/MYNEWT-550
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Affects Versions: v1_0_0_beta1, v1_0_0_beta2
>Reporter: Simon Ratner
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Would be very handy to send arbitrary indications, and seems like an omission 
> since the corresponding notify api is there.



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

[jira] [Commented] (MYNEWT-760) Switch testbench app over to CoAP (from plain NMP)

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-760:


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

Currently, the testbench app uses plain newtmgr. The task is to modify the app 
so that newtmgr messages are sent via CoAP instead.

> Switch testbench app over to CoAP (from plain NMP)
> --
>
> Key: MYNEWT-760
> URL: https://issues.apache.org/jira/browse/MYNEWT-760
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>




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

[jira] [Updated] (MYNEWT-750) BLE Host - Ignore pairing attempt from already bonded peer

[Christopher Collins (JIRA)]

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

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

If a device is already bonded, the host should not allow the same device to 
pair again.  Currently, the host blindly proceeds with the pairing operation.  
This should not be allowed because the second peer could be an imposter 
masquerading as the original.

I propose the following behavior in such a scenario:
# Host notifies application of the duplicate pairing attempt via the gap event 
callback.  The callback would specify a new event code that specifically 
indicates a duplicate pairing attempt.
# The gap event callback would return an error code indicating which of the 
following behaviors to perform:
## Retry: Return BLE_GAP_REPEAT_PAIRING_RETRY after deleting the conflicting 
bond.  The stack will verify the bond has been deleted and continue the pairing 
procedure.  If the bond is still present, this event will be reported again.
## Ignore: Return BLE_GAP_REPEAT_PAIRING_IGNORE.  The stack will silently 
ignore the pairing request.


  was:
If a device is already bonded, the host should not allow the same device to 
pair again.  Currently, the host blindly proceeds with the pairing operation.  
This should not be allowed because the second peer could be an imposter 
masquerading as the original.

I propose the following behavior in such a scenario:
# Host notifies application of the duplicate pairing attempt via the gap event 
callback.  The callback would specify a new event code that specifically 
indicates a duplicate pairing attempt.
# The gap event callback would return an error code indicating which of the 
following behaviors to perform:
## Retry: Return BLE_GAP_REPEAT_PAIRING_RETRY after deleting the conflicting 
bond.  The stack will verify the bond has been deleted and continue the pairing 
procedure.  If the bond is still present, this event will be reported again.
## Ignore: Return BLE_GAP_REPEAT_PAIRING_IGNORE.  The stack will silently 
ignore the pairing request.



> BLE Host - Ignore pairing attempt from already bonded peer
> --
>
> Key: MYNEWT-750
> URL: https://issues.apache.org/jira/browse/MYNEWT-750
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-core/pull/287)
> If a device is already bonded, the host should not allow the same device to 
> pair again.  Currently, the host blindly proceeds with the pairing operation. 
>  This should not be allowed because the second peer could be an imposter 
> masquerading as the original.
> I propose the following behavior in such a scenario:
> # Host notifies application of the duplicate pairing attempt via the gap 
> event callback.  The callback would specify a new event code that 
> specifically indicates a duplicate pairing attempt.
> # The gap event callback would return an error code indicating which of the 
> following behaviors to perform:
> ## Retry: Return BLE_GAP_REPEAT_PAIRING_RETRY after deleting the conflicting 
> bond.  The stack will verify the bond has been deleted and continue the 
> pairing procedure.  If the bond is still present, this event will be reported 
> again.
> ## Ignore: Return BLE_GAP_REPEAT_PAIRING_IGNORE.  The stack will silently 
> ignore the pairing request.



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

[jira] [Updated] (MYNEWT-743) BLE Host - Persist bonding material to sys/config.

[Christopher Collins (JIRA)]

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

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

> BLE Host - Persist bonding material to sys/config.
> --
>
> Key: MYNEWT-743
> URL: https://issues.apache.org/jira/browse/MYNEWT-743
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-core/pull/280)



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

[jira] [Updated] (MYNEWT-751) BLE Host - Policy for SM key overflow

[Christopher Collins (JIRA)]

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

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

The BLE host needs a way to handle the case where a security store write fails 
because the maximum number of entries have already been written.  Currently, 
the host simply fails to persist the record and returns an error code.

I propose the following behavior in such a scenario:

# Host checks that there is sufficient storage for a bond before it starts a 
pairing operation.  Any currently-active pairing procedures should be included 
in the total number of bonds.
# If there is insufficient space, host notifies application of the issue via a 
callback.
# The callback would return an error code indicating which of the following 
behaviors to perform:
## Reject the pairing request.
## Proceed with the pairing operation (presumably the application would delete 
a security record to make room before returning from the callback).

  was:
The BLE host needs a way to handle the case where a security store write fails 
because the maximum number of entries have already been written.  Currently, 
the host simply fails to persist the record and returns an error code.

I propose the following behavior in such a scenario:

# Host checks that there is sufficient storage for a bond before it starts a 
pairing operation.  Any currently-active pairing procedures should be included 
in the total number of bonds.
# If there is insufficient space, host notifies application of the issue via a 
callback.
# The callback would return an error code indicating which of the following 
behaviors to perform:
## Reject the pairing request.
## Proceed with the pairing operation (presumably the application would delete 
a security record to make room before returning from the callback).


> BLE Host - Policy for SM key overflow
> -
>
> Key: MYNEWT-751
> URL: https://issues.apache.org/jira/browse/MYNEWT-751
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-core/pull/279)
> The BLE host needs a way to handle the case where a security store write 
> fails because the maximum number of entries have already been written.  
> Currently, the host simply fails to persist the record and returns an error 
> code.
> I propose the following behavior in such a scenario:
> # Host checks that there is sufficient storage for a bond before it starts a 
> pairing operation.  Any currently-active pairing procedures should be 
> included in the total number of bonds.
> # If there is insufficient space, host notifies application of the issue via 
> a callback.
> # The callback would return an error code indicating which of the following 
> behaviors to perform:
> ## Reject the pairing request.
> ## Proceed with the pairing operation (presumably the application would 
> delete a security record to make room before returning from the callback).



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-756:


This works for me on the nRF51dk.  One possibility is that your device is 
running out of mbufs.  The mpstat command is actually quite mbuf-hungry because 
it generates such a large response.  Unfortunately, we need the mpstat command 
to determine if this is the case!

Are you building with a reduced mbuf size or count?  For the record, here is 
the target I used:

{noformat}
targets/bleprph-nrf51dk
app=apps/bleprph
bsp=hw/bsp/nrf51dk
build_profile=optimized

syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_PUBLIC_DEV_ADDR=(uint8_t[6]){0x1c, 
0x22, 0x00, 0x99, 0x99, 
0x99}:BLE_SM_LEGACY=0:BLE_SM_SC=0:LOG_LEVEL=1:STATS_NAMES=1
{noformat}

And here is the mpstat output:
{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph -n 
nimble-bleprph mpstat
name blksz  cnt free  min
  ble_att_svr_entry_pool20   3700
 ble_att_svr_prep_entry_pool12   64   64   64
  ble_gap_update24111
 ble_gattc_proc_pool56444
  ble_gatts_clt_cfg_pool16200
 ble_hci_ram_evt_hi_pool72220
 ble_hci_ram_evt_lo_pool72888
ble_hs_conn_pool84100
  ble_hs_hci_ev_pool16   10   109
 ble_l2cap_chan_pool28300
 ble_l2cap_sig_proc_pool20111
  msys_1   292   1298
{noformat}

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

[jira] [Updated] (MYNEWT-772) BLE Host - Initial set-event-mask specifies reserved bits

[Christopher Collins (JIRA)]

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

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

The host intends to enable the following events at start up:
{noformat}
/**
 * Enable the following events:
 * 0x0001 Inquiry Complete Event
 * 0x0002 Inquiry Result Event
 * 0x0004 Connection Complete Event
 * 0x0008 Connection Request Event
 * 0x0010 Disconnection Complete Event
 * 0x0020 Authentication Complete Event
 * 0x0040 Remote Name Request Complete Event
 * 0x0080 Encryption Change Event
 * 0x0100 Change Connection Link Key Complete Event
 * 0x0200 Master Link Key Complete Event
 * 0x0400 Read Remote Supported Features Complete Event
 * 0x0800 Read Remote Version Information Complete Event
 * 0x1000 QoS Setup Complete Event
 * 0x2000 Reserved
 * 0x4000 Reserved
 * 0x8000 Hardware Error Event
 * 0x0001 Flush Occurred Event
 * 0x0002 Role Change Event
 * 0x0004 Reserved
 * 0x0008 Mode Change Event
 * 0x0010 Return Link Keys Event
 * 0x0020 PIN Code Request Event
 * 0x0040 Link Key Request Event
 * 0x0080 Link Key Notification Event
 * 0x0100 Loopback Command Event
 * 0x0200 Data Buffer Overflow Event
 * 0x0400 Max Slots Change Event
 * 0x0800 Read Clock Offset Complete Event
 * 0x1000 Connection Packet Type Changed Event
 * 0x2000 QoS Violation Event
 * 0x4000 Page Scan Mode Change Event [deprecated]
 * 0x8000 Page Scan Repetition Mode Change Event
 * 0x0001 Flow Specification Complete Event
 * 0x0002 Inquiry Result with RSSI Event
 * 0x0004 Read Remote Extended Features Complete Event
 * 0x0800 Synchronous Connection Complete Event
 * 0x1000 Synchronous Connection Changed Event
 * 0x8000 Encryption Key Refresh Complete Event
 * 0x2000 LE Meta-Event
 */
{noformat}

It does this by setting the following bit mask: {{0x20009fff}}.  This 
mask is incorrect; it should be: {{0x20009807}}.

  was:
The host intends to enable the following events at start up:
{noformat}
/**
 * Enable the following events:
 * 0x0001 Inquiry Complete Event
 * 0x0002 Inquiry Result Event
 * 0x0004 Connection Complete Event
 * 0x0008 Connection Request Event
 * 0x0010 Disconnection Complete Event
 * 0x0020 Authentication Complete Event
 * 0x0040 Remote Name Request Complete Event
 * 0x0080 Encryption Change Event
 * 0x0100 Change Connection Link Key Complete Event
 * 0x0200 Master Link Key Complete Event
 * 0x0400 Read Remote Supported Features Complete Event
 * 0x0800 Read Remote Version Information Complete Event
 * 0x1000 QoS Setup Complete Event
 * 0x2000 Reserved
 * 0x4000 Reserved
 * 0x8000 Hardware Error Event
 * 0x0001 Flush Occurred Event
 * 0x0002 Role Change Event
 * 0x0004 Reserved
 * 0x0008 Mode Change Event
 * 0x0010 Return Link Keys Event
 * 0x0020 PIN Code Request Event
 * 0x0040 Link Key Request Event
 * 0x0080 Link Key Notification Event
 * 0x0100 Loopback Command Event
 * 0x0200 Data Buffer Overflow Event
 * 0x0400 Max Slots Change Event
 * 0x0800 Read Clock Offset Complete Event
 * 0x1000 Connection Packet Type Changed Event
 * 0x2000 QoS Violation Event
 * 0x4000 Page Scan Mode Change Event [deprecated]
 * 0x8000 Page Scan Repetition Mode Change Event
 * 0x0001 Flow Specification Complete Event
 * 0x0002 Inquiry Result with RSSI Event
 * 0x0004 Read Remote Extended Features Complete Event
 * 0x0800 

[jira] [Updated] (MYNEWT-772) BLE Host - Initial set-event-mask specifies reserved bits

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-772:
---
Description: 
The host intends to enable the following events at start up:
{noformat}
/**
 * Enable the following events:
 * 0x0001 Inquiry Complete Event
 * 0x0002 Inquiry Result Event
 * 0x0004 Connection Complete Event
 * 0x0008 Connection Request Event
 * 0x0010 Disconnection Complete Event
 * 0x0020 Authentication Complete Event
 * 0x0040 Remote Name Request Complete Event
 * 0x0080 Encryption Change Event
 * 0x0100 Change Connection Link Key Complete Event
 * 0x0200 Master Link Key Complete Event
 * 0x0400 Read Remote Supported Features Complete Event
 * 0x0800 Read Remote Version Information Complete Event
 * 0x1000 QoS Setup Complete Event
 * 0x2000 Reserved
 * 0x4000 Reserved
 * 0x8000 Hardware Error Event
 * 0x0001 Flush Occurred Event
 * 0x0002 Role Change Event
 * 0x0004 Reserved
 * 0x0008 Mode Change Event
 * 0x0010 Return Link Keys Event
 * 0x0020 PIN Code Request Event
 * 0x0040 Link Key Request Event
 * 0x0080 Link Key Notification Event
 * 0x0100 Loopback Command Event
 * 0x0200 Data Buffer Overflow Event
 * 0x0400 Max Slots Change Event
 * 0x0800 Read Clock Offset Complete Event
 * 0x1000 Connection Packet Type Changed Event
 * 0x2000 QoS Violation Event
 * 0x4000 Page Scan Mode Change Event [deprecated]
 * 0x8000 Page Scan Repetition Mode Change Event
 * 0x0001 Flow Specification Complete Event
 * 0x0002 Inquiry Result with RSSI Event
 * 0x0004 Read Remote Extended Features Complete Event
 * 0x0800 Synchronous Connection Complete Event
 * 0x1000 Synchronous Connection Changed Event
 * 0x8000 Encryption Key Refresh Complete Event
 * 0x2000 LE Meta-Event
 */
{noformat}

It does this by setting the following bit mask: {{0x20009fff}}.  This 
mask is incorrect; it should be: {{0x20009807}}.

  was:
The host intends to enable the following events at start up:
{noformat}
/**
 * Enable the following events:
 * 0x0001 Inquiry Complete Event
 * 0x0002 Inquiry Result Event
 * 0x0004 Connection Complete Event
 * 0x0008 Connection Request Event
 * 0x0010 Disconnection Complete Event
 * 0x0020 Authentication Complete Event
 * 0x0040 Remote Name Request Complete Event
 * 0x0080 Encryption Change Event
 * 0x0100 Change Connection Link Key Complete Event
 * 0x0200 Master Link Key Complete Event
 * 0x0400 Read Remote Supported Features Complete Event
 * 0x0800 Read Remote Version Information Complete Event
 * 0x1000 QoS Setup Complete Event
 * 0x2000 Reserved
 * 0x4000 Reserved
 * 0x8000 Hardware Error Event
 * 0x0001 Flush Occurred Event
 * 0x0002 Role Change Event
 * 0x0004 Reserved
 * 0x0008 Mode Change Event
 * 0x0010 Return Link Keys Event
 * 0x0020 PIN Code Request Event
 * 0x0040 Link Key Request Event
 * 0x0080 Link Key Notification Event
 * 0x0100 Loopback Command Event
 * 0x0200 Data Buffer Overflow Event
 * 0x0400 Max Slots Change Event
 * 0x0800 Read Clock Offset Complete Event
 * 0x1000 Connection Packet Type Changed Event
 * 0x2000 QoS Violation Event
 * 0x4000 Page Scan Mode Change Event [deprecated]
 * 0x8000 Page Scan Repetition Mode Change Event
 * 0x0001 Flow Specification Complete Event
 * 0x0002 Inquiry Result with RSSI Event
 * 0x0004 Read Remote Extended Features Complete Event
 * 0x0800 Synchronous Connection Complete Event
 * 0x1000 Synchronous 

[jira] [Created] (MYNEWT-772) BLE Host - Initial set-event-mask specifies reserved bits

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-772:
--

 Summary: BLE Host - Initial set-event-mask specifies reserved bits
 Key: MYNEWT-772
 URL: https://issues.apache.org/jira/browse/MYNEWT-772
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


The host intends to enable the following events at start up:
{noformat}
/**
 * Enable the following events:
 * 0x0001 Inquiry Complete Event
 * 0x0002 Inquiry Result Event
 * 0x0004 Connection Complete Event
 * 0x0008 Connection Request Event
 * 0x0010 Disconnection Complete Event
 * 0x0020 Authentication Complete Event
 * 0x0040 Remote Name Request Complete Event
 * 0x0080 Encryption Change Event
 * 0x0100 Change Connection Link Key Complete Event
 * 0x0200 Master Link Key Complete Event
 * 0x0400 Read Remote Supported Features Complete Event
 * 0x0800 Read Remote Version Information Complete Event
 * 0x1000 QoS Setup Complete Event
 * 0x2000 Reserved
 * 0x4000 Reserved
 * 0x8000 Hardware Error Event
 * 0x0001 Flush Occurred Event
 * 0x0002 Role Change Event
 * 0x0004 Reserved
 * 0x0008 Mode Change Event
 * 0x0010 Return Link Keys Event
 * 0x0020 PIN Code Request Event
 * 0x0040 Link Key Request Event
 * 0x0080 Link Key Notification Event
 * 0x0100 Loopback Command Event
 * 0x0200 Data Buffer Overflow Event
 * 0x0400 Max Slots Change Event
 * 0x0800 Read Clock Offset Complete Event
 * 0x1000 Connection Packet Type Changed Event
 * 0x2000 QoS Violation Event
 * 0x4000 Page Scan Mode Change Event [deprecated]
 * 0x8000 Page Scan Repetition Mode Change Event
 * 0x0001 Flow Specification Complete Event
 * 0x0002 Inquiry Result with RSSI Event
 * 0x0004 Read Remote Extended Features Complete Event
 * 0x0800 Synchronous Connection Complete Event
 * 0x1000 Synchronous Connection Changed Event
 * 0x8000 Encryption Key Refresh Complete Event
 * 0x2000 LE Meta-Event
 */
{noformat}

It does this by setting the following bit mask: {{0x20009fff}}.  This 
mask in incorrect; it should be: {{0x20009807}}.



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

[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] [Resolved] (MYNEWT-450) Enable extensible module ID and matching names for log messages

[Sheela (JIRA)]

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

Sheela resolved MYNEWT-450.
---
Resolution: Fixed

> Enable extensible module ID and matching names for log messages
> ---
>
> Key: MYNEWT-450
> URL: https://issues.apache.org/jira/browse/MYNEWT-450
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: OS
>Affects Versions: v1_0_0_beta1
>Reporter: Peter Snyder
>Assignee: Peter Snyder
>
> Log messages are associated with a particular module which can be used for 
> filtering entries. Each module has a string associated with it and this is 
> used by newtmgr to list which log are available.
> While intended to be extensible, there is not a mechanism to associate module 
> strings with additional module types. There are a number of pre-configured 
> module names and strings associated with OS subsystems (e.g, NIMBLE, NFFS, 
> OS...) but a more systematic and extensible way to associate modules and name 
> strings is needed.



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

[jira] [Closed] (MYNEWT-460) Version string updates

[Sheela (JIRA)]

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

Sheela closed MYNEWT-460.
-
Resolution: Fixed

Now documented as part of release process

> Version string updates
> --
>
> Key: MYNEWT-460
> URL: https://issues.apache.org/jira/browse/MYNEWT-460
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Affects Versions: v1_0_0_beta1
>Reporter: David G. Simmons
>Assignee: Sterling Hughes
>
> Version strings for newt tool are not updated. They should probably be 
> updated in each branch so users know what version/branch they are using.



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

[jira] [Assigned] (MYNEWT-469) Add a 'raw uart' mode to Console

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-469:
-

Assignee: Michał Narajowski  (was: Marko Kiiskila)

> Add a 'raw uart' mode to Console
> 
>
> Key: MYNEWT-469
> URL: https://issues.apache.org/jira/browse/MYNEWT-469
> Project: Mynewt
>  Issue Type: Wish
>  Security Level: Public(Viewable by anyone) 
>  Components: OS
>Affects Versions: WISHLIST, v1_0_0_beta2
> Environment: all
>Reporter: Wayne Keenan
>Assignee: Michał Narajowski
> Fix For: WISHLIST
>
>
> As Marko suggested on the dev list to my original text below, just add a 
> 'raw' mode to the existing console.
> It would also be very useful to expose the console's CONSOLE_RX_BUF_SZ & 
> CONSOLE_TX_BUF_SZ #defines as tweakable pkg and target config settings.
> ---
> Original text, ignore...
> I've found that (at least) the stdout, stdin and the assert facility depends 
> on the console module; I think this is perhaps inverted, but obviously that 
> depends on your view...
>  
> I wish to use direct UART access and am using the console stub to placate the 
> noble et. al dependancies.  But as a result no assert messages can be output. 
> I'd also like to wire up a third part library to stdout/in (however in the 
> version I'm using these seem to be somewhat deserted constructs)
> I've not had a chance to look, but is there a low level UART HAL (perhaps 
> with basic buffer support) that the console, stdio, assert can all depend on 
> in more recent development versions of Mynewt?
> The OOTB MicroPython REPL console code really needs direct access to Serial 
> TX/RX.
> Two key issues are:
> cons_tty.c 'mangles' RX data before 
> stdout depends on console_write



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

[jira] [Closed] (MYNEWT-479) initialize different set of devices when building bootloader

[Sheela (JIRA)]

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

Sheela closed MYNEWT-479.
-
Resolution: Duplicate

Duplicate of #532

> initialize different set of devices when building bootloader
> 
>
> Key: MYNEWT-479
> URL: https://issues.apache.org/jira/browse/MYNEWT-479
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>
> bootloader does not need most of the devices created in bsp_init(). 
> Initializing unneeded devices has a significant impact on the size of the end 
> result.
> bsp_init() for bootloader should only initialize flash, and if BOOT_SERIAL is 
> set, then the console uart.



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

[jira] [Updated] (MYNEWT-482) support flash erase via newt command-line

[Sheela (JIRA)]

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

Sheela updated MYNEWT-482:
--
Fix Version/s: WISHLIST

> support flash erase via newt command-line
> -
>
> Key: MYNEWT-482
> URL: https://issues.apache.org/jira/browse/MYNEWT-482
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>Priority: Minor
> Fix For: WISHLIST
>
>




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

[jira] [Updated] (MYNEWT-482) support flash erase via newt command-line

[Sheela (JIRA)]

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

Sheela updated MYNEWT-482:
--
Issue Type: Improvement  (was: Bug)

> support flash erase via newt command-line
> -
>
> Key: MYNEWT-482
> URL: https://issues.apache.org/jira/browse/MYNEWT-482
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
> Fix For: WISHLIST
>
>




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

[jira] [Updated] (MYNEWT-482) support flash erase via newt command-line

[Sheela (JIRA)]

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

Sheela updated MYNEWT-482:
--
Affects Version/s: (was: WISHLIST)

> support flash erase via newt command-line
> -
>
> Key: MYNEWT-482
> URL: https://issues.apache.org/jira/browse/MYNEWT-482
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>Priority: Minor
> Fix For: WISHLIST
>
>




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

[jira] [Updated] (MYNEWT-482) support flash erase via newt command-line

[Sheela (JIRA)]

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

Sheela updated MYNEWT-482:
--
Priority: Minor  (was: Major)

> support flash erase via newt command-line
> -
>
> Key: MYNEWT-482
> URL: https://issues.apache.org/jira/browse/MYNEWT-482
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>Priority: Minor
> Fix For: WISHLIST
>
>




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

[jira] [Updated] (MYNEWT-482) support flash erase via newt command-line

[Sheela (JIRA)]

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

Sheela updated MYNEWT-482:
--
Affects Version/s: WISHLIST

> support flash erase via newt command-line
> -
>
> Key: MYNEWT-482
> URL: https://issues.apache.org/jira/browse/MYNEWT-482
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>Priority: Minor
> Fix For: WISHLIST
>
>




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

[jira] [Updated] (MYNEWT-502) nrf52 ADC will not work if VDD4 reference is specified

[Sheela (JIRA)]

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

Sheela updated MYNEWT-502:
--
Fix Version/s: (was: v1_1_0_rel)

> nrf52 ADC will not work if VDD4 reference is specified
> --
>
> Key: MYNEWT-502
> URL: https://issues.apache.org/jira/browse/MYNEWT-502
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: BSP
>Affects Versions: v1_0_0_beta1
>Reporter: William San Filippo
>Assignee: William San Filippo
>
> There is bug in the nrf52 adc code when VDD4 reference is used. The code is 
> expecting a global "init_adc_config" to have been configured prior to 
> nrf52_adc_configure_channel being called (this is called through 
> adc_chan_config). The BSP's are not initializing this structure. Note that 
> init_adc_config gets set through a call to nrf52_adc_dev_init(). The call to 
> os_dev_create() is what calls the initialization function which should end up 
> calling nrf52_adc_dev_init(). Not sure exactly which structures need to be 
> passed into os_dev_create() and os_dev_open(); these need to be reconciled.



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

[jira] [Updated] (MYNEWT-522) Callout API should be improved to add a "call back at" timer function.

[Sheela (JIRA)]

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

Sheela updated MYNEWT-522:
--
Fix Version/s: (was: v1_1_0_rel)

> Callout API should be improved to add a "call back at" timer function.  
> 
>
> Key: MYNEWT-522
> URL: https://issues.apache.org/jira/browse/MYNEWT-522
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: OS
>Affects Versions: v1_0_0_beta2
>Reporter: Sterling Hughes
>
> Thread describing feature and potential implementation.
> https://lists.apache.org/thread.html/122791020d131b9b7c7bc100fa5c16efc2663bc7a24e79f45aef9568@%3Cdev.mynewt.apache.org%3E



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

[jira] [Assigned] (MYNEWT-550) ble_gattc_indicate_custom to parallel ble_gattc_notify_custom

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-550:
-

Assignee: Christopher Collins

> ble_gattc_indicate_custom to parallel ble_gattc_notify_custom
> -
>
> Key: MYNEWT-550
> URL: https://issues.apache.org/jira/browse/MYNEWT-550
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Affects Versions: v1_0_0_beta1, v1_0_0_beta2
>Reporter: Simon Ratner
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Would be very handy to send arbitrary indications, and seems like an omission 
> since the corresponding notify api is there.



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

[jira] [Assigned] (MYNEWT-553) Option in newt to print only executed commands during build.

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-553:
-

Assignee: Michał Narajowski

> Option in newt to print only executed commands during build.
> 
>
> Key: MYNEWT-553
> URL: https://issues.apache.org/jira/browse/MYNEWT-553
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Aditi Hilbert
>Assignee: Michał Narajowski
>
> This could be then used instead of '-l debug' which
> produces huge amount of logs



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

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

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-571:
-

Assignee: Marko Kiiskila

> 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
>  Security Level: Public(Viewable by anyone) 
>  Components: OS
>Reporter: Jacob
>Assignee: Marko Kiiskila
>
> 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.15#6346)

[jira] [Assigned] (MYNEWT-574) re-evaluate the amount of initial stack space for cortex MCUs

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-574:
-

Assignee: William San Filippo

> re-evaluate the amount of initial stack space for cortex MCUs
> -
>
> Key: MYNEWT-574
> URL: https://issues.apache.org/jira/browse/MYNEWT-574
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>Assignee: William San Filippo
>
> Now that main() does not run in the initial context, that stack space 
> requirements have changed. We could probably reduce this amount, and
> get some additional heap space.



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

[jira] [Resolved] (MYNEWT-583) Allow project.yml to specify a commit hash

[Sheela (JIRA)]

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

Sheela resolved MYNEWT-583.
---
Resolution: Fixed

> Allow project.yml to specify a commit hash
> --
>
> Key: MYNEWT-583
> URL: https://issues.apache.org/jira/browse/MYNEWT-583
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Affects Versions: v1_0_0_rel
>Reporter: Simon Ratner
>Assignee: Marko Kiiskila
> Fix For: v1_1_0_rel
>
>
> Would be great if one could lock down a specific mynewt-core commit hash in 
> project.yml, in addition to tags. Currently, one tags are supported, but when 
> using develop/latest it is more useful to test against a fixed known state.



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

[jira] [Closed] (MYNEWT-635) unlock rb-nano2 flash in download script

[Sheela (JIRA)]

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

Sheela closed MYNEWT-635.
-
Resolution: Duplicate

Duplicate #681

> unlock rb-nano2 flash in download script
> 
>
> Key: MYNEWT-635
> URL: https://issues.apache.org/jira/browse/MYNEWT-635
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>
> Download script should inspect whether flash is write-protected, and unlock 
> it if needed.



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

[jira] [Resolved] (MYNEWT-643) ctrl-c on windows during 'newt debug' kills jtag software

[Sheela (JIRA)]

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

Sheela resolved MYNEWT-643.
---
Resolution: Fixed

> ctrl-c on windows during 'newt debug' kills jtag software
> -
>
> Key: MYNEWT-643
> URL: https://issues.apache.org/jira/browse/MYNEWT-643
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: v1_0_0_rel
>Reporter: Marko Kiiskila
>
> At least when using http://win-bash.sourceforge.net/ as the bash.



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

[jira] [Updated] (MYNEWT-644) newt build's hunt for project.yml fails to find it when starting in sub-dir

[Sheela (JIRA)]

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

Sheela updated MYNEWT-644:
--
Fix Version/s: v1_1_0_rel

> newt build's hunt for project.yml fails to find it when starting in sub-dir
> ---
>
> Key: MYNEWT-644
> URL: https://issues.apache.org/jira/browse/MYNEWT-644
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: v1_0_0_rel
>Reporter: Marko Kiiskila
> Fix For: v1_1_0_rel
>
>
> This is what it looks like:
> Z:\marko\src8\incubator-mynewt-blinky\repos>newt -lDEBUG build boot_bbc
> 2017/02/27 21:01:51.450 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.451 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.452 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.453 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.454 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.455 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.456 [DEBUG] Searching for project file ./project.yml



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

[jira] [Assigned] (MYNEWT-644) newt build's hunt for project.yml fails to find it when starting in sub-dir

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-644:
-

Assignee: Marko Kiiskila

> newt build's hunt for project.yml fails to find it when starting in sub-dir
> ---
>
> Key: MYNEWT-644
> URL: https://issues.apache.org/jira/browse/MYNEWT-644
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: v1_0_0_rel
>Reporter: Marko Kiiskila
>Assignee: Marko Kiiskila
> Fix For: v1_1_0_rel
>
>
> This is what it looks like:
> Z:\marko\src8\incubator-mynewt-blinky\repos>newt -lDEBUG build boot_bbc
> 2017/02/27 21:01:51.450 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.451 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.452 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.453 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.454 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.455 [DEBUG] Searching for project file ./project.yml
> 2017/02/27 21:01:51.456 [DEBUG] Searching for project file ./project.yml



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

[jira] [Assigned] (MYNEWT-648) "newt test net/oic" fails when compiling with clang

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-648:
-

Assignee: Marko Kiiskila

> "newt test net/oic" fails when compiling with clang
> ---
>
> Key: MYNEWT-648
> URL: https://issues.apache.org/jira/browse/MYNEWT-648
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Aditi Hilbert
>Assignee: Marko Kiiskila
> Fix For: v1_1_0_rel
>
>
> $ newt test net/oic
> Testing package net/oic/test
> Compiling encoding/cborattr/src/cborattr.c
> Compiling encoding/tinycbor/src/cborerrorstrings.c
> 
> Compiling net/oic/src/api/oc_server_api.c
> In file included from net/oic/src/api/oc_buffer.c:23:
> In file included from net/oic/src/messaging/coap/engine.h:38:
> In file included from net/oic/src/messaging/coap/observe.h:45:
> net/oic/include/oic/oc_ri.h:126:3: error: redefinition of typedef 
> 'oc_resource_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
> } oc_resource_t;
>   ^
> net/oic/include/oic/oc_ri.h:98:28: note: previous definition is here
> typedef struct oc_resource oc_resource_t;
>^
> net/oic/include/oic/oc_ri.h:152:28: error: redefinition of typedef 
> 'coap_packet_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
> typedef struct coap_packet coap_packet_t;
>^
> net/oic/src/messaging/coap/coap.h:227:3: note: previous definition is here
> } coap_packet_t;
>   ^
> In file included from net/oic/src/api/oc_buffer.c:23:
> In file included from net/oic/src/messaging/coap/engine.h:39:
> In file included from net/oic/src/messaging/coap/separate.h:46:
> net/oic/src/messaging/coap/oc_coap.h:30:3: error: redefinition of typedef 
> 'oc_separate_response_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
> } oc_separate_response_t;
>   ^
> net/oic/include/oic/oc_ri.h:64:37: note: previous definition is here
> typedef struct oc_separate_response oc_separate_response_t;
> ^
> In file included from net/oic/src/api/oc_buffer.c:23:
> In file included from net/oic/src/messaging/coap/engine.h:39:
> In file included from net/oic/src/messaging/coap/separate.h:46:
> net/oic/src/messaging/coap/oc_coap.h:37:3: error: redefinition of typedef 
> 'oc_response_buffer_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
> } oc_response_buffer_t;
>   ^
> net/oic/include/oic/oc_ri.h:66:35: note: previous definition is here
> typedef struct oc_response_buffer oc_response_buffer_t;
>   ^
> In file included from net/oic/src/api/oc_buffer.c:23:
> In file included from net/oic/src/messaging/coap/engine.h:39:
> net/oic/src/messaging/coap/separate.h:67:28: error: redefinition of typedef 
> 'coap_packet_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
> typedef struct coap_packet coap_packet_t;
>^
> net/oic/include/oic/oc_ri.h:152:28: note: previous definition is here
> typedef struct coap_packet coap_packet_t;
>^
> 5 errors generated.
> Error: Test failure(s):
> Passed tests: []
> Failed tests: [net/oic/test]



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

[jira] [Assigned] (MYNEWT-657) Ability to configure per-module log level at compile time

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-657:
-

Assignee: Christopher Collins

> Ability to configure per-module log level at compile time
> -
>
> Key: MYNEWT-657
> URL: https://issues.apache.org/jira/browse/MYNEWT-657
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>Assignee: Christopher Collins
>
> Currently, the log level can only be configured globally (via the LOG_LEVEL 
> syscfg setting).  It would be useful if each module had its own log level.
> Unfortunately, I don't know of a better way to do this than to define 
> module-specific versions of all the LOG_... macros.



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

[jira] [Updated] (MYNEWT-648) "newt test net/oic" fails when compiling with clang

[Sheela (JIRA)]

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

Sheela updated MYNEWT-648:
--
Fix Version/s: v1_1_0_rel

> "newt test net/oic" fails when compiling with clang
> ---
>
> Key: MYNEWT-648
> URL: https://issues.apache.org/jira/browse/MYNEWT-648
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Aditi Hilbert
> Fix For: v1_1_0_rel
>
>
> $ newt test net/oic
> Testing package net/oic/test
> Compiling encoding/cborattr/src/cborattr.c
> Compiling encoding/tinycbor/src/cborerrorstrings.c
> 
> Compiling net/oic/src/api/oc_server_api.c
> In file included from net/oic/src/api/oc_buffer.c:23:
> In file included from net/oic/src/messaging/coap/engine.h:38:
> In file included from net/oic/src/messaging/coap/observe.h:45:
> net/oic/include/oic/oc_ri.h:126:3: error: redefinition of typedef 
> 'oc_resource_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
> } oc_resource_t;
>   ^
> net/oic/include/oic/oc_ri.h:98:28: note: previous definition is here
> typedef struct oc_resource oc_resource_t;
>^
> net/oic/include/oic/oc_ri.h:152:28: error: redefinition of typedef 
> 'coap_packet_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
> typedef struct coap_packet coap_packet_t;
>^
> net/oic/src/messaging/coap/coap.h:227:3: note: previous definition is here
> } coap_packet_t;
>   ^
> In file included from net/oic/src/api/oc_buffer.c:23:
> In file included from net/oic/src/messaging/coap/engine.h:39:
> In file included from net/oic/src/messaging/coap/separate.h:46:
> net/oic/src/messaging/coap/oc_coap.h:30:3: error: redefinition of typedef 
> 'oc_separate_response_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
> } oc_separate_response_t;
>   ^
> net/oic/include/oic/oc_ri.h:64:37: note: previous definition is here
> typedef struct oc_separate_response oc_separate_response_t;
> ^
> In file included from net/oic/src/api/oc_buffer.c:23:
> In file included from net/oic/src/messaging/coap/engine.h:39:
> In file included from net/oic/src/messaging/coap/separate.h:46:
> net/oic/src/messaging/coap/oc_coap.h:37:3: error: redefinition of typedef 
> 'oc_response_buffer_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
> } oc_response_buffer_t;
>   ^
> net/oic/include/oic/oc_ri.h:66:35: note: previous definition is here
> typedef struct oc_response_buffer oc_response_buffer_t;
>   ^
> In file included from net/oic/src/api/oc_buffer.c:23:
> In file included from net/oic/src/messaging/coap/engine.h:39:
> net/oic/src/messaging/coap/separate.h:67:28: error: redefinition of typedef 
> 'coap_packet_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
> typedef struct coap_packet coap_packet_t;
>^
> net/oic/include/oic/oc_ri.h:152:28: note: previous definition is here
> typedef struct coap_packet coap_packet_t;
>^
> 5 errors generated.
> Error: Test failure(s):
> Passed tests: []
> Failed tests: [net/oic/test]



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

[jira] [Updated] (MYNEWT-657) Ability to configure per-module log level at compile time

[Sheela (JIRA)]

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

Sheela updated MYNEWT-657:
--
Fix Version/s: (was: v1_1_0_rel)

> Ability to configure per-module log level at compile time
> -
>
> Key: MYNEWT-657
> URL: https://issues.apache.org/jira/browse/MYNEWT-657
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>
> Currently, the log level can only be configured globally (via the LOG_LEVEL 
> syscfg setting).  It would be useful if each module had its own log level.
> Unfortunately, I don't know of a better way to do this than to define 
> module-specific versions of all the LOG_... macros.



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

[jira] [Assigned] (MYNEWT-661) BLE Host - SC:yes, lgcy:no - device never responds to pairing rsp.

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-661:
-

Assignee: Christopher Collins

> BLE Host - SC:yes, lgcy:no - device never responds to pairing rsp.
> --
>
> Key: MYNEWT-661
> URL: https://issues.apache.org/jira/browse/MYNEWT-661
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Configure device A with the following settings:
> {noformat}
> BLE_SM_LEGACY: 0
> BLE_SM_SC: 1
> {noformat}
> Configure device B with the opposite settings:
> {noformat}
> BLE_SM_LEGACY: 1
> BLE_SM_SC: 0
> {noformat}
> # Connect the two devices.
> # Device A initiates pairing.
> The result is: device A never responds to B's paring response.  Instead, it 
> does nothing and allows the pairing procedure to time out.



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

[jira] [Assigned] (MYNEWT-663) can't build bootloader for ci40

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-663:
-

Assignee: Julian Ingram

> can't build bootloader for ci40
> ---
>
> Key: MYNEWT-663
> URL: https://issues.apache.org/jira/browse/MYNEWT-663
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>Assignee: Julian Ingram
>
> It's missing hal flash driver:
> Linking /mnt/hgfs/marko/test_1_0/bin/targets/boot_ci40/app/apps/boot/boot.elf
> Error: 
> /mnt/hgfs/marko/test_1_0/bin/targets/boot_ci40/app/apps/boot/apps_boot.a(boot.o):
>  In function `main':
> repos/apache-mynewt-core/apps/boot/src/boot.c:(.text.startup+0x4c): undefined 
> reference to `hal_system_start'
> /mnt/hgfs/marko/test_1_0/bin/targets/boot_ci40/app/hw/hal/hw_hal.a(hal_flash.o):
>  In function `hal_flash_init':
> repos/apache-mynewt-core/hw/hal/src/hal_flash.c:(.text+0x48): undefined 
> reference to `hal_bsp_flash_dev'
> /mnt/hgfs/marko/test_1_0/bin/targets/boot_ci40/app/hw/hal/hw_hal.a(hal_flash.o):
>  In function `hal_flash_align':
> repos/apache-mynewt-core/hw/hal/src/hal_flash.c:(.text+0x98): undefined 
> reference to `hal_bsp_flash_dev'
> /mnt/hgfs/marko/test_1_0/bin/targets/boot_ci40/app/hw/hal/hw_hal.a(hal_flash.o):
>  In function `hal_flash_read':
> repos/apache-mynewt-core/hw/hal/src/hal_flash.c:(.text+0x114): undefined 
> reference to `hal_bsp_flash_dev'



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

[jira] [Assigned] (MYNEWT-664) coredownload newtmgr command should indicate core size in first response

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-664:
-

Assignee: Christopher Collins

> coredownload newtmgr command should indicate core size in first response
> 
>
> Key: MYNEWT-664
> URL: https://issues.apache.org/jira/browse/MYNEWT-664
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> This would be analogous to the "image upload", "file upload", and "file 
> download" commands.  Each of these indicate the total number of bytes in the 
> first packet.
> This change involves a backwards compatible modification to the NMP protocol. 
>  Compatibility is maintained because this change only requires the addition 
> of a new field, not the modification or removal of existing fields.



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

[jira] [Closed] (MYNEWT-684) Support

[Sheela (JIRA)]

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

Sheela closed MYNEWT-684.
-
Resolution: Fixed

not enough info

> Support 
> 
>
> Key: MYNEWT-684
> URL: https://issues.apache.org/jira/browse/MYNEWT-684
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Reporter: Sterling Hughes
>




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

[jira] [Assigned] (MYNEWT-695) Arduino Zero with Wifi Shield 101 failing on wifi start

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-695:
-

Assignee: Marko Kiiskila  (was: William San Filippo)

> Arduino Zero with Wifi Shield 101 failing on wifi start
> ---
>
> Key: MYNEWT-695
> URL: https://issues.apache.org/jira/browse/MYNEWT-695
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: BSP
>Affects Versions: v1_0_0_rel
>Reporter: Wanda Chiu
>Assignee: Marko Kiiskila
> Attachments: zero.patch
>
>
>  *wifi start* is failing when using arduino zero with arduino Wifi Shield 101 
> (See steps in tutorial: 
> https://mynewt.apache.org/latest/os/tutorials/wi-fi_on_arduino/)
> {code}
> wifi start
> wifi_init : -6
>   
> 151416:(APP)(ERR)[nm_drv_init][293][nmi start]: fail init bus
> ...
> {code}
> Marko looked into this and found that  hw/bsp/arduino_zero/syscfg.yml is 
> missing the following sysconfig definitions (see attached zero.patch).:
>  
> * *SPI_2*, 
> * *SPI_2_TYPE*, 
> * *SPI_3* 
> *  *SPI_3_TYPE* 
> Applying the attached zero.patch fixes the *wifi_init:-6* error, but 
> wifi_init seems to hang after that.



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

[jira] [Updated] (MYNEWT-695) Arduino Zero with Wifi Shield 101 failing on wifi start

[Sheela (JIRA)]

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

Sheela updated MYNEWT-695:
--
Fix Version/s: (was: v1_1_0_rel)

> Arduino Zero with Wifi Shield 101 failing on wifi start
> ---
>
> Key: MYNEWT-695
> URL: https://issues.apache.org/jira/browse/MYNEWT-695
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: BSP
>Affects Versions: v1_0_0_rel
>Reporter: Wanda Chiu
>Assignee: William San Filippo
> Attachments: zero.patch
>
>
>  *wifi start* is failing when using arduino zero with arduino Wifi Shield 101 
> (See steps in tutorial: 
> https://mynewt.apache.org/latest/os/tutorials/wi-fi_on_arduino/)
> {code}
> wifi start
> wifi_init : -6
>   
> 151416:(APP)(ERR)[nm_drv_init][293][nmi start]: fail init bus
> ...
> {code}
> Marko looked into this and found that  hw/bsp/arduino_zero/syscfg.yml is 
> missing the following sysconfig definitions (see attached zero.patch).:
>  
> * *SPI_2*, 
> * *SPI_2_TYPE*, 
> * *SPI_3* 
> *  *SPI_3_TYPE* 
> Applying the attached zero.patch fixes the *wifi_init:-6* error, but 
> wifi_init seems to hang after that.



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

[jira] [Commented] (MYNEWT-698) Unhandled exception in controller (in ble_ll_conn_end)

[Sheela (JIRA)]

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

Sheela commented on MYNEWT-698:
---

believed to be fixed

> Unhandled exception in controller (in ble_ll_conn_end)
> --
>
> Key: MYNEWT-698
> URL: https://issues.apache.org/jira/browse/MYNEWT-698
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Affects Versions: v1_0_0_rel
>Reporter: William San Filippo
>Assignee: William San Filippo
> Fix For: v1_1_0_rel
>
>
> The controller is generating an unhandled exception inside the function 
> ble_ll_conn_end().



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

[jira] [Commented] (MYNEWT-708) Lock scheduler during init

[Marko Kiiskila (JIRA)]

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

Marko Kiiskila commented on MYNEWT-708:
---

See https://issues.apache.org/jira/browse/MYNEWT-463

> Lock scheduler during init
> --
>
> Key: MYNEWT-708
> URL: https://issues.apache.org/jira/browse/MYNEWT-708
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Now that main() runs after the OS is started, tasks may preempt the main task 
> as soon as they are created.  If such a task expects all packages to have 
> been initialized, then a crash or other unpredictable behavior will occur.
> Here is an example crash that happens when the BLE link layer task runs 
> before the host package is fully initialized:
> {noformat}
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __assert_func (file=, line=, func= out>, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
> 137asm("bkpt");
> (gdb) whe
> #0  __assert_func (file=, line=, 
> func=, e=) at 
> kernel/os/src/arch/cortex_m4/os_fault.c:137
> #1  0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at 
> net/nimble/transport/ram/src/ble_hci_ram.c:91
> #2  0xea5e in ble_ll_hci_send_noop () at 
> net/nimble/controller/src/ble_ll_hci.c:106
> #3  0xa438 in ble_ll_task (arg=) at 
> net/nimble/controller/src/ble_ll.c:1008
> #4  0x in ?? ()
> {noformat}



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

[jira] [Updated] (MYNEWT-699) recreate linker files which show how to build olimex bsp to run from RAM

[Sheela (JIRA)]

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

Sheela updated MYNEWT-699:
--
Fix Version/s: v1_1_0_rel

> recreate linker files which show how to build olimex bsp to run from RAM
> 
>
> Key: MYNEWT-699
> URL: https://issues.apache.org/jira/browse/MYNEWT-699
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: v1_0_0_rel
>Reporter: Marko Kiiskila
>Assignee: Marko Kiiskila
> Fix For: v1_1_0_rel
>
>
> I removed them as unused, without realizing that our tutorials talk refer 
> them.



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

[jira] [Resolved] (MYNEWT-714) Add DC/DC regulator enable syscfg for nordic platforms

[Sheela (JIRA)]

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

Sheela resolved MYNEWT-714.
---
Resolution: Fixed

> Add DC/DC regulator enable syscfg for nordic platforms
> --
>
> Key: MYNEWT-714
> URL: https://issues.apache.org/jira/browse/MYNEWT-714
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Affects Versions: v1_0_0_rel
>Reporter: William San Filippo
>Assignee: William San Filippo
> Fix For: v1_1_0_rel
>
>
> The current controller code enables the LDO regulator and has no option to 
> enable the DC/DC regulator. This option should be added to the bsp for nordic 
> platforms as it saves a considerable amount of power.



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

[jira] [Updated] (MYNEWT-717) some nrf51 boards get into weird state when serial port is going through jtag USB

[Sheela (JIRA)]

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

Sheela updated MYNEWT-717:
--
Priority: Minor  (was: Major)

> some nrf51 boards get into weird state when serial port is going through jtag 
> USB
> -
>
> Key: MYNEWT-717
> URL: https://issues.apache.org/jira/browse/MYNEWT-717
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>Priority: Minor
>
> See discussion on:
> https://github.com/apache/incubator-mynewt-core/pull/198
> Specifically BBC Microbit, RedBear Nano exhibit this behaviour.



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

[jira] [Assigned] (MYNEWT-720) Newt: manipulate image signatures

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-720:
-

Assignee: Marko Kiiskila  (was: Sterling Hughes)

> Newt: manipulate image signatures
> -
>
> Key: MYNEWT-720
> URL: https://issues.apache.org/jira/browse/MYNEWT-720
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Affects Versions: v1_0_0_rel
>Reporter: Simon Ratner
>Assignee: Marko Kiiskila
>Priority: Minor
>
> Ability to manipulate image signatures should be independent of creating the 
> image. Suggesting a new command:
> {noformat}
> newt sign-image  
> {noformat}
> Useful operations:
> * strip a signature from an existing image,
> * sign an existing unsigned image,
> * re-sign an existing image with a different key.
> In all cases, the rest of the image besides the signature should remain 
> byte-for-byte identical.
> Motivating use cases:
> * dev images are promoted to qa, prod; qa and prod keys are kept separate, 
> but the promoted image should not be rebuilt from source, to eliminate any 
> possibility that an untested configuration is deployed due to differences in 
> build environment.
> * distinct keys for different customers, used to sign the same image.



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

[jira] [Resolved] (MYNEWT-730) Add ruuvi tag rev B bsp

[Sheela (JIRA)]

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

Sheela resolved MYNEWT-730.
---
Resolution: Fixed

> Add ruuvi tag rev B bsp
> ---
>
> Key: MYNEWT-730
> URL: https://issues.apache.org/jira/browse/MYNEWT-730
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Affects Versions: v1_0_0_rel
>Reporter: William San Filippo
>Assignee: William San Filippo
> Fix For: v1_1_0_rel
>
> Attachments: ruuvitag_revb4_schema.pdf
>
>
> Add bsp for ruuvi tag rev B (rev B3 or B4; not sure if it will work for other 
> revisions of the tag).



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

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

[Marko Kiiskila (JIRA)]

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

Marko Kiiskila commented on MYNEWT-733:
---

Jacob, is this issue still pending, or were you able to figure this one out?

> 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] [Assigned] (MYNEWT-738) Fix Parameter arrays in events and elsewhere

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-738:
-

Assignee: William San Filippo

> Fix Parameter arrays in events and elsewhere
> 
>
> Key: MYNEWT-738
> URL: https://issues.apache.org/jira/browse/MYNEWT-738
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Affects Versions: v1_0_0_rel
>Reporter: William San Filippo
>Assignee: William San Filippo
> Fix For: v1_1_0_rel
>
>
> It appears that for some events and possible commands that the specification 
> was interpreted incorrectly. Multiple parameter arrays are treated in the 
> following manner:
> Arrayed parameters are specified using the following notation: ParameterA[i]. 
> If more than one set of arrayed parameters are specified (e.g. ParameterA[i], 
> ParameterB[i]), then the order of the parameters are as follows: 
> ParameterA[0], ParameterB[0], ParameterA[1], ParameterB[1], ParameterA[2], 
> ParameterB[2], … ParameterA[n], ParameterB[n]
> Need to go through the controller and host code to fix all places where this 
> is incorrect.



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

[jira] [Updated] (MYNEWT-742) OIC requires some manual steps to initialize

[Sheela (JIRA)]

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

Sheela updated MYNEWT-742:
--
Fix Version/s: (was: v1_1_0_rel)

> OIC requires some manual steps to initialize
> 
>
> Key: MYNEWT-742
> URL: https://issues.apache.org/jira/browse/MYNEWT-742
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>Assignee: Christopher Collins
>
> E.g.,
> {noformat}
> static const oc_handler_t omgr_oc_handler = {
> .init = omgr_app_init,
> };
> int
> main(int argc, char **argv)
> {
> /* ... */
> oc_main_init((oc_handler_t *)_oc_handler);
> oc_ble_coap_gatt_srv_init();
> }
> {noformat}
> If possible, it would be good if these calls happened automatically when the 
> OS starts.  Unfortunately, the user will still need to configure the library 
> with an oc_handler.



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

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

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-749:
-

Assignee: Szymon Janc

> BLE Host - Crash during key persistence if key-dist settings are 0
> --
>
> Key: MYNEWT-749
> URL: https://issues.apache.org/jira/browse/MYNEWT-749
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Reporter: Christopher Collins
>Assignee: Szymon Janc
> Fix For: v1_1_0_rel
>
>
> If BLE_SM_BONDING is enabled, but one of the the following settings is 0:
> * BLE_SM_OUR_KEY_DIST
> * BLE_SM_THEIR_KEY_DIST
> then Mynewt crashes when pairing completes.  Here is an example stack trace:
> {noformat}
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0, 
> e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
> 137asm("bkpt");
> (gdb) whe
> #0  __assert_func (file=file@entry=0x0, line=line@entry=0, 
> func=func@entry=0x0, e=e@entry=0x0) at 
> kernel/os/src/arch/cortex_m4/os_fault.c:137
> #1  0x000181f8 in ble_store_persist_sec (obj_type=, 
> value_sec=) at net/nimble/host/src/ble_store.c:92
> #2  0x000177ca in ble_sm_persist_keys (proc=0x181f9 
> ) at net/nimble/host/src/ble_sm.c:565
> #3  ble_sm_process_result (conn_handle=conn_handle@entry=1, 
> res=res@entry=0x2000165c ) at 
> net/nimble/host/src/ble_sm.c:860
> #4  0x0001792c in ble_sm_enc_event_rx (conn_handle=, 
> evt_status=, encrypted=1) at net/nimble/host/src/ble_sm.c:1042
> #5  0x00017942 in ble_sm_enc_change_rx (evt=evt@entry=0x20001698 
> ) at net/nimble/host/src/ble_sm.c:1051
> #6  0x000153be in ble_hs_hci_evt_encrypt_change (event_code=, 
> data=0x20004c20 "\b\004", len=) at 
> net/nimble/host/src/ble_hs_hci_evt.c:163
> #7  0x00015438 in ble_hs_hci_evt_process (data=0x20004c20 "\b\004") at 
> net/nimble/host/src/ble_hs_hci_evt.c:593
> #8  0x9016 in os_eventq_run (evq=) at 
> kernel/os/src/os_eventq.c:172
> #9  0x879e in main () at apps/bleprph/src/main.c:301
> {noformat}



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

[jira] [Updated] (MYNEWT-752) Error in setting the "permanent" flag upon confirm with hash during image upgrade

[Sheela (JIRA)]

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

Sheela updated MYNEWT-752:
--
Fix Version/s: v1_1_0_rel

> Error in setting the "permanent" flag upon confirm with hash during image 
> upgrade
> -
>
> Key: MYNEWT-752
> URL: https://issues.apache.org/jira/browse/MYNEWT-752
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Aditi Hilbert
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> This is an issue seen during image upgrade. When doing  a "confirm" with a 
> hash, newtmgr always marks the "permanent" flag for Slot 1 image to "true", 
> irrespective of which image the hash matches.
> This works fine when we skip the "test" step during image upgrade and we 
> issue a "confirm" with a hash of the new image in Slot 1. 
> However, if we do the "test" step (when the new image is swapped into Slot 
> 0), and we then do a "confirm" with a hash of the new image and reboot, the 
> device marks the old image in Slot 1 as "permanent" and swaps it back to Slot 
> 0. 



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

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

[Sheela (JIRA)]

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

Sheela updated MYNEWT-755:
--
Fix Version/s: v1_1_0_rel

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

[jira] [Resolved] (MYNEWT-754) BLE Host - Store management API additions

[Sheela (JIRA)]

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

Sheela resolved MYNEWT-754.
---
Resolution: Fixed

> BLE Host - Store management API additions
> -
>
> Key: MYNEWT-754
> URL: https://issues.apache.org/jira/browse/MYNEWT-754
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The store API supports all the necessary operations: read, write, and delete. 
>  However, some convenience functions are sorely lacking:
> * Retrieve list of bonded peers
> * Delete bond



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

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

[Sheela (JIRA)]

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

Sheela reassigned MYNEWT-755:
-

Assignee: Christopher Collins  (was: Sterling Hughes)

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

[jira] [Closed] (MYNEWT-41) Improve regression test coverage

[Sheela (JIRA)]

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

Sheela closed MYNEWT-41.

Resolution: Won't Fix

Too broad

> Improve regression test coverage
> 
>
> Key: MYNEWT-41
> URL: https://issues.apache.org/jira/browse/MYNEWT-41
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: Baselibc, Bootloader, BSP, Flash, HAL, Image Mgmt, JSON, 
> Misc, NFFS, Nimble, OS
>Reporter: Sterling Hughes
>Assignee: Peter Snyder
>Priority: Blocker
>
> We need a push behind regression test coverage for nearly every component.  
> NFFS and Nimble host are pretty good, but the rest have sadly large gaps in 
> regression testing. 
> I think a couple of rules prior to release would make sense: 
> 1- Every package must have at least 1 regression test.
> 2- The libs/os and hw/hal packages should have every API covered by 
> regression tests (anything in tadpole)
> 3- We should have a picture of regression test coverage prior to release via 
> some sort of automated tool. 



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