[jira] [Created] (MYNEWT-789) Add driver for Ruuvi Tag LIS2DH12 3-axis accelerometer

2017-06-21 Thread Sheela (JIRA)
Sheela created MYNEWT-789:
-

 Summary: Add driver for Ruuvi Tag LIS2DH12 3-axis accelerometer
 Key: MYNEWT-789
 URL: https://issues.apache.org/jira/browse/MYNEWT-789
 Project: Mynewt
  Issue Type: New Feature
  Security Level: Public (Viewable by anyone)
  Components: Drivers
Reporter: Sheela
Assignee: Vipul Rahane
 Fix For: v1_1_0_rel


Add driver support for the LIS2DH12 3-axis accelerometer



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


[jira] [Resolved] (MYNEWT-450) Enable extensible module ID and matching names for log messages

2017-06-05 Thread 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] [Resolved] (MYNEWT-456) boot loader serial image upgrade needs to use CBOR

2017-06-05 Thread Sheela (JIRA)

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

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

> boot loader serial image upgrade needs to use CBOR
> --
>
> Key: MYNEWT-456
> URL: https://issues.apache.org/jira/browse/MYNEWT-456
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>Affects Versions: v1_0_0_beta1
>Reporter: Marko Kiiskila
>




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


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

2017-06-05 Thread 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-462) Nimble controller when acting as master will send a connect request to an already connected peripheral

2017-06-05 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-462:
-

Assignee: Szymon Janc  (was: William San Filippo)

> Nimble controller when acting as master will send a connect request to an 
> already connected peripheral
> --
>
> Key: MYNEWT-462
> URL: https://issues.apache.org/jira/browse/MYNEWT-462
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Affects Versions: v0_9_0
>Reporter: William San Filippo
>Assignee: Szymon Janc
>
> The nimble controller, when acting as a master, will attempt to send a 
> connection request to a peripheral to which it is already connected. The 
> nimble controller, when acting as a peripheral, will deny the connect request 
> from a master to which it is already connected, so it is only an issue with 
> the controller when it is acting as a master.



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


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

2017-06-05 Thread 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] [Updated] (MYNEWT-477) newt - Split image requires split startup .s file to be in BSP package

2017-06-05 Thread Sheela (JIRA)

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

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

> newt - Split image requires split startup .s file to be in BSP package
> --
>
> Key: MYNEWT-477
> URL: https://issues.apache.org/jira/browse/MYNEWT-477
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Reporter: Christopher Collins
>Assignee: Sterling Hughes
>
> It would be better if all the startup code could go in the MCU package.  If 
> the split startup file is put in the MCU package, a split image build results 
> in an empty second-slot image and the following warning:
> {noformat}
> arm-none-eabi/bin/ld: warning: cannot find entry symbol Reset_Handler_split; 
> defaulting to 00042020
> {noformat}
> Newt thinks the second-stage app uses no symbols from the MCU package, so it 
> doesn't include the MCU .a file in the final link phace.  The app does use a 
> symbol from the MCU app; namely Reset_Handler_split.  This symbol is 
> designated as the entry point in the split linker script, but not referenced 
> anywhere else.
> The reason newt doesn't honor the linker script's reference to 
> Reset_Handler_split has to do with the way it builds split images.  Before 
> performing the final link of the second-stage app, newt performs some "test 
> links" to determine which packages and symbols are shared among the two apps. 
>  The test links are done using the regular stage 1 (loader) linker script.  
> Hence, newt determines early that the second-stage app does not reference the 
> MCU package at all.
> This problem does not occur when the split startup code is in the BSP 
> package, because the second-stage app directly calls BSP functions in main(), 
> namely bsp_init() (called via sysinit()).  Therefore, newt recognizes that 
> the app depends on the BSP package, and includes this package in the final 
> link phase.



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


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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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] [Resolved] (MYNEWT-505) Fix compiler errors when using Clang in native MacOS environment

2017-06-05 Thread Sheela (JIRA)

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

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

> Fix compiler errors when using Clang in native MacOS environment
> 
>
> Key: MYNEWT-505
> URL: https://issues.apache.org/jira/browse/MYNEWT-505
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Misc
>Affects Versions: v1_1_0_rel
> Environment: unit tests running in native MacOS
>Reporter: Peter Snyder
>Assignee: Peter Snyder
>
> When running "newt test all" with native Clang compiler on MacOS, several 
> compiler errors prevented builds and testing. This includes several logic 
> bugs as well as unused functions and mis-cast arguments.
> Fixes should be tested with gcc-5, gcc-6 and Clang.



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

2017-06-05 Thread 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] [Commented] (MYNEWT-544) Cannot over-ride UART Pins in sys cfg.yml

2017-06-05 Thread Sheela (JIRA)

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

Sheela commented on MYNEWT-544:
---

David, is this still a problem?  If it is, can you show project syscfg.yml in 
full?



> Cannot over-ride UART Pins in sys cfg.yml
> -
>
> Key: MYNEWT-544
> URL: https://issues.apache.org/jira/browse/MYNEWT-544
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: drivers
>Affects Versions: v1_0_0_beta1
> Environment: Mac OS Sierra, latest develop branch of newt, mynewt-core
>Reporter: David G. Simmons
>
> From my project's syscfg.yml:
> UART_0_PIN_TX:
> description: 'New Pin Assignment'
> value: 23
> UART_0_PIN_RX:
> description: 'New Pin Assignment'
> value: 24
> Results in newt target config show air_q:
> * Setting: UART_0_PIN_RX
> * Description: TBD
> * Value:
> * Overridden: targets/air_q, default=5
>   * Setting: UART_0_PIN_TX
> * Description: TBD
> * Value:
> * Overridden: targets/air_q, default=6
> So it picks up that the value was overridden, but it doesn't pick up the 
> actual value.



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


