[jira] [Created] (MYNEWT-873) newt crashes during 'newt install'
Marko Kiiskila created MYNEWT-873: - Summary: newt crashes during 'newt install' Key: MYNEWT-873 URL: https://issues.apache.org/jira/browse/MYNEWT-873 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Components: Newt Affects Versions: v1_3_0_rel Reporter: Marko Kiiskila Assignee: Sterling Hughes There might, or might not have been, an attempt to run 'newt install' before for this project. Network was slow, so they might've stopped the fetch in the middle. But I'm not certain of that. nu@mc-117:~/myproj$ newt install panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x75d4ce] goroutine 1 [running]: mynewt.apache.org/newt/newt/repo.(*Version).ToNuVersion(...) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/version.go:162 mynewt.apache.org/newt/newt/repo.(*Repo).CheckNewtCompatibility(0xc420094e10, 0x0, 0x1, 0x2, 0x0, 0x0, 0x0, 0x1) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/repo.go:796 +0x5e mynewt.apache.org/newt/newt/project.(*Project).loadRepo(0xc420064ae0, 0xc4200157a0, 0x12, 0xc4200cc0e0, 0x1, 0x1) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:427 +0x51c mynewt.apache.org/newt/newt/project.(*Project).loadConfig(0xc420064ae0, 0x0, 0xc42007dbc0) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:505 +0x421 mynewt.apache.org/newt/newt/project.(*Project).Init(0xc420064ae0, 0xc420014184, 0x10, 0x1c, 0x8363c0) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:544 +0xed mynewt.apache.org/newt/newt/project.NewProject(0xc420014184, 0x10, 0xc420014184, 0x10, 0x0) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:135 +0x58 mynewt.apache.org/newt/newt/project.LoadProject(0xc420014184, 0x10, 0xc420057bd8, 0xc420062080, 0xc42180) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:719 +0x7d mynewt.apache.org/newt/newt/project.initProject(0xc420014184, 0x10, 0xc420014184, 0x10) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:74 +0x39 mynewt.apache.org/newt/newt/project.initialize(0x4, 0xc420057c90) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:92 +0x89 mynewt.apache.org/newt/newt/project.TryGetProject(0x4, 0xc420019138, 0x4) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:100 +0x22 mynewt.apache.org/newt/newt/cli.TryGetProject(0x0) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/cli/util.go:208 +0x26 mynewt.apache.org/newt/newt/cli.installRunCmd(0xc420161200, 0xb6fcf8, 0x0, 0x0) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/cli/project_cmds.go:76 +0x26 mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420161200, 0xb6fcf8, 0x0, 0x0, 0xc420161200, 0xb6fcf8) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636 +0x234 mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200ced80, 0xc42016e000, 0xc42016e900, 0xc42016e6c0) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722 +0x2fe mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200ced80, 0xc42007d290, 0xc420057f10) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681 +0x2b main.main() /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac gnu@mc-117:~/myproj$ cd .. gnu@mc-117:~$ cd adafruit/ gnu@mc-117:~/adafruit$ cd myproj/ gnu@mc-117:~/adafruit/myproj$ newt install panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x75d4ce] goroutine 1 [running]: mynewt.apache.org/newt/newt/repo.(*Version).ToNuVersion(...) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/version.go:162 mynewt.apache.org/newt/newt/repo.(*Repo).CheckNewtCompatibility(0xc4200aae10, 0x0, 0x1, 0x2, 0x0, 0x0, 0x0, 0x1) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/repo.go:796 +0x5e mynewt.apache.org/newt/newt/project.(*Project).loadRepo(0xc42009ea80, 0xc4200a71a0, 0x12, 0xc4200e20e0, 0x1, 0x1) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:427 +0x51c mynewt.apache.org/newt/newt/project.(*Project).loadConfig(0xc42009ea80, 0x0, 0xc420083bc0) /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:505 +0x421 mynewt.apache.org/newt/newt/project.(*Project).Init(0xc42009ea80, 0xc420014184, 0x19, 0x25, 0x8363c0)
[jira] [Resolved] (MYNEWT-870) net/nimble/host unittest build failure on raspberry pi
[
https://issues.apache.org/jira/browse/MYNEWT-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko Kiiskila resolved MYNEWT-870.
---
Resolution: Fixed
Fix Version/s: v1_4_0_rel
Checked in to master branch.
> net/nimble/host unittest build failure on raspberry pi
> --
>
> Key: MYNEWT-870
> URL: https://issues.apache.org/jira/browse/MYNEWT-870
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
>Reporter: Marko Kiiskila
> Fix For: v1_4_0_rel
>
>
> Compiling net/nimble/host/test/src/ble_sm_sc_test.c
> net/nimble/host/test/src/ble_hs_hci_test.c: In function
> ‘TEST_CASE_ble_hs_hci_acl_one_conn’:
> net/nimble/host/test/src/ble_hs_hci_test.c:88:12: error: missing braces
> around initializer [-Werror=missing-braces]
> struct ble_hs_test_util_hci_num_completed_pkts_entry ncpe[2] = { 0 };
> ^
> net/nimble/host/test/src/ble_hs_hci_test.c:88:12: error: (near initialization
> for ‘ncpe[0]’) [-Werror=missing-braces]
> net/nimble/host/test/src/ble_hs_hci_test.c: In function
> ‘TEST_CASE_ble_hs_hci_acl_two_conn’:
> net/nimble/host/test/src/ble_hs_hci_test.c:171:12: error: missing braces
> around initializer [-Werror=missing-braces]
> struct ble_hs_test_util_hci_num_completed_pkts_entry ncpe[2] = { 0 };
> ^
> net/nimble/host/test/src/ble_hs_hci_test.c:171:12: error: (near
> initialization for ‘ncpe[0]’) [-Werror=missing-braces]
> cc1: all warnings being treated as errors
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MYNEWT-870) net/nimble/host unittest build failure on raspberry pi
Marko Kiiskila created MYNEWT-870:
-
Summary: net/nimble/host unittest build failure on raspberry pi
Key: MYNEWT-870
URL: https://issues.apache.org/jira/browse/MYNEWT-870
Project: Mynewt
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Reporter: Marko Kiiskila
Compiling net/nimble/host/test/src/ble_sm_sc_test.c
net/nimble/host/test/src/ble_hs_hci_test.c: In function
‘TEST_CASE_ble_hs_hci_acl_one_conn’:
net/nimble/host/test/src/ble_hs_hci_test.c:88:12: error: missing braces around
initializer [-Werror=missing-braces]
struct ble_hs_test_util_hci_num_completed_pkts_entry ncpe[2] = { 0 };
^
net/nimble/host/test/src/ble_hs_hci_test.c:88:12: error: (near initialization
for ‘ncpe[0]’) [-Werror=missing-braces]
net/nimble/host/test/src/ble_hs_hci_test.c: In function
‘TEST_CASE_ble_hs_hci_acl_two_conn’:
net/nimble/host/test/src/ble_hs_hci_test.c:171:12: error: missing braces around
initializer [-Werror=missing-braces]
struct ble_hs_test_util_hci_num_completed_pkts_entry ncpe[2] = { 0 };
^
net/nimble/host/test/src/ble_hs_hci_test.c:171:12: error: (near initialization
for ‘ncpe[0]’) [-Werror=missing-braces]
cc1: all warnings being treated as errors
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MYNEWT-378) Need stack checking in OS context switch
[ https://issues.apache.org/jira/browse/MYNEWT-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila reassigned MYNEWT-378: - Assignee: Marko Kiiskila (was: Fabio Utzig) > Need stack checking in OS context switch > > > Key: MYNEWT-378 > URL: https://issues.apache.org/jira/browse/MYNEWT-378 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Reporter: Sterling Hughes >Assignee: Marko Kiiskila > > We should have a debug mode of operation that includes stack guards, and > performs stack overflow checking in the context switch -- and asserts if a > task has overflowed its stack. > This should be optionally compiled in, because there is a performance hit. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYNEWT-863) hal_i2c_clear_bus() should be made public
[ https://issues.apache.org/jira/browse/MYNEWT-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269149#comment-16269149 ] Marko Kiiskila commented on MYNEWT-863: --- You have i2c devices which lock up? Or ones which don't reset when your MCU resets? Note that you'll have to implement this function for all MCUs. > hal_i2c_clear_bus() should be made public > - > > Key: MYNEWT-863 > URL: https://issues.apache.org/jira/browse/MYNEWT-863 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Reporter: Vipul Rahane >Assignee: Vipul Rahane > Labels: drivers, i2c > Fix For: v1_4_0_rel > > > hal_i2c_clear_bus() should be made public, currently it is static and cannot > be called from outside the hal. > We are currently working on a locking i2c driver which would call this > function. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYNEWT-865) hal i2c lockup on nrf platform if timeout is too short
[ https://issues.apache.org/jira/browse/MYNEWT-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261007#comment-16261007 ] Marko Kiiskila commented on MYNEWT-865: --- That seems unlikely; as you can see from the tx side code, it does not leave the routine until either a) data was sent successfully, b) timeout and we have written to TASKS_STOP or c) ERROR register was set. Unlike with RX, there's no event marked to happen at byte boundary afterwards. On the other hand, I was not able to find from Nordic's documentation the fact that RXD had to be read to unstall the RX. This as opposed to just clearing the event register, which I thought would be sufficient. > hal i2c lockup on nrf platform if timeout is too short > -- > > Key: MYNEWT-865 > URL: https://issues.apache.org/jira/browse/MYNEWT-865 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: HAL >Affects Versions: v1_2_0_rel >Reporter: William San Filippo >Assignee: Marko Kiiskila > Fix For: v1_3_0_rel > > > The nordic TWI (i2c) interface locked up when a too short timeout was > applied. Not sure of all the details here but I believe another transaction > was started and that this transaction caused the TWI interface to become > unresponsive. > The basic issue here is that the timeout is in os ticks and it is possible, > given the current code implementation, that there is basically no timeout > applied as a timeout of 1 os tick will give you a timeout of 0 to 1 os tick > (in msecs). > Another issue is that the code does not attempt to calculate whether the > timeout is too short given the length of i2c data to be sent, the clock > frequency and the time per os tick. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYNEWT-865) hal i2c lockup on nrf platform if timeout is too short
[ https://issues.apache.org/jira/browse/MYNEWT-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16260057#comment-16260057 ] Marko Kiiskila commented on MYNEWT-865: --- Bit of a correction regarding timeout parameter: passing 1 means that we'll wait 1-2 ticks. Not 0-1 ticks. My opinion is that we don't need granular timeouts here. The timeout parameter is to catch cases where e.g. there is no device present with this address present, not so much to cancel requests to slow i2c devices. That being said, there was an issue when cancelling read requests when data was being RX'd. We told TWI to cancel the transfer on the next byte boundary, but did not drain the incoming data afterwards. I was able to tickle this case once I started stopping the core in debugger in the middle of a transaction. > hal i2c lockup on nrf platform if timeout is too short > -- > > Key: MYNEWT-865 > URL: https://issues.apache.org/jira/browse/MYNEWT-865 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: HAL >Affects Versions: v1_2_0_rel >Reporter: William San Filippo >Assignee: Marko Kiiskila > Fix For: v1_3_0_rel > > > The nordic TWI (i2c) interface locked up when a too short timeout was > applied. Not sure of all the details here but I believe another transaction > was started and that this transaction caused the TWI interface to become > unresponsive. > The basic issue here is that the timeout is in os ticks and it is possible, > given the current code implementation, that there is basically no timeout > applied as a timeout of 1 os tick will give you a timeout of 0 to 1 os tick > (in msecs). > Another issue is that the code does not attempt to calculate whether the > timeout is too short given the length of i2c data to be sent, the clock > frequency and the time per os tick. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-17) add atof() and strtod() support to baselibc
[ https://issues.apache.org/jira/browse/MYNEWT-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila updated MYNEWT-17: - Fix Version/s: (was: v1_3_0_rel) v1_4_0_rel > add atof() and strtod() support to baselibc > --- > > Key: MYNEWT-17 > URL: https://issues.apache.org/jira/browse/MYNEWT-17 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: Misc >Reporter: Marko Kiiskila >Assignee: Marko Kiiskila >Priority: Minor > Fix For: v1_4_0_rel > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-795) need to have os_task_remove()
[ https://issues.apache.org/jira/browse/MYNEWT-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila resolved MYNEWT-795. --- Resolution: Fixed > need to have os_task_remove() > - > > Key: MYNEWT-795 > URL: https://issues.apache.org/jira/browse/MYNEWT-795 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: OS >Reporter: Marko Kiiskila >Assignee: Marko Kiiskila > Fix For: v1_1_0_rel > > > Currently you can suspend a task, but not remove it completely. > There are use cases where creation of short-lived task makes sense. We should > have a way to get rid of existing task completely. > Whether this removal is done by the task itself (by returning from it's > handler), or by a separate task is TBD. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-795) need to have os_task_remove()
[ https://issues.apache.org/jira/browse/MYNEWT-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila updated MYNEWT-795: -- Fix Version/s: (was: v1_3_0_rel) v1_1_0_rel > need to have os_task_remove() > - > > Key: MYNEWT-795 > URL: https://issues.apache.org/jira/browse/MYNEWT-795 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: OS >Reporter: Marko Kiiskila >Assignee: Marko Kiiskila > Fix For: v1_1_0_rel > > > Currently you can suspend a task, but not remove it completely. > There are use cases where creation of short-lived task makes sense. We should > have a way to get rid of existing task completely. > Whether this removal is done by the task itself (by returning from it's > handler), or by a separate task is TBD. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-490) Move os_time_get() and parts of os_time_tick() into the HAL, rename os_tick HAL
[ https://issues.apache.org/jira/browse/MYNEWT-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila updated MYNEWT-490: -- Fix Version/s: (was: v1_3_0_rel) v1_4_0_rel > Move os_time_get() and parts of os_time_tick() into the HAL, rename os_tick > HAL > --- > > Key: MYNEWT-490 > URL: https://issues.apache.org/jira/browse/MYNEWT-490 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Sterling Hughes >Assignee: Marko Kiiskila > Fix For: v1_4_0_rel > > > Right now the implementation of os_time_* is split between platform/idle tick > handling (currently in the MCU directory), and the OS itself. It is useful > for the HAL to be able to access the ticker, and given that the os_tick > handling implementation is already _largely_ in the HAL, it makes sense to > centralize this in the MCU implementation itself. > Also, we should rename os_tick_idle() to hal_os_tick_idle(). > This is a tracking ticket to make sure we review and potentially revise the > division here prior to release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-417) os_mbuf needs functions to pre-allocate buffers, and generate a contiguous buffer
[ https://issues.apache.org/jira/browse/MYNEWT-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila updated MYNEWT-417: -- Fix Version/s: (was: v1_3_0_rel) v1_4_0_rel > os_mbuf needs functions to pre-allocate buffers, and generate a contiguous > buffer > - > > Key: MYNEWT-417 > URL: https://issues.apache.org/jira/browse/MYNEWT-417 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: v1_0_0_beta1 >Reporter: Sterling Hughes >Assignee: Marko Kiiskila > Fix For: v1_4_0_rel > > > os_mbuf APIs need a few extra helper functions: > - a function to allocate an mbuf with at least 'n' bytes contiguous from msys > - a function to allocate a chain of mbufs that is guaranteed to have at least > 'n' bytes -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-133) Need support for running from RAM
[ https://issues.apache.org/jira/browse/MYNEWT-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila updated MYNEWT-133: -- Fix Version/s: (was: v1_3_0_rel) v1_4_0_rel > Need support for running from RAM > - > > Key: MYNEWT-133 > URL: https://issues.apache.org/jira/browse/MYNEWT-133 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) > Components: Bootloader, Flash, Image Mgmt, OS >Reporter: Sterling Hughes >Assignee: Marko Kiiskila > Fix For: v1_4_0_rel > > > Right now we program internal flash to run from, must provide support for > running from RAM, and a combination of different RAMs (e.g. internal ram for > critical code sections, external ram for non-critical sections.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-32) Add pinmux API for GPIOs
[ https://issues.apache.org/jira/browse/MYNEWT-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila updated MYNEWT-32: - Fix Version/s: (was: v1_3_0_rel) v1_4_0_rel > Add pinmux API for GPIOs > > > Key: MYNEWT-32 > URL: https://issues.apache.org/jira/browse/MYNEWT-32 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) > Components: HAL >Reporter: Sterling Hughes >Assignee: Marko Kiiskila > Fix For: v1_4_0_rel > > > Need an API to register GPIOs, and manage multiplexing their functions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-134) Support images in external flash
[ https://issues.apache.org/jira/browse/MYNEWT-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila updated MYNEWT-134: -- Fix Version/s: (was: v1_3_0_rel) v1_4_0_rel > Support images in external flash > > > Key: MYNEWT-134 > URL: https://issues.apache.org/jira/browse/MYNEWT-134 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) > Components: Bootloader, Flash, Image Mgmt >Reporter: Sterling Hughes >Assignee: Marko Kiiskila > Fix For: v1_4_0_rel > > > Must support grabbing images from an external SPI flash, and running them > either in RAM, or in internal flash. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-834) logging to console needs \n at the end of the log line
Marko Kiiskila created MYNEWT-834: - Summary: logging to console needs \n at the end of the log line Key: MYNEWT-834 URL: https://issues.apache.org/jira/browse/MYNEWT-834 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Reporter: Marko Kiiskila Priority: Minor Fix For: v1_3_0_rel The current behaviour does not seems quite right. Which is that user is expected to insert \n at the end of logged string. newlines make sense at the end of the log line when going to console, but not when going to flash. We should either a) append a newline at the end of the line when going to console or b) strip newlines from the end when going to other targets. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-827) nrf52 BLE without external 32k crystal has issues
[ https://issues.apache.org/jira/browse/MYNEWT-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila resolved MYNEWT-827. --- Resolution: Fixed Now works for me. > nrf52 BLE without external 32k crystal has issues > - > > Key: MYNEWT-827 > URL: https://issues.apache.org/jira/browse/MYNEWT-827 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Affects Versions: v1_1_0_rel >Reporter: Marko Kiiskila >Assignee: William San Filippo > > This target was working ok with mynewt 1.0, but does not after updating to > mynewt 1.1 > targets/hci_bmd300 > app=@apache-mynewt-core/apps/blehci > bsp=@apache-mynewt-core/hw/bsp/bmd300eval > build_profile=optimized > syscfg=BLE_MAX_CONNECTIONS=12:MSYS_1_BLOCK_COUNT=32:XTAL_32768=0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYNEWT-827) nrf52 BLE without external 32k crystal has issues
[ https://issues.apache.org/jira/browse/MYNEWT-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16165015#comment-16165015 ] Marko Kiiskila commented on MYNEWT-827: --- So with these settings connections seems to establish ok. syscfg=BLE_MAX_CONNECTIONS=12:BLE_XTAL_SETTLE_TIME=0:MSYS_1_BLOCK_COUNT=32:UART_0_PIN_CTS=5:UART_0_PIN_RTS=7:XTAL_32768=0:XTAL_32768_SYNTH=1 > nrf52 BLE without external 32k crystal has issues > - > > Key: MYNEWT-827 > URL: https://issues.apache.org/jira/browse/MYNEWT-827 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Affects Versions: v1_1_0_rel >Reporter: Marko Kiiskila >Assignee: William San Filippo > > This target was working ok with mynewt 1.0, but does not after updating to > mynewt 1.1 > targets/hci_bmd300 > app=@apache-mynewt-core/apps/blehci > bsp=@apache-mynewt-core/hw/bsp/bmd300eval > build_profile=optimized > syscfg=BLE_MAX_CONNECTIONS=12:MSYS_1_BLOCK_COUNT=32:XTAL_32768=0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MYNEWT-827) nrf52 BLE without external 32k crystal has issues
[ https://issues.apache.org/jira/browse/MYNEWT-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila reassigned MYNEWT-827: - Assignee: William San Filippo (was: Marko Kiiskila) > nrf52 BLE without external 32k crystal has issues > - > > Key: MYNEWT-827 > URL: https://issues.apache.org/jira/browse/MYNEWT-827 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Affects Versions: v1_1_0_rel >Reporter: Marko Kiiskila >Assignee: William San Filippo > > This target was working ok with mynewt 1.0, but does not after updating to > mynewt 1.1 > targets/hci_bmd300 > app=@apache-mynewt-core/apps/blehci > bsp=@apache-mynewt-core/hw/bsp/bmd300eval > build_profile=optimized > syscfg=BLE_MAX_CONNECTIONS=12:MSYS_1_BLOCK_COUNT=32:XTAL_32768=0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MYNEWT-827) nrf52 BLE without external 32k crystal has issues
[ https://issues.apache.org/jira/browse/MYNEWT-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila reassigned MYNEWT-827: - Assignee: Marko Kiiskila > nrf52 BLE without external 32k crystal has issues > - > > Key: MYNEWT-827 > URL: https://issues.apache.org/jira/browse/MYNEWT-827 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Affects Versions: v1_1_0_rel >Reporter: Marko Kiiskila >Assignee: Marko Kiiskila > > This target was working ok with mynewt 1.0, but does not after updating to > mynewt 1.1 > targets/hci_bmd300 > app=@apache-mynewt-core/apps/blehci > bsp=@apache-mynewt-core/hw/bsp/bmd300eval > build_profile=optimized > syscfg=BLE_MAX_CONNECTIONS=12:MSYS_1_BLOCK_COUNT=32:XTAL_32768=0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-833) PWM driver for Atmel SAMD21
Marko Kiiskila created MYNEWT-833: - Summary: PWM driver for Atmel SAMD21 Key: MYNEWT-833 URL: https://issues.apache.org/jira/browse/MYNEWT-833 Project: Mynewt Issue Type: New Feature Security Level: Public (Viewable by anyone) Reporter: Marko Kiiskila There was a PWM driver for SAMD21 with old HAL API, it should be relatively easy to bring that up-to-date with current driver API. Having this would help in sanity checking the PWM API we have. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-525) Need a PWM driver
[ https://issues.apache.org/jira/browse/MYNEWT-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila resolved MYNEWT-525. --- Resolution: Fixed Fix Version/s: v1_2_0_rel There is now PWM driver API, and a driver for nrf52. > Need a PWM driver > - > > Key: MYNEWT-525 > URL: https://issues.apache.org/jira/browse/MYNEWT-525 > Project: Mynewt > Issue Type: Wish > Security Level: Public(Viewable by anyone) > Components: Drivers >Reporter: Sterling Hughes > Fix For: v1_2_0_rel > > > Desirable to have a PWM driver, as this is a very common function. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-692) Add support for ethernet in frdm-k64f
[ https://issues.apache.org/jira/browse/MYNEWT-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila updated MYNEWT-692: -- Summary: Add support for ethernet in frdm-k64f (was: Add support for ethernet communication) > Add support for ethernet in frdm-k64f > - > > Key: MYNEWT-692 > URL: https://issues.apache.org/jira/browse/MYNEWT-692 > Project: Mynewt > Issue Type: Task > Security Level: Public(Viewable by anyone) > 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.4.14#64029)
[jira] [Assigned] (MYNEWT-823) Broken link
[ https://issues.apache.org/jira/browse/MYNEWT-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila reassigned MYNEWT-823: - Assignee: Aditi Hilbert > Broken link > --- > > Key: MYNEWT-823 > URL: https://issues.apache.org/jira/browse/MYNEWT-823 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Environment: http://mynewt.apache.org/latest/os/introduction/ >Reporter: Sebb >Assignee: Aditi Hilbert > > "get set up and started" links to > http://mynewt.apache.org/latest/get_started/get_started/ which fails with 404. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-829) boot loader with serial update option is too big
[ https://issues.apache.org/jira/browse/MYNEWT-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila resolved MYNEWT-829. --- Resolution: Fixed Fix pushed to master. > boot loader with serial update option is too big > > > Key: MYNEWT-829 > URL: https://issues.apache.org/jira/browse/MYNEWT-829 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Affects Versions: v1_2_0_rel >Reporter: Marko Kiiskila >Assignee: Marko Kiiskila > Fix For: v1_2_0_rel > > > console/minimal now has dependencies to os_eventq(), and this ends up > increasing serial bootloader size by 10%. > new image upload scheme involves erasing flash slot before upgrade, which > means adding a new command. > These together push the bootloader size to be > 16k on nrf52. > boot_serial needs to be revisited to bring down the resource use. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-829) boot loader with serial update option is too big
Marko Kiiskila created MYNEWT-829: - Summary: boot loader with serial update option is too big Key: MYNEWT-829 URL: https://issues.apache.org/jira/browse/MYNEWT-829 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Affects Versions: v1_2_0_rel Reporter: Marko Kiiskila Assignee: Marko Kiiskila Fix For: v1_2_0_rel console/minimal now has dependencies to os_eventq(), and this ends up increasing serial bootloader size by 10%. new image upload scheme involves erasing flash slot before upgrade, which means adding a new command. These together push the bootloader size to be > 16k on nrf52. boot_serial needs to be revisited to bring down the resource use. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-827) nrf52 BLE without external 32k crystal has issues
Marko Kiiskila created MYNEWT-827: - Summary: nrf52 BLE without external 32k crystal has issues Key: MYNEWT-827 URL: https://issues.apache.org/jira/browse/MYNEWT-827 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Affects Versions: v1_1_0_rel Reporter: Marko Kiiskila This target was working ok with mynewt 1.0, but does not after updating to mynewt 1.1 targets/hci_bmd300 app=@apache-mynewt-core/apps/blehci bsp=@apache-mynewt-core/hw/bsp/bmd300eval build_profile=optimized syscfg=BLE_MAX_CONNECTIONS=12:MSYS_1_BLOCK_COUNT=32:XTAL_32768=0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-826) syscfg settings not taking effect
[ https://issues.apache.org/jira/browse/MYNEWT-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila resolved MYNEWT-826. --- Resolution: Fixed Fix checked in. > syscfg settings not taking effect > - > > Key: MYNEWT-826 > URL: https://issues.apache.org/jira/browse/MYNEWT-826 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Marko Kiiskila >Assignee: Marko Kiiskila > Fix For: v1_2_0_rel > > > I was trying to set syscfg variable in target, but it was not having desired > effect. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYNEWT-544) Cannot over-ride UART Pins in sys cfg.yml
[
https://issues.apache.org/jira/browse/MYNEWT-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16133741#comment-16133741
]
Marko Kiiskila commented on MYNEWT-544:
---
This should work. Here's from a target I'm using:
{code:none}
newt target show hci_bmd300
...
syscfg=UART_0_PIN_CTS=5:UART_0_PIN_RTS=7
newt target config show hci_bmd300
...
* Setting: UART_0_PIN_CTS
* Description: CTS pin for UART0
* Value: 5
* Overridden: targets/hci_bmd300, default=7
* Setting: UART_0_PIN_RTS
* Description: RTS pin for UART0
* Value: 7
* Overridden: targets/hci_bmd300, default=5
{code}
And this is how it looks on my target's syscfg.yml:
{code:none}
syscfg.vals:
UART_0_PIN_RTS: 7
UART_0_PIN_CTS: 5
{code}
> 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.4.14#64029)
[jira] [Resolved] (MYNEWT-384) Implement MQTT client protocol
[ https://issues.apache.org/jira/browse/MYNEWT-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila resolved MYNEWT-384. --- Resolution: Fixed PR merged: https://github.com/apache/mynewt-core/pull/383 > Implement MQTT client protocol > -- > > Key: MYNEWT-384 > URL: https://issues.apache.org/jira/browse/MYNEWT-384 > Project: Mynewt > Issue Type: Wish > Security Level: Public(Viewable by anyone) > Components: Misc >Reporter: Iosif Gut >Assignee: Sterling Hughes >Priority: Minor > Labels: features > Fix For: v1_1_0_rel > > > Message Queue Telemetry Transport (MQTT) protocol is a lightweight > machine-to-machine protocol. The protocol uses a subscribe publish model for > message exchange between the machines. All messaging takes place through a > messaging broker, referred to from now on as the MQTT Broker. When referring > to publishers and subscribers that use the broker for messaging, they are > referred to as MQTT clients. > https://developer.nordicsemi.com/nRF5_IoT_SDK/doc/0.8.0/iot/html/a00028.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-720) Newt: manipulate image signatures
[
https://issues.apache.org/jira/browse/MYNEWT-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko Kiiskila updated MYNEWT-720:
--
Labels: doc documentation (was: )
> 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
> Labels: doc, documentation
> Fix For: v1_1_0_rel
>
>
> 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.4.14#64029)
[jira] [Updated] (MYNEWT-302) driver interface for capacitive sensing
[ https://issues.apache.org/jira/browse/MYNEWT-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila updated MYNEWT-302: -- Summary: driver interface for capacitive sensing (was: HAL for capacitive sensing) > driver interface for capacitive sensing > --- > > Key: MYNEWT-302 > URL: https://issues.apache.org/jira/browse/MYNEWT-302 > Project: Mynewt > Issue Type: Wish > Security Level: Public(Viewable by anyone) > Components: HAL >Affects Versions: WISHLIST >Reporter: Stephane D'Alu >Priority: Minor > Fix For: v1_2_0_rel > > > It's possible to implement capacitive sensing with some of the MCUs > * nRF51: https://github.com/NordicSemiconductor/nrf51-capsense-example > * nRF52: https://github.com/NordicSemiconductor/nrf52-capsense-example > * STM32F091RC > It would be nice to have an abstraction layer for it -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-795) need to have os_task_remove()
Marko Kiiskila created MYNEWT-795: - Summary: need to have os_task_remove() Key: MYNEWT-795 URL: https://issues.apache.org/jira/browse/MYNEWT-795 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Components: OS Reporter: Marko Kiiskila Fix For: v1_2_0_rel Currently you can suspend a task, but not remove it completely. There are use cases where creation of short-lived task makes sense. We should have a way to get rid of existing task completely. Whether this removal is done by the task itself (by returning from it's handler), or by a separate task is TBD. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-395) make 'newt create-image' to create a combined Intel hex file
[ https://issues.apache.org/jira/browse/MYNEWT-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila updated MYNEWT-395: -- Labels: doc (was: ) > make 'newt create-image' to create a combined Intel hex file > > > Key: MYNEWT-395 > URL: https://issues.apache.org/jira/browse/MYNEWT-395 > Project: Mynewt > Issue Type: Wish > Security Level: Public(Viewable by anyone) > Components: Newt >Affects Versions: WISHLIST > Environment: all >Reporter: Wayne Keenan >Assignee: Marko Kiiskila >Priority: Minor > Labels: doc > Fix For: v1_1_0_rel > > > It would be handy for the 'newt create-image' command to also create a single > combined Intel hex file for (at least) the boot loader and application. > In addition, it would also be handy if custom files and/or filesystems could > be included at hex file creation time too. > This is very useful for DAP based (e.g. mbed) boards. > At the moment I'm saving the entire device flash as a hex file after issuing > the boot & app 'newt load' commands; it would be nice to be able to create a > hex file without having a physical device attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