[jira] [Assigned] (MYNEWT-546) Can't compile unittest on Windows

2017-06-05 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-546:
-

Assignee: Wanda Chiu

> Can't compile unittest on Windows
> -
>
> Key: MYNEWT-546
> URL: https://issues.apache.org/jira/browse/MYNEWT-546
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Misc
>Affects Versions: v1_0_0_beta1, v1_0_0_beta2
> Environment: Win10, msys2
>Reporter: Simon Ratner
>Assignee: Wanda Chiu
>
> The following are problematic:
> *pty*
> Needed by hal_uart; assuming one doesn't need UART, hal_uart.c can be 
> commented out in its entirety. Would be nice to be able to set a syscfg flag 
> to disable certain bits of the hal package, such as hal_uart.
> *signals*
> All of kill / sigsetjmp / siglongjmp / etc.



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

2017-06-05 Thread 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] [Updated] (MYNEWT-550) ble_gattc_indicate_custom to parallel ble_gattc_notify_custom

2017-06-05 Thread Sheela (JIRA)

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

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

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

2017-06-05 Thread 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] [Closed] (MYNEWT-561) CONFIG_FCB_VERSION syscfg value should be configurable

2017-06-05 Thread Sheela (JIRA)

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

Sheela closed MYNEWT-561.
-
Resolution: Won't Fix

Version number is associated with the way data is formatted to the flash.  Its 
not the version number for the data but is the version number for the code 
which writes the data.  It should not be user configurable.

> CONFIG_FCB_VERSION syscfg value should be configurable
> --
>
> Key: MYNEWT-561
> URL: https://issues.apache.org/jira/browse/MYNEWT-561
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Sysinit
>Affects Versions: v1_0_0_beta1, v1_0_0_beta2
>Reporter: Simon Ratner
>
> sys/config exports CONFIG_FCB_MAGIC in syscfg (although see MYNEWT-560), but 
> not CONFIG_FCB_VERSION, which is always hard-coded to 1.



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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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.

2017-06-05 Thread 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

2017-06-05 Thread 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] [Updated] (MYNEWT-681) remove flash write protection in download script for nano2

2017-06-05 Thread Sheela (JIRA)

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

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

> remove flash write protection in download script for nano2
> --
>
> Key: MYNEWT-681
> URL: https://issues.apache.org/jira/browse/MYNEWT-681
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
> Fix For: v1_1_0_rel
>
>
> Nano2 comes with flash write protected for bootloader area. We should remove 
> this protection before trying to update the flash contents.



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


[jira] [Assigned] (MYNEWT-681) remove flash write protection in download script for nano2

2017-06-05 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-681:
-

Assignee: Vipul Rahane

> remove flash write protection in download script for nano2
> --
>
> Key: MYNEWT-681
> URL: https://issues.apache.org/jira/browse/MYNEWT-681
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>Assignee: Vipul Rahane
> Fix For: v1_1_0_rel
>
>
> Nano2 comes with flash write protected for bootloader area. We should remove 
> this protection before trying to update the flash contents.



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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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)

2017-06-05 Thread Sheela (JIRA)

[ 
https://issues.apache.org/jira/browse/MYNEWT-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (MYNEWT-698) Unhandled exception in controller (in ble_ll_conn_end)

2017-06-05 Thread Sheela (JIRA)

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

Sheela resolved MYNEWT-698.
---
Resolution: 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] [Updated] (MYNEWT-699) recreate linker files which show how to build olimex bsp to run from RAM

2017-06-05 Thread 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] [Assigned] (MYNEWT-708) Lock scheduler during init

2017-06-05 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-708:
-

Assignee: Christopher Collins

> 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] [Resolved] (MYNEWT-701) Low power timer support for nimble controller

2017-06-05 Thread Sheela (JIRA)

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

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

> Low power timer support for nimble controller
> -
>
> Key: MYNEWT-701
> URL: https://issues.apache.org/jira/browse/MYNEWT-701
> 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
>
>
> Add low power timer support for the nimble controller.



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


[jira] [Resolved] (MYNEWT-707) Add API to retrieve public and static random addresses from chip specific locations

2017-06-05 Thread Sheela (JIRA)

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

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

> Add API to retrieve public and static random addresses from chip specific 
> locations
> ---
>
> Key: MYNEWT-707
> URL: https://issues.apache.org/jira/browse/MYNEWT-707
> 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
>
>
> This ticket will add API to retrieve a public address and random static 
> address from "chip specific" locations. Here are the API and how they will 
> work for the nordic chips, which are currently the only supported BLE chips. 
> This ticket does not address storing/retrieving these values from flash or 
> configuration areas.
> 1) The ble_hw_get_public_addr function will do the following:
> * If the user has overridden the default public address (the syscfg variable) 
> with a non-zero public address, that address will be returned by this 
> function.
> * If the default public address in the syscfg is all zero, the code will read 
> FICR and check if the device address type in the FICR is public. If so, it 
> means the nordic chip was factory programmed with a public address and this 
> will be used.
> * If both of the above checks fail, the code will read UICR[0] and UICR[1] to 
> see if a public address has been programmed into the UICR. We are doing this 
> to make it easy for folks to program their development kits with public 
> addresses so they do not have to hardcode them. UICR[0] will contain the 
> least significant 4 bytes of the device address. UICR[1] will contain the 
> most significant two bytes. The upper 16 bits of this word should be set to 
> 0. The API will presume that this is a valid public device address as long as 
> the upper 16-bits of this 32-bit word are all zero. We will also check to see 
> if this is a valid public address (see below). If both UICR[0] and UICR[1] 
> are zero, this will not be considered a valid public address.
> 2) The ble_hw_get_static_addr() will do the following:
> * Read the FICR to see if there is a random address in the FICR. This is the 
> default programming of the nrf51dk and nrf52dk. Unless you have them program 
> a public device address in the FICR, it will have a random address.
> * If the chip does not have a random address the API returns -1.
> * If the chip has a random address the upper two bits will be set to 1 (which 
> denotes random static address).



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


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

2017-06-05 Thread 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] [Assigned] (MYNEWT-717) some nrf51 boards get into weird state when serial port is going through jtag USB

2017-06-05 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-717:
-

Assignee: Marko Kiiskila

> 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
>Assignee: 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] [Updated] (MYNEWT-717) some nrf51 boards get into weird state when serial port is going through jtag USB

2017-06-05 Thread 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

2017-06-05 Thread 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] [Updated] (MYNEWT-720) Newt: manipulate image signatures

2017-06-05 Thread Sheela (JIRA)

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

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

> 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: Sterling Hughes
>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-726) Modify how controller handles terminate control procedure

2017-06-05 Thread Sheela (JIRA)

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

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

> Modify how controller handles terminate control procedure
> -
>
> Key: MYNEWT-726
> URL: https://issues.apache.org/jira/browse/MYNEWT-726
> 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
>
> Attachments: ruuvitag_revb4_schema.pdf
>
>
> The terminate control procedure can occur while other control procedures are 
> in process. The way the controller currently handles this causes some extra 
> checks in the code and can be handled better.



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


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

2017-06-05 Thread 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] [Assigned] (MYNEWT-733) newtmgr image upload crashes on nrf51 devices

2017-06-05 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-733:
-

Assignee: Christopher Collins  (was: Sterling Hughes)

> 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-737) Make ble_hci_uart_tx_char more efficient

2017-06-05 Thread Sheela (JIRA)

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

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

> Make ble_hci_uart_tx_char more efficient
> 
>
> Key: MYNEWT-737
> URL: https://issues.apache.org/jira/browse/MYNEWT-737
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>Affects Versions: v1_1_0_rel, v1_0_0_rel
>Reporter: William San Filippo
> Fix For: v1_1_0_rel
>
>
> Recently there was a bug fixed in ble_hci_uart_tx_char(). The original code 
> assumed a single mbuf but now that we have mbuf chains, the code could 
> probably be made more efficient, as using os_mbuf_copydata and os_mbuf_adj() 
> is a bit heavyweight for single mbuf copies



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


[jira] [Assigned] (MYNEWT-738) Fix Parameter arrays in events and elsewhere

2017-06-05 Thread 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

2017-06-05 Thread 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 *)&omgr_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] [Commented] (MYNEWT-746) Sim - Floating point calculations sometimes incorrect

2017-06-05 Thread Sheela (JIRA)

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

Sheela commented on MYNEWT-746:
---

 Need to document in release notes

> Sim - Floating point calculations sometimes incorrect
> -
>
> Key: MYNEWT-746
> URL: https://issues.apache.org/jira/browse/MYNEWT-746
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> *Note: this problem does not occur in OS X; it has only been seen in Linux.*
> In sim, some floating point calculations yield wildly incorrect results 
> (usually 0 or NaN).  The cause appears to be that the floating point 
> registers are not restored when longjmp() is called.  If subsequent code 
> tries to use an intermediate value stored in a floating point register, the 
> result is indeterminate.
> There is a gcc / clang compiler option which mostly solves this problem: 
> *-ffloat-store*:
> {quote}
> -ffloat-store
> Do not store floating point variables in registers, and inhibit other 
> options that might change whether a floating point value is taken from a 
> register or memory.
> This option prevents undesirable excess precision on machines such as the 
> 68000 where the floating registers (of the 68881) keep more precision than a 
> double is supposed to have. Similarly for the x86 architecture. For most 
> programs, the excess precision does only good, but a few programs rely on the 
> precise definition of IEEE floating point. Use -ffloat-store for such 
> programs, after modifying them to store all pertinent intermediate 
> computations into variables. 
> {quote}
> The problems disappeared when I started using this option.  However, it seems 
> there is still the occasional miscalculation, as a test failure just occurred 
> due to an incorrect floating point value.  In this case, assigning {{18.0}} 
> to an int yielded the value {{-2147483648}}.



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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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

2017-06-05 Thread 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] [Updated] (MYNEWT-756) mpstats (on nrf51) hangs indefinately

2017-06-05 Thread Sheela (JIRA)

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

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

> 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 
> Packet:buf::eecmin?wble_l2cap_sig_proc_pool?fblksizenblksenfreecmin?xle_att_svr_prep_entry_pool?fblksiz
>   
>   

[jira] [Closed] (MYNEWT-467) Create template syscfg.yml file when creating new target

2017-06-05 Thread Sheela (JIRA)

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

Sheela closed MYNEWT-467.
-
Resolution: Won't Fix

Can be done via Command line

> Create template syscfg.yml file when creating new target
> 
>
> Key: MYNEWT-467
> URL: https://issues.apache.org/jira/browse/MYNEWT-467
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Paul Dietrich
>Priority: Critical
>
> It would be nice it newt created a syscfg/yml file with the sys cfg.vals 
> entry so that its clear to users how to add/override sys cfg values in the 
> target.



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


[jira] [Resolved] (MYNEWT-516) add "last" flag to logs show command in newtmgr

2017-06-05 Thread Sheela (JIRA)

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

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

> add "last" flag to logs show  command in newtmgr
> --
>
> Key: MYNEWT-516
> URL: https://issues.apache.org/jira/browse/MYNEWT-516
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>  Components: Newtmgr, OS
>Affects Versions: v0_8_0_beta1
>Reporter: Peter Snyder
>Assignee: Peter Snyder
>Priority: Critical
> Fix For: v0_8_0_beta2
>
>
> It's a pain to go through successive calls to show log in order to simply 
> read the last log record. Add a "last" keyword to be used in place of a 
> timestamp which simply returns the last record of the specified log.



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


[jira] [Assigned] (MYNEWT-769) newtmgr over HCI

2017-06-05 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-769:
-

Assignee: Szymon Janc

> newtmgr over HCI
> 
>
> Key: MYNEWT-769
> URL: https://issues.apache.org/jira/browse/MYNEWT-769
> Project: Mynewt
>  Issue Type: New Feature
>  Security Level: Public(Viewable by anyone) 
>Reporter: Marko Kiiskila
>Assignee: Szymon Janc
>Priority: Critical
> Fix For: v1_1_0_rel
>
>
> newtmgr over HCI would be useful. This we could use to monitor the state and 
> do firmware upgrades from host side when mynewt is running as controller only.



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


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

2017-06-05 Thread 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)


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

2017-06-02 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-756:
-

Assignee: Christopher Collins  (was: Sterling Hughes)

> 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
>
> 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 
> Packet:buf::eecmin?wble_l2cap_sig_proc_pool?fblksizenblksenfreecmin?xle_att_svr_prep_entry_pool?fblksiz
>   
>

[jira] [Assigned] (MYNEWT-746) Sim - Floating point calculations sometimes incorrect

2017-06-02 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-746:
-

Assignee: Christopher Collins

> Sim - Floating point calculations sometimes incorrect
> -
>
> Key: MYNEWT-746
> URL: https://issues.apache.org/jira/browse/MYNEWT-746
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> *Note: this problem does not occur in OS X; it has only been seen in Linux.*
> In sim, some floating point calculations yield wildly incorrect results 
> (usually 0 or NaN).  The cause appears to be that the floating point 
> registers are not restored when longjmp() is called.  If subsequent code 
> tries to use an intermediate value stored in a floating point register, the 
> result is indeterminate.
> There is a gcc / clang compiler option which mostly solves this problem: 
> *-ffloat-store*:
> {quote}
> -ffloat-store
> Do not store floating point variables in registers, and inhibit other 
> options that might change whether a floating point value is taken from a 
> register or memory.
> This option prevents undesirable excess precision on machines such as the 
> 68000 where the floating registers (of the 68881) keep more precision than a 
> double is supposed to have. Similarly for the x86 architecture. For most 
> programs, the excess precision does only good, but a few programs rely on the 
> precise definition of IEEE floating point. Use -ffloat-store for such 
> programs, after modifying them to store all pertinent intermediate 
> computations into variables. 
> {quote}
> The problems disappeared when I started using this option.  However, it seems 
> there is still the occasional miscalculation, as a test failure just occurred 
> due to an incorrect floating point value.  In this case, assigning {{18.0}} 
> to an int yielded the value {{-2147483648}}.



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


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

2017-06-02 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-757:
-

Assignee: Aditi Hilbert  (was: Sterling Hughes)

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



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


[jira] [Assigned] (MYNEWT-758) BLE Host - OOB security for SC

2017-06-02 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-758:
-

Assignee: Szymon Janc

> BLE Host - OOB security for SC
> --
>
> Key: MYNEWT-758
> URL: https://issues.apache.org/jira/browse/MYNEWT-758
> 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
>
>




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


[jira] [Resolved] (MYNEWT-686) Fix tutorial description @ https://mynewt.apache.org/latest/os/tutorials/bleprph/bleprph-app/

2017-05-12 Thread Sheela (JIRA)

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

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

Fixed in current docs

> Fix tutorial description @ 
> https://mynewt.apache.org/latest/os/tutorials/bleprph/bleprph-app/
> -
>
> Key: MYNEWT-686
> URL: https://issues.apache.org/jira/browse/MYNEWT-686
> Project: Mynewt
>  Issue Type: Bug
>Reporter: Arek Lichwa
>Priority: Trivial
>
> in build BLE peripheral package/binary tutorial @ 
> https://mynewt.apache.org/latest/os/tutorials/bleprph/bleprph-app/ in "Create 
> a New Target" section shouldn't be when getting to build step iteration 
> "$newt build blerph" -> "$newt build myperiph" ?



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


[jira] [Assigned] (MYNEWT-686) Fix tutorial description @ https://mynewt.apache.org/latest/os/tutorials/bleprph/bleprph-app/

2017-05-12 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-686:
-

Assignee: Wanda Chiu

> Fix tutorial description @ 
> https://mynewt.apache.org/latest/os/tutorials/bleprph/bleprph-app/
> -
>
> Key: MYNEWT-686
> URL: https://issues.apache.org/jira/browse/MYNEWT-686
> Project: Mynewt
>  Issue Type: Bug
>Reporter: Arek Lichwa
>Assignee: Wanda Chiu
>Priority: Trivial
> Fix For: v1_1_0_rel
>
>
> in build BLE peripheral package/binary tutorial @ 
> https://mynewt.apache.org/latest/os/tutorials/bleprph/bleprph-app/ in "Create 
> a New Target" section shouldn't be when getting to build step iteration 
> "$newt build blerph" -> "$newt build myperiph" ?



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


[jira] [Updated] (MYNEWT-686) Fix tutorial description @ https://mynewt.apache.org/latest/os/tutorials/bleprph/bleprph-app/

2017-05-12 Thread Sheela (JIRA)

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

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

> Fix tutorial description @ 
> https://mynewt.apache.org/latest/os/tutorials/bleprph/bleprph-app/
> -
>
> Key: MYNEWT-686
> URL: https://issues.apache.org/jira/browse/MYNEWT-686
> Project: Mynewt
>  Issue Type: Bug
>Reporter: Arek Lichwa
>Priority: Trivial
> Fix For: v1_1_0_rel
>
>
> in build BLE peripheral package/binary tutorial @ 
> https://mynewt.apache.org/latest/os/tutorials/bleprph/bleprph-app/ in "Create 
> a New Target" section shouldn't be when getting to build step iteration 
> "$newt build blerph" -> "$newt build myperiph" ?



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


[jira] [Updated] (MYNEWT-659) Bluetooth 5 support

2017-05-12 Thread Sheela (JIRA)

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

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

> Bluetooth 5 support
> ---
>
> Key: MYNEWT-659
> URL: https://issues.apache.org/jira/browse/MYNEWT-659
> Project: Mynewt
>  Issue Type: New Feature
>  Components: ble, Nimble
>Reporter: Szymon Janc
>Assignee: Szymon Janc
> Fix For: v1_1_0_rel
>
>
> Bluetooth 5 specifications was released December 2016 and we should start 
> adding new features from it.
> Relevant new features include (and if related for controller, host or both):
> - LE Channel Selection Algorithm #2 [controller]
> - LE Advertising Extensions  [controller and host]
> - Privacy Erratas [controller and host]
> - 2 Mbit for LE  [controller and host, new PHY required - nRF52840 should do)]
> - LE Long Range [controller and host, new PHY required - nRF52840 should do)]
> - High Duty Cycle Non-Connectable Advertising [controller and host]
> I put them in tentative (based on strong feelings:) importance order.



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


[jira] [Updated] (MYNEWT-682) stm32f767-nucleo build warning

2017-05-12 Thread Sheela (JIRA)

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

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

> stm32f767-nucleo build warning
> --
>
> Key: MYNEWT-682
> URL: https://issues.apache.org/jira/browse/MYNEWT-682
> Project: Mynewt
>  Issue Type: Bug
>Reporter: Marko Kiiskila
>Assignee: Fabio Utzig
> Fix For: v1_1_0_rel
>
>
> targets/slinky_767
> app=@apache-mynewt-core/apps/slinky
> bsp=@apache-mynewt-core/hw/bsp/stm32f767-nucleo
> build_profile=debug
> [marko@IsMyLaptop:~/src8/incubator-mynewt-blinky]$ newt run slinky_767 4
> Compiling bin/targets/slinky_767/generated/src/slinky_767-sysinit-app.c
> Archiving slinky_767-sysinit-app.a
> Linking 
> /Users/marko/src8/incubator-mynewt-blinky/bin/targets/slinky_767/app/apps/slinky/slinky.elf
> App image succesfully generated: 
> /Users/marko/src8/incubator-mynewt-blinky/bin/targets/slinky_767/app/apps/slinky/slinky.img
> * Warning: target does not define MCU_FLASH_MIN_WRITE_SIZE setting; assuming 
> a value of 1.



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


[jira] [Updated] (MYNEWT-689) CONSOLE_UART syscfg value

2017-05-12 Thread Sheela (JIRA)

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

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

> CONSOLE_UART syscfg value
> -
>
> Key: MYNEWT-689
> URL: https://issues.apache.org/jira/browse/MYNEWT-689
> Project: Mynewt
>  Issue Type: Bug
>  Components: BSP
>Affects Versions: v1_0_0_rel
>Reporter: Simon Ratner
>Assignee: William San Filippo
> Fix For: v1_1_0_rel
>
>
> Currently CONSOLE_UART is hard-coded in bsp/bsp.h.
> It would be better as a syscfg value, so that switching the console to UART1, 
> for example, didn't require modifying the bsp.



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


[jira] [Assigned] (MYNEWT-692) Add support for ethernet communication

2017-05-12 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-692:
-

Assignee: Marko Kiiskila

> Add support for ethernet communication
> --
>
> Key: MYNEWT-692
> URL: https://issues.apache.org/jira/browse/MYNEWT-692
> Project: Mynewt
>  Issue Type: Task
>  Components: drivers
>Reporter: Fabio Utzig
>Assignee: Marko Kiiskila
>Priority: Minor
>  Labels: gsoc2017
>
> Mynewt needs to have an Ethernet low-level layer driver/hal definition. 
> Beyond proposing/discussing/defining how it needs to work, drivers should be 
> added to the two most common ethernet supporting chips: K-64F and STM32Fxxx. 
> Target BSPs that could make use of this are K-64F, STM32F767-Nucleo, 
> STM32F429-Discovery and Olimex STM32-E407.
> PS: All STM32Fxxx based boards probably use the same enet peripheral which 
> means one driver should suit them all!



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

2017-05-12 Thread 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: 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
>  Components: BSP
>Affects Versions: v1_0_0_rel
>Reporter: Wanda Chiu
>Assignee: William San Filippo
> Fix For: v1_1_0_rel
>
> 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] [Closed] (MYNEWT-704) Risk Analysis and more white Box and Regression testing on Mynewt OS

2017-05-12 Thread Sheela (JIRA)

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

Sheela closed MYNEWT-704.
-
Resolution: Fixed

> Risk Analysis and more white Box and Regression testing on Mynewt OS
> 
>
> Key: MYNEWT-704
> URL: https://issues.apache.org/jira/browse/MYNEWT-704
> Project: Mynewt
>  Issue Type: Task
>Reporter: Nges Brian
>Priority: Minor
>  Labels: gsoc2017
>
> This Project is based on testing and risk analysis.
> Due to the increase in the code base of the Mynewt OS, there is the fear that 
> some code might not be obeying the standard of coding in the the OS or might 
> be omitting certain conditions that present as threats to the stability, 
> security, or performance of the code.
> Secondly, New modules keep adding to the Mynewt OS everyday such as Tinycbor 
> without automated testing.
> For the above reasons, we need someone who will be able to run risk analyses 
> on most parts of the OS , correct any errors if found and also write some 
> automated testing for modules which do not yet have on the Mynewt OS.



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


[jira] [Updated] (MYNEWT-715) LE Extended Advertising

2017-05-12 Thread Sheela (JIRA)

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

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

>  LE Extended Advertising
> 
>
> Key: MYNEWT-715
> URL: https://issues.apache.org/jira/browse/MYNEWT-715
> Project: Mynewt
>  Issue Type: Sub-task
>  Components: ble, Nimble
>Reporter: Szymon Janc
>Assignee: Szymon Janc
> Fix For: v1_1_0_rel
>
>




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


[jira] [Updated] (MYNEWT-716) LE Periodic Advertising

2017-05-12 Thread Sheela (JIRA)

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

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

>  LE Periodic Advertising
> 
>
> Key: MYNEWT-716
> URL: https://issues.apache.org/jira/browse/MYNEWT-716
> Project: Mynewt
>  Issue Type: Sub-task
>  Components: ble, Nimble
>Reporter: Szymon Janc
> Fix For: v1_1_0_rel
>
>




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


[jira] [Updated] (MYNEWT-723) Host: LE Long Range and LE 2M support

2017-05-12 Thread Sheela (JIRA)

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

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

> Host: LE Long Range and LE 2M support
> -
>
> Key: MYNEWT-723
> URL: https://issues.apache.org/jira/browse/MYNEWT-723
> Project: Mynewt
>  Issue Type: Sub-task
>  Components: ble, Nimble
>Reporter: Łukasz Rymanowski
>Assignee: Łukasz Rymanowski
> Fix For: v1_1_0_rel
>
>
> In this Jira, HCI commands + GAP API to control PHY is going to be implement



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


[jira] [Updated] (MYNEWT-725) LE Extended scanning

2017-05-12 Thread Sheela (JIRA)

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

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

> LE Extended scanning
> 
>
> Key: MYNEWT-725
> URL: https://issues.apache.org/jira/browse/MYNEWT-725
> Project: Mynewt
>  Issue Type: Sub-task
>  Components: ble, Nimble
>Reporter: Łukasz Rymanowski
>Assignee: Łukasz Rymanowski
> Fix For: v1_1_0_rel
>
>




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


[jira] [Assigned] (MYNEWT-724) mynewt, build on ubuntu

2017-05-12 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-724:
-

Assignee: Wanda Chiu

> mynewt, build on ubuntu
> ---
>
> Key: MYNEWT-724
> URL: https://issues.apache.org/jira/browse/MYNEWT-724
> Project: Mynewt
>  Issue Type: Bug
>Affects Versions: v1_0_0_rel
> Environment: Linux Version:
> lsb_release -a
> Distributor ID:   Ubuntu
> Description:  Ubuntu 14.04.4 LTS
> Release:  14.04
> Codename: trusty
> Go version:
> go version
> go version go1.7 linux/386
>Reporter: Filipe
>Assignee: Wanda Chiu
>Priority: Minor
>
> when building the mynewt on ubuntu I have an error on go builder:
> syscfg/syscfg.go:965: constant 4294967295 overflows int
> Seems that the SYSCFG_INTERRUPT_PRIO_MAX is too big for the variable "int"



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


[jira] [Updated] (MYNEWT-748) SensorAPI: Add BME280 support to mynewt along with pressure, temperature and humidity support

2017-05-12 Thread Sheela (JIRA)

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

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

> SensorAPI: Add BME280 support to mynewt along with pressure, temperature and 
> humidity support
> -
>
> Key: MYNEWT-748
> URL: https://issues.apache.org/jira/browse/MYNEWT-748
> Project: Mynewt
>  Issue Type: New Feature
>Reporter: Vipul Rahane
>Assignee: Vipul Rahane
> Fix For: v1_1_0_rel
>
>
> Add SPI driver for BME280 along with pressure, temperature and humidity 
> support in SensorAPI. 



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


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

2017-05-12 Thread Sheela (JIRA)

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

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

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


[jira] [Created] (MYNEWT-739) Sensor list shows only default sensor

2017-04-24 Thread Sheela (JIRA)
Sheela created MYNEWT-739:
-

 Summary: Sensor list shows only default sensor 
 Key: MYNEWT-739
 URL: https://issues.apache.org/jira/browse/MYNEWT-739
 Project: Mynewt
  Issue Type: Bug
  Components: drivers
 Environment: nRF52dk with Adafruit BNO055 sensor and Minicom
Reporter: Sheela
Assignee: Vipul Rahane
 Fix For: v1_1_0_rel


Built code from the tip to include Sensors.  Connected Adafruit BNO055 via I2C 
interface to nRF52dk.  Modified Syscfg to "nrf52_sensor 
syscfg=BNO055_I2CBUS=0:I2C_0=1" for the BNO055 sensor.

Using sensors_test, issued 'sensor list' command which yielded "sensor dev = 
color0, type = 0x8000 " as result.  

Noticed that in syscfg the "TCS34725_PRESENT" was also set to '1' by default 
and 'sensor list' automatically shows only that sensor.  

sensor list should show all the sensors that are configured.




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


[jira] [Created] (MYNEWT-728) Raspberry Pi 3 support

2017-04-14 Thread Sheela (JIRA)
Sheela created MYNEWT-728:
-

 Summary: Raspberry Pi 3 support
 Key: MYNEWT-728
 URL: https://issues.apache.org/jira/browse/MYNEWT-728
 Project: Mynewt
  Issue Type: New Feature
  Components: OS
Reporter: Sheela
Assignee: Marko Kiiskila
 Fix For: v1_1_0_rel


support raspberry pi as dev environment



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


[jira] [Created] (MYNEWT-727) BSP for ACD52832

2017-04-14 Thread Sheela (JIRA)
Sheela created MYNEWT-727:
-

 Summary: BSP for ACD52832
 Key: MYNEWT-727
 URL: https://issues.apache.org/jira/browse/MYNEWT-727
 Project: Mynewt
  Issue Type: New Feature
  Components: BSP
Affects Versions: v1_1_0_rel
Reporter: Sheela
Assignee: William San Filippo
Priority: Minor


Create a BSP for Aconno ACD52832



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


[jira] [Resolved] (MYNEWT-495) newt sync needs a refactor

2017-03-08 Thread Sheela (JIRA)

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

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

> newt sync needs a refactor
> --
>
> Key: MYNEWT-495
> URL: https://issues.apache.org/jira/browse/MYNEWT-495
> Project: Mynewt
>  Issue Type: Improvement
>Affects Versions: v1_0_0_beta1
>Reporter: Sterling Hughes
>Assignee: Fabio Utzig
> Fix For: v1_0_0_rel
>
>
> newt sync currently deletes and resynchronizes the repository.
> It's behaviour needs a review, minimally I think it should:
> - go to the repositories its synching
> - detect whether or not there are any local changes
> - if so, goto #a
> - if not, git pull the latest changes
> #a
> - check if -f (force) flag is present, if not, abort and print error message
> - if -f is present, then it should stash the changes and save a diff, and 
> then pull the latest from the remote repo (and print notice messages.)



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


[jira] [Resolved] (MYNEWT-501) Add LE CoC support

2017-03-08 Thread Sheela (JIRA)

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

Sheela resolved MYNEWT-501.
---
   Resolution: Fixed
Fix Version/s: (was: WISHLIST)
   v1_0_0_rel

> Add LE CoC support
> --
>
> Key: MYNEWT-501
> URL: https://issues.apache.org/jira/browse/MYNEWT-501
> Project: Mynewt
>  Issue Type: Wish
>  Components: Nimble
>Reporter: Łukasz Rymanowski
>Assignee: Łukasz Rymanowski
> Fix For: v1_0_0_rel
>
>
> Bluetooth LE Connection Oriented Channels allows us to exchange data without 
> ATT/GATT overview.
> It is also mandatory for:  Internet Protocol Support Profile 



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


[jira] [Resolved] (MYNEWT-42) Need to run coverity scan on project source

2017-03-07 Thread Sheela (JIRA)

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

Sheela resolved MYNEWT-42.
--
Resolution: Done

Ran the coverity scan and it came with zero detects.

> Need to run coverity scan on project source 
> 
>
> Key: MYNEWT-42
> URL: https://issues.apache.org/jira/browse/MYNEWT-42
> Project: Mynewt
>  Issue Type: Improvement
>Reporter: Sterling Hughes
>Assignee: Aditi Hilbert
>Priority: Blocker
> Fix For: v1_0_0_rel
>
>
> And fix any bugs found by coverity.
> This should be a regular process now that we're running towards actually 
> putting up a release.



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


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

2017-03-07 Thread Sheela (JIRA)

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

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

> 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
>  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-543) setting sys cfg values via newt erases old settings

2017-03-01 Thread Sheela (JIRA)

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

Sheela closed MYNEWT-543.
-
Resolution: Won't Fix

See MYNEWT-640

> setting sys cfg values via newt erases old settings
> ---
>
> Key: MYNEWT-543
> URL: https://issues.apache.org/jira/browse/MYNEWT-543
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Affects Versions: v1_0_0_beta1
> Environment: Mac OS X
>Reporter: David G. Simmons
>Assignee: Wanda Chiu
>Priority: Minor
> Fix For: v1_0_0_rel
>
>
> DSimmons-Pro:myproj dsimmons$ cat targets/air_q/syscfg.yml
> \### Package: targets/air_q
> syscfg.vals:
> OPENOCD_DEBUG: 1
> \# Enable the shell task.
> SHELL_TASK: 1
> STATS_CLI: 1
> CONSOLE_TICKS: 1
> CONSOLE_PROMPT: 1
> DSimmons-Pro:myproj dsimmons$ newt target set air_q  syscfg=OPENOCD_DEBUG=0
> Target targets/air_q successfully set target.syscfg to OPENOCD_DEBUG=0
> DSimmons-Pro:myproj dsimmons$ cat targets/air_q/syscfg.yml
> \### Package: targets/air_q
> syscfg.vals:
> OPENOCD_DEBUG: 0
> DSimmons-Pro:myproj dsimmons$



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


[jira] [Resolved] (MYNEWT-641) Error in 'newt build nrf52_boot'

2017-02-28 Thread Sheela (JIRA)

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

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

new docker image with newt 1.0.0.b2 should fix the problem

> Error in 'newt build nrf52_boot'
> 
>
> Key: MYNEWT-641
> URL: https://issues.apache.org/jira/browse/MYNEWT-641
> Project: Mynewt
>  Issue Type: Bug
>  Components: Bootloader
>Affects Versions: v1_0_0_beta2
> Environment: Ubuntu 16.04 (docker)
>Reporter: Anthony Verbeck
>Assignee: Todd Mitton
>Priority: Minor
> Fix For: v1_0_0_rel
>
>
> Was able to build 'my_blinky_sim' (after reviewing issue 620). I had 
> something similar happen when attempting to build 'nrf52_boot'. Here's what I 
> got:
> Building target targets/nrf52_boot
> Error: In file included from aes.c:29:0:
> /workspace/repos/apache-mynewt-core/crypto/mbedtls/include/mbedtls/config.h:2522:10:
>  error: #include expects "FILENAME" or 
>  #include MBEDTLS_USER_CONFIG_FILE



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


[jira] [Assigned] (MYNEWT-620) my_blinky_sim not compiling (docker image on ubuntu 14.04)

2017-02-28 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-620:
-

Assignee: Todd Mitton  (was: Marko Kiiskila)

> my_blinky_sim not compiling (docker image on ubuntu 14.04)
> --
>
> Key: MYNEWT-620
> URL: https://issues.apache.org/jira/browse/MYNEWT-620
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Affects Versions: v1_0_0_rel
> Environment: Ubuntu 14.04 (using Docker)
>Reporter: Alvaro Prieto
>Assignee: Todd Mitton
>Priority: Minor
> Fix For: v1_0_0_rel
>
> Attachments: err_out.txt
>
>
> I'm following the Docker on Linux tutorial for mynewt: 
> https://mynewt.apache.org/latest/os/get_started/project_create/
> When running `newt build my_blinky_sim`, I get the following error (full 
> output attached):
> Assembling os_arch_stack_frame.s
> Error: os_arch_stack_frame.s: Assembler messages:
> os_arch_stack_frame.s:34: Error: junk at end of line, first unrecognized 
> character is `('
> os_arch_stack_frame.s:39: Error: invalid character '(' in mnemonic
> os_arch_stack_frame.s:84: Error: junk `(sigsetjmp)' after expression
> os_arch_stack_frame.s:98: Error: junk `(os_arch_task_start)' after expression
> After some searching, I found this: 
> http://stackoverflow.com/questions/3975278/cross-compile-arm-none-eabi-as-arm-assembly-error-junk-at-end-of-line-or-u
> I renamed the file from os_arch_stack_frame.s to os_arch_stack_frame.S and it 
> worked.



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


[jira] [Assigned] (MYNEWT-641) Error in 'newt build nrf52_boot'

2017-02-28 Thread Sheela (JIRA)

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

Sheela reassigned MYNEWT-641:
-

Assignee: Todd Mitton  (was: Marko Kiiskila)

> Error in 'newt build nrf52_boot'
> 
>
> Key: MYNEWT-641
> URL: https://issues.apache.org/jira/browse/MYNEWT-641
> Project: Mynewt
>  Issue Type: Bug
>  Components: Bootloader
>Affects Versions: v1_0_0_beta2
> Environment: Ubuntu 16.04 (docker)
>Reporter: Anthony Verbeck
>Assignee: Todd Mitton
>Priority: Minor
> Fix For: v1_0_0_rel
>
>
> Was able to build 'my_blinky_sim' (after reviewing issue 620). I had 
> something similar happen when attempting to build 'nrf52_boot'. Here's what I 
> got:
> Building target targets/nrf52_boot
> Error: In file included from aes.c:29:0:
> /workspace/repos/apache-mynewt-core/crypto/mbedtls/include/mbedtls/config.h:2522:10:
>  error: #include expects "FILENAME" or 
>  #include MBEDTLS_USER_CONFIG_FILE



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


  1   2   >