[jira] [Created] (MYNEWT-685) Support "git" only package management
Sterling Hughes created MYNEWT-685: -- Summary: Support "git" only package management Key: MYNEWT-685 URL: https://issues.apache.org/jira/browse/MYNEWT-685 Project: Mynewt Issue Type: Improvement Reporter: Sterling Hughes Fix For: v1_1_0_rel Right now fetching repository.yml requires github (either private or public), but can not just use raw git commands. Support git only versions of this, to suppoort bitbucket and other private git repos. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-684) Support
Sterling Hughes created MYNEWT-684: -- Summary: Support Key: MYNEWT-684 URL: https://issues.apache.org/jira/browse/MYNEWT-684 Project: Mynewt Issue Type: Improvement Reporter: Sterling Hughes -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-675) Arduino Primo documentation still references "features"
Sterling Hughes created MYNEWT-675: -- Summary: Arduino Primo documentation still references "features" Key: MYNEWT-675 URL: https://issues.apache.org/jira/browse/MYNEWT-675 Project: Mynewt Issue Type: Bug Components: Documentation Affects Versions: v1_0_0_rel Reporter: Sterling Hughes Assignee: Marko Kiiskila Fix For: v1_0_0_rel http://mynewt.apache.org/latest/os/tutorials/blinky_primo/ In order to use openocd, it says to have the following line: $ newt target set primo_boot features=openocd_debug $ newt target set primoblinky features=openocd_debug Instead, this is now "syscfg=OPENOCD_DEBUG" in order to have the same effect. Also, install of custom openocd is painful, as it requires autotools - it would be great if we already compiled the openocd binary for mac, linux platforms. This is more of an openocd thing, but still. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-543) setting sys cfg values via newt erases old settings
[ https://issues.apache.org/jira/browse/MYNEWT-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886060#comment-15886060 ] Sterling Hughes commented on MYNEWT-543: +1 - I agree. I think it's confusing that these files are auto-generated by newt target set and manually editable by users as well. We should either say "don't edit manually" (with a big comment at the top), or cleanly manage the two. IMO - we should say don't edit manually with a big comment at the top. > 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] [Assigned] (MYNEWT-642) Eddystone UID format is incorrect
[ https://issues.apache.org/jira/browse/MYNEWT-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes reassigned MYNEWT-642: -- Assignee: Christopher Collins > Eddystone UID format is incorrect > - > > Key: MYNEWT-642 > URL: https://issues.apache.org/jira/browse/MYNEWT-642 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Affects Versions: v1_0_0_rel >Reporter: Simon Ratner >Assignee: Christopher Collins > > The format of the eddystone beacon, as generated by > `ble_eddystone_set_adv_data_uid`, is incorrect. > According to https://github.com/google/eddystone/tree/master/eddystone-uid, > the UID frame starts with 0x00, followed by calibrated rssi at 0m, followed > by the 16 byte uid, and finally 2 zero bytes to pad to the full 31 bytes. > By comparison, `ble_eddystone_set_adv_data_url` seems to be doing the right > thing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-642) Eddystone UID format is incorrect
[ https://issues.apache.org/jira/browse/MYNEWT-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884801#comment-15884801 ] Sterling Hughes commented on MYNEWT-642: and simon, thank you! > Eddystone UID format is incorrect > - > > Key: MYNEWT-642 > URL: https://issues.apache.org/jira/browse/MYNEWT-642 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Affects Versions: v1_0_0_rel >Reporter: Simon Ratner >Assignee: Christopher Collins > > The format of the eddystone beacon, as generated by > `ble_eddystone_set_adv_data_uid`, is incorrect. > According to https://github.com/google/eddystone/tree/master/eddystone-uid, > the UID frame starts with 0x00, followed by calibrated rssi at 0m, followed > by the 16 byte uid, and finally 2 zero bytes to pad to the full 31 bytes. > By comparison, `ble_eddystone_set_adv_data_url` seems to be doing the right > thing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-642) Eddystone UID format is incorrect
[ https://issues.apache.org/jira/browse/MYNEWT-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884800#comment-15884800 ] Sterling Hughes commented on MYNEWT-642: chris, can we look at merging prior to 1.0? > Eddystone UID format is incorrect > - > > Key: MYNEWT-642 > URL: https://issues.apache.org/jira/browse/MYNEWT-642 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Affects Versions: v1_0_0_rel >Reporter: Simon Ratner >Assignee: Christopher Collins > > The format of the eddystone beacon, as generated by > `ble_eddystone_set_adv_data_uid`, is incorrect. > According to https://github.com/google/eddystone/tree/master/eddystone-uid, > the UID frame starts with 0x00, followed by calibrated rssi at 0m, followed > by the 16 byte uid, and finally 2 zero bytes to pad to the full 31 bytes. > By comparison, `ble_eddystone_set_adv_data_url` seems to be doing the right > thing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-641) Error in 'newt build nrf52_boot'
[ https://issues.apache.org/jira/browse/MYNEWT-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-641: --- Fix Version/s: v1_0_0_rel > 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: Marko Kiiskila >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] [Commented] (MYNEWT-641) Error in 'newt build nrf52_boot'
[ https://issues.apache.org/jira/browse/MYNEWT-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884503#comment-15884503 ] Sterling Hughes commented on MYNEWT-641: hrm - Marko can you check to ensure that the docker image is updated with the b2 newt? If not, that could certainly cause this issue, because blinky is now pointing to b2 on "newt new" > 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: Marko Kiiskila >Priority: Minor > > 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-527) newt - Run bsp scripts on Windows
[
https://issues.apache.org/jira/browse/MYNEWT-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes reassigned MYNEWT-527:
--
Assignee: Marko Kiiskila (was: Sterling Hughes)
> newt - Run bsp scripts on Windows
> -
>
> Key: MYNEWT-527
> URL: https://issues.apache.org/jira/browse/MYNEWT-527
> Project: Mynewt
> Issue Type: Bug
> Components: Newt
>Affects Versions: v1_0_0_beta1
> Environment: Windows 10, WSL, MSYS2
>Reporter: Simon Ratner
>Assignee: Marko Kiiskila
> Fix For: v1_0_0_rel
>
>
> Now that the `newt` tool no longer runs commands through a shell, it is not
> able to execute bsp scripts (`_download.sh` / `_debug.sh`) on Windows, where
> `CreateProcess` can't run shell scripts natively.
> A solution that works pretty well is to create parallel `_download.cmd` /
> `_debug.cmd` scripts with just the following:
> {noformat}
> @rem Execute a shell with a script of the same name and .sh extension
> @sh "%~dp0%~n0.sh"
> {noformat}
> And modify bsp.yml to use those instead, for example for `nrf51dk`:
> {noformat}
> diff --git a/hw/bsp/nrf51dk/bsp.yml b/hw/bsp/nrf51dk/bsp.yml
> index 5e78d60..95b57f6 100644
> --- a/hw/bsp/nrf51dk/bsp.yml
> +++ b/hw/bsp/nrf51dk/bsp.yml
> @@ -26,8 +26,8 @@ bsp.linkerscript.BOOT_LOADER.OVERWRITE:
> - "hw/bsp/nrf51dk/boot-nrf51xxac.ld"
> - "hw/mcu/nordic/nrf51xxx/nrf51.ld"
> bsp.part2linkerscript: "hw/bsp/nrf51dk/split-nrf51dk.ld"
> -bsp.downloadscript: "hw/bsp/nrf51dk/nrf51dk_download.sh"
> -bsp.debugscript: "hw/bsp/nrf51dk/nrf51dk_debug.sh"
> +bsp.downloadscript: "hw/bsp/nrf51dk/nrf51dk_download.cmd"
> +bsp.debugscript: "hw/bsp/nrf51dk/nrf51dk_debug.cmd"
> bsp.flash_map:
> areas:
> diff --git a/hw/bsp/nrf51dk/nrf51dk_debug.cmd
> b/hw/bsp/nrf51dk/nrf51dk_debug.cmd
> new file mode 100644
> index 000..354743d
> --- /dev/null
> +++ b/hw/bsp/nrf51dk/nrf51dk_debug.cmd
> @@ -0,0 +1,2 @@
> +@rem Execute a shell with a script of the same name and .sh extension
> +@sh "%~dp0%~n0.sh"
> diff --git a/hw/bsp/nrf51dk/nrf51dk_download.cmd
> b/hw/bsp/nrf51dk/nrf51dk_download.cmd
> new file mode 100644
> index 000..354743d
> --- /dev/null
> +++ b/hw/bsp/nrf51dk/nrf51dk_download.cmd
> @@ -0,0 +1,2 @@
> +@rem Execute a shell with a script of the same name and .sh extension
> +@sh "%~dp0%~n0.sh"
> {noformat}
> At the very least, adding these scripts to the repo will allow devs to use
> `newt load` and `newt debug` on Windows with minimal effort (in combination
> with https://github.com/apache/incubator-mynewt-newt/pull/29 and
> https://github.com/apache/incubator-mynewt-core/pull/150).
> How to best automate this is a question to the devs; perhaps platform
> overrides in `bsp.yml` to specify platform-specific scripts?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MYNEWT-527) newt - Run bsp scripts on Windows
[
https://issues.apache.org/jira/browse/MYNEWT-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884485#comment-15884485
]
Sterling Hughes commented on MYNEWT-527:
can we look at this prior to rel?
> newt - Run bsp scripts on Windows
> -
>
> Key: MYNEWT-527
> URL: https://issues.apache.org/jira/browse/MYNEWT-527
> Project: Mynewt
> Issue Type: Bug
> Components: Newt
>Affects Versions: v1_0_0_beta1
> Environment: Windows 10, WSL, MSYS2
>Reporter: Simon Ratner
>Assignee: Marko Kiiskila
> Fix For: v1_0_0_rel
>
>
> Now that the `newt` tool no longer runs commands through a shell, it is not
> able to execute bsp scripts (`_download.sh` / `_debug.sh`) on Windows, where
> `CreateProcess` can't run shell scripts natively.
> A solution that works pretty well is to create parallel `_download.cmd` /
> `_debug.cmd` scripts with just the following:
> {noformat}
> @rem Execute a shell with a script of the same name and .sh extension
> @sh "%~dp0%~n0.sh"
> {noformat}
> And modify bsp.yml to use those instead, for example for `nrf51dk`:
> {noformat}
> diff --git a/hw/bsp/nrf51dk/bsp.yml b/hw/bsp/nrf51dk/bsp.yml
> index 5e78d60..95b57f6 100644
> --- a/hw/bsp/nrf51dk/bsp.yml
> +++ b/hw/bsp/nrf51dk/bsp.yml
> @@ -26,8 +26,8 @@ bsp.linkerscript.BOOT_LOADER.OVERWRITE:
> - "hw/bsp/nrf51dk/boot-nrf51xxac.ld"
> - "hw/mcu/nordic/nrf51xxx/nrf51.ld"
> bsp.part2linkerscript: "hw/bsp/nrf51dk/split-nrf51dk.ld"
> -bsp.downloadscript: "hw/bsp/nrf51dk/nrf51dk_download.sh"
> -bsp.debugscript: "hw/bsp/nrf51dk/nrf51dk_debug.sh"
> +bsp.downloadscript: "hw/bsp/nrf51dk/nrf51dk_download.cmd"
> +bsp.debugscript: "hw/bsp/nrf51dk/nrf51dk_debug.cmd"
> bsp.flash_map:
> areas:
> diff --git a/hw/bsp/nrf51dk/nrf51dk_debug.cmd
> b/hw/bsp/nrf51dk/nrf51dk_debug.cmd
> new file mode 100644
> index 000..354743d
> --- /dev/null
> +++ b/hw/bsp/nrf51dk/nrf51dk_debug.cmd
> @@ -0,0 +1,2 @@
> +@rem Execute a shell with a script of the same name and .sh extension
> +@sh "%~dp0%~n0.sh"
> diff --git a/hw/bsp/nrf51dk/nrf51dk_download.cmd
> b/hw/bsp/nrf51dk/nrf51dk_download.cmd
> new file mode 100644
> index 000..354743d
> --- /dev/null
> +++ b/hw/bsp/nrf51dk/nrf51dk_download.cmd
> @@ -0,0 +1,2 @@
> +@rem Execute a shell with a script of the same name and .sh extension
> +@sh "%~dp0%~n0.sh"
> {noformat}
> At the very least, adding these scripts to the repo will allow devs to use
> `newt load` and `newt debug` on Windows with minimal effort (in combination
> with https://github.com/apache/incubator-mynewt-newt/pull/29 and
> https://github.com/apache/incubator-mynewt-core/pull/150).
> How to best automate this is a question to the devs; perhaps platform
> overrides in `bsp.yml` to specify platform-specific scripts?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MYNEWT-527) newt - Run bsp scripts on Windows
[
https://issues.apache.org/jira/browse/MYNEWT-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-527:
---
Fix Version/s: v1_0_0_rel
> newt - Run bsp scripts on Windows
> -
>
> Key: MYNEWT-527
> URL: https://issues.apache.org/jira/browse/MYNEWT-527
> Project: Mynewt
> Issue Type: Bug
> Components: Newt
>Affects Versions: v1_0_0_beta1
> Environment: Windows 10, WSL, MSYS2
>Reporter: Simon Ratner
>Assignee: Sterling Hughes
> Fix For: v1_0_0_rel
>
>
> Now that the `newt` tool no longer runs commands through a shell, it is not
> able to execute bsp scripts (`_download.sh` / `_debug.sh`) on Windows, where
> `CreateProcess` can't run shell scripts natively.
> A solution that works pretty well is to create parallel `_download.cmd` /
> `_debug.cmd` scripts with just the following:
> {noformat}
> @rem Execute a shell with a script of the same name and .sh extension
> @sh "%~dp0%~n0.sh"
> {noformat}
> And modify bsp.yml to use those instead, for example for `nrf51dk`:
> {noformat}
> diff --git a/hw/bsp/nrf51dk/bsp.yml b/hw/bsp/nrf51dk/bsp.yml
> index 5e78d60..95b57f6 100644
> --- a/hw/bsp/nrf51dk/bsp.yml
> +++ b/hw/bsp/nrf51dk/bsp.yml
> @@ -26,8 +26,8 @@ bsp.linkerscript.BOOT_LOADER.OVERWRITE:
> - "hw/bsp/nrf51dk/boot-nrf51xxac.ld"
> - "hw/mcu/nordic/nrf51xxx/nrf51.ld"
> bsp.part2linkerscript: "hw/bsp/nrf51dk/split-nrf51dk.ld"
> -bsp.downloadscript: "hw/bsp/nrf51dk/nrf51dk_download.sh"
> -bsp.debugscript: "hw/bsp/nrf51dk/nrf51dk_debug.sh"
> +bsp.downloadscript: "hw/bsp/nrf51dk/nrf51dk_download.cmd"
> +bsp.debugscript: "hw/bsp/nrf51dk/nrf51dk_debug.cmd"
> bsp.flash_map:
> areas:
> diff --git a/hw/bsp/nrf51dk/nrf51dk_debug.cmd
> b/hw/bsp/nrf51dk/nrf51dk_debug.cmd
> new file mode 100644
> index 000..354743d
> --- /dev/null
> +++ b/hw/bsp/nrf51dk/nrf51dk_debug.cmd
> @@ -0,0 +1,2 @@
> +@rem Execute a shell with a script of the same name and .sh extension
> +@sh "%~dp0%~n0.sh"
> diff --git a/hw/bsp/nrf51dk/nrf51dk_download.cmd
> b/hw/bsp/nrf51dk/nrf51dk_download.cmd
> new file mode 100644
> index 000..354743d
> --- /dev/null
> +++ b/hw/bsp/nrf51dk/nrf51dk_download.cmd
> @@ -0,0 +1,2 @@
> +@rem Execute a shell with a script of the same name and .sh extension
> +@sh "%~dp0%~n0.sh"
> {noformat}
> At the very least, adding these scripts to the repo will allow devs to use
> `newt load` and `newt debug` on Windows with minimal effort (in combination
> with https://github.com/apache/incubator-mynewt-newt/pull/29 and
> https://github.com/apache/incubator-mynewt-core/pull/150).
> How to best automate this is a question to the devs; perhaps platform
> overrides in `bsp.yml` to specify platform-specific scripts?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MYNEWT-582) "go get mynewt.apache.org/newt/newt" fails
[
https://issues.apache.org/jira/browse/MYNEWT-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes reassigned MYNEWT-582:
--
Assignee: Todd Mitton (was: Sterling Hughes)
> "go get mynewt.apache.org/newt/newt" fails
> --
>
> Key: MYNEWT-582
> URL: https://issues.apache.org/jira/browse/MYNEWT-582
> Project: Mynewt
> Issue Type: Bug
> Components: Newt
>Reporter: David Brown
>Assignee: Todd Mitton
>Priority: Minor
>
> It isn't possible to develop mynewt using conventional go methods, or to use
> it as a dependency in another package.
> The problem is that the https://mynewt.apache.org/newt/ doesn't return valid
> results for subdirectories.
> {code}
> curl https://mynewt.apache.org/newt/
> curl https://mynewt.apache.org/newt/newt/
> curl https://mynewt.apache.org/newt/newt/image/
> {code}
> The first above command returns valid redirects for github, but the second
> just returns a 404. This causes the git fetch to fail.
> If something such as mcuboot/imgtool tries to use
> https://mynewt.apache.org/newt/newt/image as a dependency, it also fails to
> fetch this.
> I believe the fix is to return the metadata page for subdirectories. At least
> 'newt/newt' and 'newt/newt/image' should be used, the first to make the newt
> tool itself buildable, and the second to allow the image library to be used
> as a dependency by mcuboot.
> Probably add the other top level ones, such as newtmgr as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MYNEWT-583) Allow project.yml to specify a commit hash
[ https://issues.apache.org/jira/browse/MYNEWT-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884484#comment-15884484 ] Sterling Hughes commented on MYNEWT-583: let's see if we can't get this into 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_0_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] [Updated] (MYNEWT-572) newtmgr reset command succeeds under the hood, yet fails to recover
[
https://issues.apache.org/jira/browse/MYNEWT-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-572:
---
Fix Version/s: v1_0_0_rel
> newtmgr reset command succeeds under the hood, yet fails to recover
> ---
>
> Key: MYNEWT-572
> URL: https://issues.apache.org/jira/browse/MYNEWT-572
> Project: Mynewt
> Issue Type: Bug
> Components: Newtmgr
> Environment: develop branch
> macos
> nrf51-16kbram target
>Reporter: Jacob
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The reset after image confirm is successful, but newtmgr is having trouble
> recovering from the command:
> Ive seen it error like this:
> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr reset -cserial1
> -t -ldebug
> 2017/01/25 17:13:31 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:2
> Group:0 Seq:0 Id:5 Data:[123 125]}
> 2017/01/25 17:13:31 [DEBUG] Serializing request &{Op:2 Flags:0 Len:2 Group:0
> Seq:0 Id:5 Data:[123 125]} into buffer [2 0 0 2 0 0 0 5 123 125]
> 2017/01/25 17:13:31 [DEBUG] Tx packet dump:
> 02 00 00 02 00 00 00 05 7b 7d|{}|
> 2017/01/25 17:13:31 [INFO] Outgoing:
> 06 09 |..|
> 2017/01/25 17:13:31 [DEBUG] Writing [6 9] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
> 41 41 77 43 41 41 41 43 41 41 41 41 42 58 74 39 |AAwCAAACBXt9|
> 0010 4c 67 41 3d |LgA=|
> 2017/01/25 17:13:31 [DEBUG] Writing [65 65 119 67 65 65 65 67 65 65 65 65 66
> 88 116 57 76 103 65 61] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
> 0a|.|
> 2017/01/25 17:13:31 [DEBUG] Writing [10] to data channel
> 2017/01/25 17:13:44 [INFO] Incoming:
> 06 09 41 41 77 43 41 41 41 43 41 41 41 41 42 58 |..AAwCAAACBX|
> 0010 74 39 4c 67 41 3d 31 3a |t9LgA=1:|
> 2017/01/25 17:13:44 [DEBUG] Reading [6 9 65 65 119 67 65 65 65 67 65 65 65 65
> 66 88 116 57 76 103 65 61 49 58] from data channel
> 2017/01/25 17:13:44 [INFO] Message: base64 decode error
> 2017/01/25 17:13:44 [DEBUG] goroutine 1 [running]:
> mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util.NewNewtError(0xc420160380,
> 0xdd, 0xc42004bb50)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util/util.go:75
> +0x111
> mynewt.apache.org/newt/newtmgr/transport.(*ConnSerial).ReadPacket(0xc420140870,
> 0xc420146c00, 0x4080a8a, 0xc420140870)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/transport/connserial.go:149
> +0x7b2
> mynewt.apache.org/newt/newtmgr/protocol.(*CmdRunner).ReadResp(0xc42015f210,
> 0xc4201468c0, 0x0, 0x0)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/protocol/cmdrunner.go:42
> +0x9c
> mynewt.apache.org/newt/newtmgr/cli.resetRunCmd(0xc42016c240, 0xc420140630,
> 0x0, 0x3)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/cli/reset.go:50
> +0x1ab
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).execute(0xc42016c240,
> 0xc420140480, 0x3, 0x3, 0xc42016c240, 0xc420140480)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:636
> +0x443
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420166000,
> 0xc420166b40, 0xc420166240, 0xc42015eec0)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:722
> +0x367
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420166000,
> 0x40d65bc, 0xc421a0)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:681
> +0x2b
> main.main()
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/newtmgr.go:25
> +0x2f
> goroutine 17 [syscall, locked to thread]:
> runtime.goexit()
> /usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/asm_amd64.s:2086 +0x1
> goroutine 5 [syscall]:
> os/signal.signal_recv(0x0)
> /usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/sigqueue.go:116 +0x157
> os/signal.loop()
> /usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:22
> +0x22
> created by os/signal.init.1
> /usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:28
> +0x41
> Error: Couldn't decode base64 string: AAwCAAACBXt9LgA=1:
> Packet hex dump:
> 06 09 41 41 77 43 41 41 41 43 41 41 41 41 42 58 |..AAwCAAACBX|
> 0010 74 39 4c 67 41 3d 31 3a |t9LgA=1:|
> reset - Send re
[jira] [Assigned] (MYNEWT-572) newtmgr reset command succeeds under the hood, yet fails to recover
[
https://issues.apache.org/jira/browse/MYNEWT-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes reassigned MYNEWT-572:
--
Assignee: Christopher Collins (was: Sterling Hughes)
> newtmgr reset command succeeds under the hood, yet fails to recover
> ---
>
> Key: MYNEWT-572
> URL: https://issues.apache.org/jira/browse/MYNEWT-572
> Project: Mynewt
> Issue Type: Bug
> Components: Newtmgr
> Environment: develop branch
> macos
> nrf51-16kbram target
>Reporter: Jacob
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The reset after image confirm is successful, but newtmgr is having trouble
> recovering from the command:
> Ive seen it error like this:
> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr reset -cserial1
> -t -ldebug
> 2017/01/25 17:13:31 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:2
> Group:0 Seq:0 Id:5 Data:[123 125]}
> 2017/01/25 17:13:31 [DEBUG] Serializing request &{Op:2 Flags:0 Len:2 Group:0
> Seq:0 Id:5 Data:[123 125]} into buffer [2 0 0 2 0 0 0 5 123 125]
> 2017/01/25 17:13:31 [DEBUG] Tx packet dump:
> 02 00 00 02 00 00 00 05 7b 7d|{}|
> 2017/01/25 17:13:31 [INFO] Outgoing:
> 06 09 |..|
> 2017/01/25 17:13:31 [DEBUG] Writing [6 9] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
> 41 41 77 43 41 41 41 43 41 41 41 41 42 58 74 39 |AAwCAAACBXt9|
> 0010 4c 67 41 3d |LgA=|
> 2017/01/25 17:13:31 [DEBUG] Writing [65 65 119 67 65 65 65 67 65 65 65 65 66
> 88 116 57 76 103 65 61] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
> 0a|.|
> 2017/01/25 17:13:31 [DEBUG] Writing [10] to data channel
> 2017/01/25 17:13:44 [INFO] Incoming:
> 06 09 41 41 77 43 41 41 41 43 41 41 41 41 42 58 |..AAwCAAACBX|
> 0010 74 39 4c 67 41 3d 31 3a |t9LgA=1:|
> 2017/01/25 17:13:44 [DEBUG] Reading [6 9 65 65 119 67 65 65 65 67 65 65 65 65
> 66 88 116 57 76 103 65 61 49 58] from data channel
> 2017/01/25 17:13:44 [INFO] Message: base64 decode error
> 2017/01/25 17:13:44 [DEBUG] goroutine 1 [running]:
> mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util.NewNewtError(0xc420160380,
> 0xdd, 0xc42004bb50)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util/util.go:75
> +0x111
> mynewt.apache.org/newt/newtmgr/transport.(*ConnSerial).ReadPacket(0xc420140870,
> 0xc420146c00, 0x4080a8a, 0xc420140870)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/transport/connserial.go:149
> +0x7b2
> mynewt.apache.org/newt/newtmgr/protocol.(*CmdRunner).ReadResp(0xc42015f210,
> 0xc4201468c0, 0x0, 0x0)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/protocol/cmdrunner.go:42
> +0x9c
> mynewt.apache.org/newt/newtmgr/cli.resetRunCmd(0xc42016c240, 0xc420140630,
> 0x0, 0x3)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/cli/reset.go:50
> +0x1ab
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).execute(0xc42016c240,
> 0xc420140480, 0x3, 0x3, 0xc42016c240, 0xc420140480)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:636
> +0x443
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420166000,
> 0xc420166b40, 0xc420166240, 0xc42015eec0)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:722
> +0x367
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420166000,
> 0x40d65bc, 0xc421a0)
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:681
> +0x2b
> main.main()
>
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/newtmgr.go:25
> +0x2f
> goroutine 17 [syscall, locked to thread]:
> runtime.goexit()
> /usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/asm_amd64.s:2086 +0x1
> goroutine 5 [syscall]:
> os/signal.signal_recv(0x0)
> /usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/sigqueue.go:116 +0x157
> os/signal.loop()
> /usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:22
> +0x22
> created by os/signal.init.1
> /usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:28
> +0x41
> Error: Couldn't decode base64 string: AAwCAAACBXt9LgA=1:
> Packet hex dump:
> 06 09 41 41 77 43 41 41 41 43 41 41 41 41 42 58 |..AAwCAAACBX|
> 0010 74 39 4c 67 41 3d 31 3a
[jira] [Assigned] (MYNEWT-583) Allow project.yml to specify a commit hash
[ https://issues.apache.org/jira/browse/MYNEWT-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes reassigned MYNEWT-583: -- Assignee: Marko Kiiskila (was: Sterling Hughes) > 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_0_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] [Updated] (MYNEWT-583) Allow project.yml to specify a commit hash
[ https://issues.apache.org/jira/browse/MYNEWT-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-583: --- Fix Version/s: v1_0_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_0_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] [Assigned] (MYNEWT-548) The blinky.elf created by the Create Your First Mynewt Project tutorial runs only on linux
[ https://issues.apache.org/jira/browse/MYNEWT-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes reassigned MYNEWT-548: -- Assignee: Aditi Hilbert > The blinky.elf created by the Create Your First Mynewt Project tutorial runs > only on linux > -- > > Key: MYNEWT-548 > URL: https://issues.apache.org/jira/browse/MYNEWT-548 > Project: Mynewt > Issue Type: Bug >Affects Versions: v1_0_0_beta1 > Environment: macOS, Docker >Reporter: Liviu Ionescu >Assignee: Aditi Hilbert > Fix For: v1_0_0_rel > > > I followed your basic setup instructions and installed the Docker version of > `newt`. > Then I followed > https://mynewt.apache.org/latest/os/get_started/project_create/ to create and > build the `my_blinky_sim` application. > When trying to run the binary, not only the path is incorrect > (`./bin/my_blinky_sim/apps/blinky/blinky.elf`), but the file is a Linux > binary: > ``` > file ./bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf > ./bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf: ELF 32-bit LSB > executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter > /lib/ld-linux.so.2, for GNU/Linux 2.6.32, > BuildID[sha1]=d66139b97ed3cd7d9c9e41a03137d91002c706b2, not stripped > ``` > I do not know if it is possible to create macOS applications, if not, the > documentation should clearly state that the simulated applications run only > on Linux; if it is possible, the documentation should explain how to do it. > does installing `newt` natively allow to generate macOS applications? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-548) The blinky.elf created by the Create Your First Mynewt Project tutorial runs only on linux
[ https://issues.apache.org/jira/browse/MYNEWT-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884483#comment-15884483 ] Sterling Hughes commented on MYNEWT-548: Hi Liviu, it does. If you use newt docker on mac os x, you need to use "newt run" to run the simulated binary. If you natively install the toolchain, you can either call the binary directly, or use newt run. newt run is the expected way to call things. I'm assigning this to Aditi to add a note to the documentation. > The blinky.elf created by the Create Your First Mynewt Project tutorial runs > only on linux > -- > > Key: MYNEWT-548 > URL: https://issues.apache.org/jira/browse/MYNEWT-548 > Project: Mynewt > Issue Type: Bug >Affects Versions: v1_0_0_beta1 > Environment: macOS, Docker >Reporter: Liviu Ionescu > Fix For: v1_0_0_rel > > > I followed your basic setup instructions and installed the Docker version of > `newt`. > Then I followed > https://mynewt.apache.org/latest/os/get_started/project_create/ to create and > build the `my_blinky_sim` application. > When trying to run the binary, not only the path is incorrect > (`./bin/my_blinky_sim/apps/blinky/blinky.elf`), but the file is a Linux > binary: > ``` > file ./bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf > ./bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf: ELF 32-bit LSB > executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter > /lib/ld-linux.so.2, for GNU/Linux 2.6.32, > BuildID[sha1]=d66139b97ed3cd7d9c9e41a03137d91002c706b2, not stripped > ``` > I do not know if it is possible to create macOS applications, if not, the > documentation should clearly state that the simulated applications run only > on Linux; if it is possible, the documentation should explain how to do it. > does installing `newt` natively allow to generate macOS applications? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-548) The blinky.elf created by the Create Your First Mynewt Project tutorial runs only on linux
[ https://issues.apache.org/jira/browse/MYNEWT-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-548: --- Fix Version/s: v1_0_0_rel > The blinky.elf created by the Create Your First Mynewt Project tutorial runs > only on linux > -- > > Key: MYNEWT-548 > URL: https://issues.apache.org/jira/browse/MYNEWT-548 > Project: Mynewt > Issue Type: Bug >Affects Versions: v1_0_0_beta1 > Environment: macOS, Docker >Reporter: Liviu Ionescu >Assignee: Aditi Hilbert > Fix For: v1_0_0_rel > > > I followed your basic setup instructions and installed the Docker version of > `newt`. > Then I followed > https://mynewt.apache.org/latest/os/get_started/project_create/ to create and > build the `my_blinky_sim` application. > When trying to run the binary, not only the path is incorrect > (`./bin/my_blinky_sim/apps/blinky/blinky.elf`), but the file is a Linux > binary: > ``` > file ./bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf > ./bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf: ELF 32-bit LSB > executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter > /lib/ld-linux.so.2, for GNU/Linux 2.6.32, > BuildID[sha1]=d66139b97ed3cd7d9c9e41a03137d91002c706b2, not stripped > ``` > I do not know if it is possible to create macOS applications, if not, the > documentation should clearly state that the simulated applications run only > on Linux; if it is possible, the documentation should explain how to do it. > does installing `newt` natively allow to generate macOS applications? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-634) blecent ble_gap_connect failing with rc 21
[
https://issues.apache.org/jira/browse/MYNEWT-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884481#comment-15884481
]
Sterling Hughes commented on MYNEWT-634:
Can we look at this prior to 1.0-rel?
> blecent ble_gap_connect failing with rc 21
> --
>
> Key: MYNEWT-634
> URL: https://issues.apache.org/jira/browse/MYNEWT-634
> Project: Mynewt
> Issue Type: Bug
> Components: Nimble
>Affects Versions: v1_0_0_beta2
>Reporter: Jacob
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> blecent ble_gap_connect used to work with my heartrate device but is now
> failing with rc 21
> Tracked back to ble_hs_id_addr
>│156 if (memcmp(id_addr, ble_hs_misc_null_addr, 6) == 0) {
>│157 return BLE_HS_ENOADDR;
>│158 }
> (gdb) p id_addr_type
> $8 = 0 '\000'
> (gdb) p ble_hs_id_pub
> $9 = "\000\000\000\000\000"
> (gdb) p ble_hs_misc_null_addr
> $3 = "\000\000\000\000\000"
> (gdb) p *id_addr
> $5 = 0 '\000'
> (gdb) set $foo = memcmp(id_addr, ble_hs_misc_null_addr, 6)
> (gdb) p $foo
> $6 = 0
> There was some recent address changes I dont currently understand, maybe that
> has to do with it?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MYNEWT-634) blecent ble_gap_connect failing with rc 21
[
https://issues.apache.org/jira/browse/MYNEWT-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes reassigned MYNEWT-634:
--
Assignee: Christopher Collins
> blecent ble_gap_connect failing with rc 21
> --
>
> Key: MYNEWT-634
> URL: https://issues.apache.org/jira/browse/MYNEWT-634
> Project: Mynewt
> Issue Type: Bug
> Components: Nimble
>Affects Versions: v1_0_0_beta2
>Reporter: Jacob
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> blecent ble_gap_connect used to work with my heartrate device but is now
> failing with rc 21
> Tracked back to ble_hs_id_addr
>│156 if (memcmp(id_addr, ble_hs_misc_null_addr, 6) == 0) {
>│157 return BLE_HS_ENOADDR;
>│158 }
> (gdb) p id_addr_type
> $8 = 0 '\000'
> (gdb) p ble_hs_id_pub
> $9 = "\000\000\000\000\000"
> (gdb) p ble_hs_misc_null_addr
> $3 = "\000\000\000\000\000"
> (gdb) p *id_addr
> $5 = 0 '\000'
> (gdb) set $foo = memcmp(id_addr, ble_hs_misc_null_addr, 6)
> (gdb) p $foo
> $6 = 0
> There was some recent address changes I dont currently understand, maybe that
> has to do with it?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MYNEWT-634) blecent ble_gap_connect failing with rc 21
[
https://issues.apache.org/jira/browse/MYNEWT-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-634:
---
Fix Version/s: v1_0_0_rel
> blecent ble_gap_connect failing with rc 21
> --
>
> Key: MYNEWT-634
> URL: https://issues.apache.org/jira/browse/MYNEWT-634
> Project: Mynewt
> Issue Type: Bug
> Components: Nimble
>Affects Versions: v1_0_0_beta2
>Reporter: Jacob
> Fix For: v1_0_0_rel
>
>
> blecent ble_gap_connect used to work with my heartrate device but is now
> failing with rc 21
> Tracked back to ble_hs_id_addr
>│156 if (memcmp(id_addr, ble_hs_misc_null_addr, 6) == 0) {
>│157 return BLE_HS_ENOADDR;
>│158 }
> (gdb) p id_addr_type
> $8 = 0 '\000'
> (gdb) p ble_hs_id_pub
> $9 = "\000\000\000\000\000"
> (gdb) p ble_hs_misc_null_addr
> $3 = "\000\000\000\000\000"
> (gdb) p *id_addr
> $5 = 0 '\000'
> (gdb) set $foo = memcmp(id_addr, ble_hs_misc_null_addr, 6)
> (gdb) p $foo
> $6 = 0
> There was some recent address changes I dont currently understand, maybe that
> has to do with it?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MYNEWT-435) Incorrect usage of CONF_VALUE_SET with string variable
[ https://issues.apache.org/jira/browse/MYNEWT-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes reassigned MYNEWT-435: -- Assignee: Marko Kiiskila Can we look at this prior to rel? > Incorrect usage of CONF_VALUE_SET with string variable > -- > > Key: MYNEWT-435 > URL: https://issues.apache.org/jira/browse/MYNEWT-435 > Project: Mynewt > Issue Type: Bug >Affects Versions: v0_9_0 >Reporter: hathach >Assignee: Marko Kiiskila > > In app/slinky line 172 > https://github.com/apache/incubator-mynewt-core/blob/master/apps/slinky/src/main.c#L172 > CONF_VALUE_SET(val, CONF_STRING, test_str) will be expanded to > conf_value_from_str((val), (CONF_STRING), &(test_str), sizeof(test_str)). > test_str should be passed instead of &test_str since it is declared as char > array. > Similarly there is other few places > - > https://github.com/apache/incubator-mynewt-core/blob/master/sys/id/src/id.c#L83 > - > https://github.com/apache/incubator-mynewt-core/blob/master/sys/reboot/src/log_reboot.c#L186 > - > https://github.com/apache/incubator-mynewt-core/blob/master/sys/reboot/src/log_reboot.c#L193 > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-620) my_blinky_sim not compiling (docker image on ubuntu 14.04)
[
https://issues.apache.org/jira/browse/MYNEWT-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-620:
---
Affects Version/s: v1_0_0_rel
> 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: Marko Kiiskila
>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-620) my_blinky_sim not compiling (docker image on ubuntu 14.04)
[
https://issues.apache.org/jira/browse/MYNEWT-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes reassigned MYNEWT-620:
--
Assignee: Marko Kiiskila (was: Sterling Hughes)
We need to fix this prior to 1.0. Marko, can you take a look?
> 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: Marko Kiiskila
>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] [Updated] (MYNEWT-620) my_blinky_sim not compiling (docker image on ubuntu 14.04)
[
https://issues.apache.org/jira/browse/MYNEWT-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-620:
---
Fix Version/s: v1_0_0_rel
> 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: Marko Kiiskila
>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] [Commented] (MYNEWT-641) Error in 'newt build nrf52_boot'
[ https://issues.apache.org/jira/browse/MYNEWT-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884478#comment-15884478 ] Sterling Hughes commented on MYNEWT-641: Hi Anthony, Sorry for the inconvenience, but that error typically happens when you have an out of date newt. Would you mind upgrading newt and seeing if you have the same issue? With 1.0 we will be maintaining newt so you don't have these problems: sorry about this. Sterling > 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: Marko Kiiskila >Priority: Minor > > 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] [Updated] (MYNEWT-565) Should have USB and BTLE HID support
[ https://issues.apache.org/jira/browse/MYNEWT-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-565: --- Fix Version/s: v1_1_beta1 > Should have USB and BTLE HID support > > > Key: MYNEWT-565 > URL: https://issues.apache.org/jira/browse/MYNEWT-565 > Project: Mynewt > Issue Type: Improvement >Reporter: Sterling Hughes >Assignee: Fabio Utzig > Fix For: v1_1_beta1 > > > As we look at initial USB support, I think it would be good to target a > consistent interface for HID across both BLE and USB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYNEWT-565) Should have USB and BTLE HID support
Sterling Hughes created MYNEWT-565: -- Summary: Should have USB and BTLE HID support Key: MYNEWT-565 URL: https://issues.apache.org/jira/browse/MYNEWT-565 Project: Mynewt Issue Type: Improvement Reporter: Sterling Hughes Assignee: Fabio Utzig As we look at initial USB support, I think it would be good to target a consistent interface for HID across both BLE and USB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15838535#comment-15838535 ] Sterling Hughes commented on MYNEWT-490: Moving to 1.1 - we should release note that this will likely change in the 1.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 >Reporter: Sterling Hughes >Assignee: Marko Kiiskila > Fix For: v1_1_beta1 > > > 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.3.4#6332)
[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 ] Sterling Hughes updated MYNEWT-490: --- Fix Version/s: (was: v1_0_0_beta2) v1_1_beta1 > 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 >Reporter: Sterling Hughes >Assignee: Marko Kiiskila > Fix For: v1_1_beta1 > > > 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.3.4#6332)
[jira] [Updated] (MYNEWT-558) newt - depgraph should indicate soft vs. hard dependency
[ https://issues.apache.org/jira/browse/MYNEWT-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-558: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > newt - depgraph should indicate soft vs. hard dependency > > > Key: MYNEWT-558 > URL: https://issues.apache.org/jira/browse/MYNEWT-558 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_0_0_rel > > > The `target dep` and `target revdep` commands only indicate package names in > the dependency graph. It would be helpful to see what created the dependency > in the first place. Specifically, it would be good to know if the dependency > is "hard" (package explicitly depends on another) or "soft" (package requires > an API; other package happens to implement that API). This is useful when > trying to completely remove a package from a build. > Unfortunately, this information is lost at the time dependency graphs are > generated. Rather than use a builder's package map, dependency generation > should operate on an intermediate form produced by the `resolve` package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-41) Improve regression test coverage
[ https://issues.apache.org/jira/browse/MYNEWT-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-41: -- Fix Version/s: (was: v1_0_0_beta2) > Improve regression test coverage > > > Key: MYNEWT-41 > URL: https://issues.apache.org/jira/browse/MYNEWT-41 > Project: Mynewt > Issue Type: Improvement > 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.4#6332)
[jira] [Updated] (MYNEWT-545) newt - Newt doesn't limit size of loader images.
[ https://issues.apache.org/jira/browse/MYNEWT-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-545: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > newt - Newt doesn't limit size of loader images. > > > Key: MYNEWT-545 > URL: https://issues.apache.org/jira/browse/MYNEWT-545 > Project: Mynewt > Issue Type: Bug > Components: Newt >Reporter: Christopher Collins >Assignee: Sterling Hughes > Fix For: v1_0_0_rel > > > Normally, a BSP's linker script limits the size of an image. When newt > builds a split image, it uses some strange linker magic, so the BSP's flash > size doesn't get used as a maximum image size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-556) The newt tool does not generate an error for priority violations of configuration setting overrides
[ https://issues.apache.org/jira/browse/MYNEWT-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-556: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > The newt tool does not generate an error for priority violations of > configuration setting overrides > --- > > Key: MYNEWT-556 > URL: https://issues.apache.org/jira/browse/MYNEWT-556 > Project: Mynewt > Issue Type: Bug > Components: Newt >Affects Versions: v1_0_0_beta1 >Reporter: Wanda Chiu >Assignee: Wanda Chiu > Fix For: v1_0_0_rel > > > When a package of the same or lower priority package overrides a setting > defined by a higher priority package, newt silently ignores the overrides. > Newt should generate a priority violation error. > newt only checks for Lateral violations (lib packages overriding a setting > defined by another lib packages). This is a special case of priority > violation and should be treated as a priority violation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-13) NFFS does not work on STM32F3
[ https://issues.apache.org/jira/browse/MYNEWT-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-13: -- Fix Version/s: (was: v1_0_0_beta2) v1_1_beta1 > NFFS does not work on STM32F3 > - > > Key: MYNEWT-13 > URL: https://issues.apache.org/jira/browse/MYNEWT-13 > Project: Mynewt > Issue Type: Bug > Components: NFFS >Reporter: Marko Kiiskila >Assignee: Christopher Collins >Priority: Minor > Fix For: v1_1_beta1 > > > STM32F3 flash writes are done 2 bytes at a time. NFFS should take into > account alignment restrictions underlying storage has. > E.g. add alignment requirement in struct hal_flash. Add an HAL flash API call > to query this. NFFS would then use this when writing/reading blocks of data > from flash. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-557) Newt build command does not print out a warning when overriding an undefined configuration setting
[ https://issues.apache.org/jira/browse/MYNEWT-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-557: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > Newt build command does not print out a warning when overriding an undefined > configuration setting > -- > > Key: MYNEWT-557 > URL: https://issues.apache.org/jira/browse/MYNEWT-557 > Project: Mynewt > Issue Type: Bug > Components: Newt >Affects Versions: v1_0_0_beta1 >Reporter: Wanda Chiu >Assignee: Wanda Chiu > Fix For: v1_0_0_rel > > > The newt build command ignores overriding an undefined configuration setting. > There should be a warning message to let the user know because the error may > be caused by typo with the configuration setting name. This can create > unexpected behavior because the user thinks the override was successful. Note > that the newt target config command does output a warning message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYNEWT-542) Controller does not work if os cputime set to a value other than 1 MHz.
[ https://issues.apache.org/jira/browse/MYNEWT-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes resolved MYNEWT-542. Resolution: Fixed > Controller does not work if os cputime set to a value other than 1 MHz. > --- > > Key: MYNEWT-542 > URL: https://issues.apache.org/jira/browse/MYNEWT-542 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Affects Versions: v1_0_0_beta1 >Reporter: William San Filippo >Assignee: William San Filippo > Fix For: v1_0_0_beta2 > > > The default os cputime was changed from 1 MHz to 2 MHz and the controller > failed to connect. This was tried on a nrf52 platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-538) Add RTC to hal timer for nordic platforms
[ https://issues.apache.org/jira/browse/MYNEWT-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-538: --- Fix Version/s: (was: v1_0_0_beta2) v1_1_beta1 > Add RTC to hal timer for nordic platforms > - > > Key: MYNEWT-538 > URL: https://issues.apache.org/jira/browse/MYNEWT-538 > Project: Mynewt > Issue Type: New Feature >Affects Versions: v1_0_0_beta1 >Reporter: William San Filippo >Assignee: William San Filippo > Fix For: v1_1_beta1 > > > The current hal timer implementation for the nordic platforms does not > include any RTC timers. These need to be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-522) Callout API should be improved to add a "call back at" timer function.
[ https://issues.apache.org/jira/browse/MYNEWT-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-522: --- Fix Version/s: (was: v1_0_0_beta2) v1_1_beta1 > 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 > Components: OS >Affects Versions: v1_0_0_beta2 >Reporter: Sterling Hughes > Fix For: v1_1_beta1 > > > 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.4#6332)
[jira] [Resolved] (MYNEWT-510) sysinit - Remove from pkg.yml; put init functions in a linker section
[ https://issues.apache.org/jira/browse/MYNEWT-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes resolved MYNEWT-510. Resolution: Won't Fix > sysinit - Remove from pkg.yml; put init functions in a linker section > - > > Key: MYNEWT-510 > URL: https://issues.apache.org/jira/browse/MYNEWT-510 > Project: Mynewt > Issue Type: Bug > Components: Misc >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_0_0_beta2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYNEWT-512) Replace generated sysinit code with linker section
[
https://issues.apache.org/jira/browse/MYNEWT-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes resolved MYNEWT-512.
Resolution: Won't Fix
> Replace generated sysinit code with linker section
> --
>
> Key: MYNEWT-512
> URL: https://issues.apache.org/jira/browse/MYNEWT-512
> Project: Mynewt
> Issue Type: Improvement
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_beta2
>
>
> *Old mechanism:*
> * pkg.yml file specifies "init_function" and "init_stage"
> * newt generates sysinit C files which call the packages' init functions in
> the specified order.
> *New mechanism:*
> * Each package defines an "init entry" struct containing:
> ** pointer to init function
> ** uint8_t stage
> * Init entry structs are placed in a special section.
> * At startup, the sysinit() function walks the list of entries in the special
> section and calls their corresponding init functions in the correct order.
> *Interface*
> {code}
> typedef void sysinit_init_fn(struct sysinit_init_ctxt *ctxt);
> struct sysinit_entry {
> sysinit_init_fn *init_fn;
> uint8_t stage;
> };
> struct sysinit_init_ctxt {
> const struct sysinit_entry *entry;
> uint8_t cur_stage;
> };
> #define SYSINIT_REGISTER_INIT(init_cb, init_stage) // ...
> {code}
> User defines a package initialization function and registers it.
> Registration creates a {{struct sysinit_entry}} instance in the special
> "sysinit" section.
> *Example:*
> {code}
> static void
> my_pkg_init(void)
> {
> /* ... */
> }
> SYSINIT_REGISTER(my_pkg_init, 2);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYNEWT-497) Cleanup newtmgr debug output
[
https://issues.apache.org/jira/browse/MYNEWT-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-497:
---
Assignee: Fabio Utzig
> Cleanup newtmgr debug output
>
>
> Key: MYNEWT-497
> URL: https://issues.apache.org/jira/browse/MYNEWT-497
> Project: Mynewt
> Issue Type: Improvement
>Affects Versions: v1_0_0_beta2
>Reporter: Sterling Hughes
>Assignee: Fabio Utzig
> Fix For: v1_0_0_rel
>
>
> Hi Christopher,
> The latest version has improved debug output with the combined HEX and DEC
> which I don't remember in earlier versions, so thanks for that. We've been
> using the -t trace option but it's good to point out to anyone who stumbles
> across this thread anyway.
> I don't find the DEC very useful in the [DEBUG] output lines within 'Data:'
> which is what I was referring to in the original email, but the TX packet
> dump is a nice approach where you list both HEX and ASCII. My brain is just
> hard-wired to HEX and I find myself converting the verbose DEC values on top
> (which are very useful for the labels) into the HEX payload below to match
> things up. 100% HEX might be more natural for a lot of people.
> Between -lDEBUG and -t we were able to get everything we needed and there are
> higher priority things to cleanup, and I'm happy to have what is there today,
> but I'd say just dropping DEC altogether probably isn't going to cause any
> problems ... but perhaps other users will disagree???
> On 30/11/16 17:42, Christopher Collins wrote:
> I accidently wrapped the newtmgr output with short lines. Here is the
> unadalterated output:
> [ccollins@ccollins-mac:~/releases/1.0.0-b1/rc2]$ newtmgr -ldebug -c ttys010
> echo abc123
> 2016/11/30 08:25:57 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:10
> Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]}
> 2016/11/30 08:25:57 [DEBUG] Serializing request &{Op:2 Flags:0 Len:10 Group:0
> Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]} into buffer [2 0 0 10 0 0
> 0 0 161 97 100 102 97 98 99 49 50 51]
> 2016/11/30 08:25:57 [DEBUG] Tx packet dump:
> 02 00 00 0a 00 00 00 00 a1 61 64 66 61 62 63 31 |.adfabc1|
> 0010 32 33 |23|
> 2016/11/30 08:25:57 [DEBUG] Writing [6 9] to data channel
> 2016/11/30 08:25:57 [DEBUG] Writing [65 66 81 67 65 65 65 75 65 65 65 65 65
> 75 70 104 90 71 90 104 89 109 77 120 77 106 79 53 57 65 61 61] to data channel
> 2016/11/30 08:25:57 [DEBUG] Writing [10] to data channel
> ^C
> [ccollins@ccollins-mac:~/releases/1.0.0-b1/rc2]$ newtmgr -t -ldebug -c
> ttys010 echo abc123
> 2016/11/30 08:26:13 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:10
> Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]}
> 2016/11/30 08:26:13 [DEBUG] Serializing request &{Op:2 Flags:0 Len:10 Group:0
> Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]} into buffer [2 0 0 10 0 0
> 0 0 161 97 100 102 97 98 99 49 50 51]
> 2016/11/30 08:26:13 [DEBUG] Tx packet dump:
> 02 00 00 0a 00 00 00 00 a1 61 64 66 61 62 63 31 |.adfabc1|
> 0010 32 33 |23|
> 2016/11/30 08:26:13 [INFO] Outgoing:
> 06 09 |..|
> 2016/11/30 08:26:13 [DEBUG] Writing [6 9] to data channel
> 2016/11/30 08:26:13 [INFO] Outgoing:
> 41 42 51 43 41 41 41 4b 41 41 41 41 41 4b 46 68 |ABQCAAAKAKFh|
> 0010 5a 47 5a 68 59 6d 4d 78 4d 6a 4f 35 39 41 3d 3d |ZGZhYmMxMjO59A==|
> 2016/11/30 08:26:13 [DEBUG] Writing [65 66 81 67 65 65 65 75 65 65 65 65 65
> 75 70 104 90 71 90 104 89 109 77 120 77 106 79 53 57 65 61 61] to data channel
> 2016/11/30 08:26:13 [INFO] Outgoing:
> 0a|.|
> 2016/11/30 08:26:13 [DEBUG] Writing [10] to data channel
> ^C
> Thanks,
> Chris
> On Wed, Nov 30, 2016 at 08:40:39AM -0800, Christopher Collins wrote:
> Hi Kevin,
> On Wed, Nov 30, 2016 at 01:37:38PM +0100, Kevin Townsend wrote:
> We're currently working on a mobile version of newtmgr, and the DEBUG
> output is very useful to sanity check commands and responses, but the
> output in DEC is kind of a pain when most SW engineering on embedded
> devices is done in HEX. Is there an option I'm missing to output HEX
> instead of DEC, or is this something worth considering changing
> internally in the tool to default to HEX which feels like a far more
> natural choice from my PoV?
> The newtmgr debug output is pretty much a mess at the moment. That
> said, it does do a hex dump of incoming and outgoing packets when you
> specify the "-ldebug" flag. If you are only seeing decimal output, then
> is it possible you are using an old version of newtmgr?
> The reason I say the debug output is a mess is that it prints both a
> d
[jira] [Updated] (MYNEWT-497) Cleanup newtmgr debug output
[
https://issues.apache.org/jira/browse/MYNEWT-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-497:
---
Fix Version/s: (was: v1_0_0_beta2)
v1_0_0_rel
> Cleanup newtmgr debug output
>
>
> Key: MYNEWT-497
> URL: https://issues.apache.org/jira/browse/MYNEWT-497
> Project: Mynewt
> Issue Type: Improvement
>Affects Versions: v1_0_0_beta2
>Reporter: Sterling Hughes
> Fix For: v1_0_0_rel
>
>
> Hi Christopher,
> The latest version has improved debug output with the combined HEX and DEC
> which I don't remember in earlier versions, so thanks for that. We've been
> using the -t trace option but it's good to point out to anyone who stumbles
> across this thread anyway.
> I don't find the DEC very useful in the [DEBUG] output lines within 'Data:'
> which is what I was referring to in the original email, but the TX packet
> dump is a nice approach where you list both HEX and ASCII. My brain is just
> hard-wired to HEX and I find myself converting the verbose DEC values on top
> (which are very useful for the labels) into the HEX payload below to match
> things up. 100% HEX might be more natural for a lot of people.
> Between -lDEBUG and -t we were able to get everything we needed and there are
> higher priority things to cleanup, and I'm happy to have what is there today,
> but I'd say just dropping DEC altogether probably isn't going to cause any
> problems ... but perhaps other users will disagree???
> On 30/11/16 17:42, Christopher Collins wrote:
> I accidently wrapped the newtmgr output with short lines. Here is the
> unadalterated output:
> [ccollins@ccollins-mac:~/releases/1.0.0-b1/rc2]$ newtmgr -ldebug -c ttys010
> echo abc123
> 2016/11/30 08:25:57 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:10
> Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]}
> 2016/11/30 08:25:57 [DEBUG] Serializing request &{Op:2 Flags:0 Len:10 Group:0
> Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]} into buffer [2 0 0 10 0 0
> 0 0 161 97 100 102 97 98 99 49 50 51]
> 2016/11/30 08:25:57 [DEBUG] Tx packet dump:
> 02 00 00 0a 00 00 00 00 a1 61 64 66 61 62 63 31 |.adfabc1|
> 0010 32 33 |23|
> 2016/11/30 08:25:57 [DEBUG] Writing [6 9] to data channel
> 2016/11/30 08:25:57 [DEBUG] Writing [65 66 81 67 65 65 65 75 65 65 65 65 65
> 75 70 104 90 71 90 104 89 109 77 120 77 106 79 53 57 65 61 61] to data channel
> 2016/11/30 08:25:57 [DEBUG] Writing [10] to data channel
> ^C
> [ccollins@ccollins-mac:~/releases/1.0.0-b1/rc2]$ newtmgr -t -ldebug -c
> ttys010 echo abc123
> 2016/11/30 08:26:13 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:10
> Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]}
> 2016/11/30 08:26:13 [DEBUG] Serializing request &{Op:2 Flags:0 Len:10 Group:0
> Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]} into buffer [2 0 0 10 0 0
> 0 0 161 97 100 102 97 98 99 49 50 51]
> 2016/11/30 08:26:13 [DEBUG] Tx packet dump:
> 02 00 00 0a 00 00 00 00 a1 61 64 66 61 62 63 31 |.adfabc1|
> 0010 32 33 |23|
> 2016/11/30 08:26:13 [INFO] Outgoing:
> 06 09 |..|
> 2016/11/30 08:26:13 [DEBUG] Writing [6 9] to data channel
> 2016/11/30 08:26:13 [INFO] Outgoing:
> 41 42 51 43 41 41 41 4b 41 41 41 41 41 4b 46 68 |ABQCAAAKAKFh|
> 0010 5a 47 5a 68 59 6d 4d 78 4d 6a 4f 35 39 41 3d 3d |ZGZhYmMxMjO59A==|
> 2016/11/30 08:26:13 [DEBUG] Writing [65 66 81 67 65 65 65 75 65 65 65 65 65
> 75 70 104 90 71 90 104 89 109 77 120 77 106 79 53 57 65 61 61] to data channel
> 2016/11/30 08:26:13 [INFO] Outgoing:
> 0a|.|
> 2016/11/30 08:26:13 [DEBUG] Writing [10] to data channel
> ^C
> Thanks,
> Chris
> On Wed, Nov 30, 2016 at 08:40:39AM -0800, Christopher Collins wrote:
> Hi Kevin,
> On Wed, Nov 30, 2016 at 01:37:38PM +0100, Kevin Townsend wrote:
> We're currently working on a mobile version of newtmgr, and the DEBUG
> output is very useful to sanity check commands and responses, but the
> output in DEC is kind of a pain when most SW engineering on embedded
> devices is done in HEX. Is there an option I'm missing to output HEX
> instead of DEC, or is this something worth considering changing
> internally in the tool to default to HEX which feels like a far more
> natural choice from my PoV?
> The newtmgr debug output is pretty much a mess at the moment. That
> said, it does do a hex dump of incoming and outgoing packets when you
> specify the "-ldebug" flag. If you are only seeing decimal output, then
> is it possible you are using an old version of newtmgr?
> The reason I say the debug output is a mess is that it print
[jira] [Updated] (MYNEWT-495) newt sync needs a refactor
[ https://issues.apache.org/jira/browse/MYNEWT-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-495: --- Assignee: Fabio Utzig (was: Christopher Collins) > 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.4#6332)
[jira] [Updated] (MYNEWT-509) Linker script should limit image size to allow for trailer
[ https://issues.apache.org/jira/browse/MYNEWT-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-509: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > Linker script should limit image size to allow for trailer > -- > > Key: MYNEWT-509 > URL: https://issues.apache.org/jira/browse/MYNEWT-509 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_0_0_rel > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-495) newt sync needs a refactor
[ https://issues.apache.org/jira/browse/MYNEWT-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-495: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > 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: Christopher Collins > 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.4#6332)
[jira] [Commented] (MYNEWT-492) System configuration needs to have descriptions
[ https://issues.apache.org/jira/browse/MYNEWT-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838414#comment-15838414 ] Sterling Hughes commented on MYNEWT-492: assigned to rel, most of the newt changes are already in --- but we should make sure that all syscfg settings have configurations associated iwth them. > System configuration needs to have descriptions > --- > > Key: MYNEWT-492 > URL: https://issues.apache.org/jira/browse/MYNEWT-492 > Project: Mynewt > Issue Type: Improvement >Affects Versions: v1_0_0_beta1 >Reporter: Sterling Hughes >Assignee: Christopher Collins > Fix For: v1_0_0_rel > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-502) nrf52 ADC will not work if VDD4 reference is specified
[ https://issues.apache.org/jira/browse/MYNEWT-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-502: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_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 > Components: BSP >Affects Versions: v1_0_0_beta1 >Reporter: William San Filippo >Assignee: William San Filippo > Fix For: v1_0_0_rel > > > 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.4#6332)
[jira] [Updated] (MYNEWT-492) System configuration needs to have descriptions
[ https://issues.apache.org/jira/browse/MYNEWT-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-492: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > System configuration needs to have descriptions > --- > > Key: MYNEWT-492 > URL: https://issues.apache.org/jira/browse/MYNEWT-492 > Project: Mynewt > Issue Type: Improvement >Affects Versions: v1_0_0_beta1 >Reporter: Sterling Hughes >Assignee: Christopher Collins > Fix For: v1_0_0_rel > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15838413#comment-15838413 ] Sterling Hughes commented on MYNEWT-490: Have we fixed this yet? > 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 >Reporter: Sterling Hughes >Assignee: Marko Kiiskila > Fix For: v1_0_0_beta2 > > > 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.3.4#6332)
[jira] [Updated] (MYNEWT-481) boot loader with serial upload is too big
[ https://issues.apache.org/jira/browse/MYNEWT-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-481: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > boot loader with serial upload is too big > - > > Key: MYNEWT-481 > URL: https://issues.apache.org/jira/browse/MYNEWT-481 > Project: Mynewt > Issue Type: Bug >Reporter: Marko Kiiskila > Fix For: v1_0_0_rel > > > [marko@IsMyLaptop:~/src2/incubator-mynewt-blinky]$ newt size boot_mkr1000 | > tail -3 > objsize >text data bss dec hex filename > 11040765332 164484040 > /Users/marko/src2/incubator-mynewt-blinky/bin/targets/boot_mkr1000/app/apps/boot/boot.elf > [marko@IsMyLaptop:~/src2/incubator-mynewt-blinky]$ newt size > boot_mkr1000_serial | tail -3 > objsize >text data bss dec hex filename > 28556 1009924 3858096b4 > /Users/marko/src2/incubator-mynewt-blinky/bin/targets/boot_mkr1000_serial/app/apps/boot/boot.elf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYNEWT-465) STATS_NEWTMGR breaks compile
[ https://issues.apache.org/jira/browse/MYNEWT-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes resolved MYNEWT-465. Resolution: Fixed > STATS_NEWTMGR breaks compile > > > Key: MYNEWT-465 > URL: https://issues.apache.org/jira/browse/MYNEWT-465 > Project: Mynewt > Issue Type: Bug > Components: Newtmgr >Affects Versions: v1_0_0_beta1 > Environment: Mac OS X >Reporter: David G. Simmons >Assignee: Marko Kiiskila > Fix For: v1_0_0_beta2 > > > Adding STATS_NEWTMG: 1 > To syscfg.yml causes the following compile error: > Compiling mgmt.c > Error: mgmt.c:22:27: fatal error: tinycbor/cbor.h: No such file or directory > #include >^ > compilation terminated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-473) arduino primo console should go via hal uart, and ESP uart use bitbanger
[ https://issues.apache.org/jira/browse/MYNEWT-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-473: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > arduino primo console should go via hal uart, and ESP uart use bitbanger > > > Key: MYNEWT-473 > URL: https://issues.apache.org/jira/browse/MYNEWT-473 > Project: Mynewt > Issue Type: Bug >Reporter: Marko Kiiskila > Fix For: v1_0_0_rel > > > ESP8266 uart port is by default configured to be 9600 bps, so it does not > have to be high speed one. Bitbanger will suffice. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-400) Improve newt compatibility with 3rd party systems
[ https://issues.apache.org/jira/browse/MYNEWT-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-400: --- Fix Version/s: (was: v1_0_0_beta2) v1_1_beta1 > Improve newt compatibility with 3rd party systems > - > > Key: MYNEWT-400 > URL: https://issues.apache.org/jira/browse/MYNEWT-400 > Project: Mynewt > Issue Type: Improvement > Components: Newt >Reporter: Sterling Hughes >Assignee: Sterling Hughes > Fix For: v1_1_beta1 > > > Newt should be able to generate a Makefile, with the targets from newt target > show, so that a newt source code base can easily be brought in. > This includes a few features: > - Every newt target should generate a .a file which is the superset of all > built .a files, that way newt can be linked as a library into another > application. > - All the include directories should (optionally) be placed into the bin/ > directory, along with their full directory path. > - this MUST be optional, as for users of newt this creates unnecessary > header file duplication, but it is very useful for people who wish to include > newt in third party systems > - Newt should have an option to generate a Makefile, with the targets in newt > target show, that allows people to build a newt project without the newt > tool, and just requires Make. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-420) Implement OS stack checking, and memory debug
[ https://issues.apache.org/jira/browse/MYNEWT-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-420: --- Fix Version/s: (was: v1_0_0_beta2) v1_1_beta1 > Implement OS stack checking, and memory debug > - > > Key: MYNEWT-420 > URL: https://issues.apache.org/jira/browse/MYNEWT-420 > Project: Mynewt > Issue Type: Improvement >Affects Versions: v1_0_0_beta1 >Reporter: Sterling Hughes >Assignee: Sterling Hughes > Fix For: v1_1_beta1 > > > OS needs stack size checking / stack guards. Memory pools need alloc/free > tracking, and assert on double free. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-359) Make hal cputime more efficient when 32.768 kHz crystal is used.
[ https://issues.apache.org/jira/browse/MYNEWT-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-359: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > Make hal cputime more efficient when 32.768 kHz crystal is used. > > > Key: MYNEWT-359 > URL: https://issues.apache.org/jira/browse/MYNEWT-359 > Project: Mynewt > Issue Type: Improvement > Components: Nimble >Reporter: William San Filippo >Assignee: William San Filippo > Fix For: v1_0_0_rel > > > Just like the code to make cputime more efficient for a 1MHZ cputime, we also > need to modify the code when cputime is using a 32.768 kHz crystal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-394) Improve error handling in newt tool
[ https://issues.apache.org/jira/browse/MYNEWT-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-394: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > Improve error handling in newt tool > --- > > Key: MYNEWT-394 > URL: https://issues.apache.org/jira/browse/MYNEWT-394 > Project: Mynewt > Issue Type: Improvement > Components: Newt >Reporter: Sterling Hughes >Assignee: Fabio Utzig > Fix For: v1_0_0_rel > > > When newt encounters errors, its messages are not always the most helpful. > e.g. if you have two packages with the same name, it silently ignores all of > them. > e.g. interface panic happens when you can't fetch a repository.yml file. > somebody should spend a couple of hours breaking repositories, and making > sure that newt provides helpful error messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-451) `newt create-image` does not recognise PEM unless private key is listed first
[
https://issues.apache.org/jira/browse/MYNEWT-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-451:
---
Fix Version/s: (was: v1_0_0_beta2)
v1_0_0_rel
> `newt create-image` does not recognise PEM unless private key is listed first
> -
>
> Key: MYNEWT-451
> URL: https://issues.apache.org/jira/browse/MYNEWT-451
> Project: Mynewt
> Issue Type: Bug
> Components: Newt
>Affects Versions: v1_0_0_beta1
>Reporter: Simon Ratner
>Assignee: Marko Kiiskila
> Fix For: v1_0_0_rel
>
>
> Here is an example of a PEM file not recognised by `newt create-image`:
> {noformat}
> ASN1 OID: secp224r1
> NIST CURVE: P-224
> -BEGIN EC PARAMETERS-
> BgUrgQQAIQ==
> -END EC PARAMETERS-
> -BEGIN EC PRIVATE KEY-
> MGgCAQEEHC+OSuFL+Y4G1vbb2Tuj3cAmmj99EJjxWVNQlc2gBwYFK4EEACGhPAM6
> AATnm3vSTozIAcjQVNKRzJ7RKk+S2qF6cuHfxaCf0jp8IaJlO2bY6cd/ArSKF8kQ
> Jl2kETQMT0B1OA==
> -END EC PRIVATE KEY-
> {noformat}
> This is the direct output of:
> {noformat}
> openssl ecparam -genkey -name secp224r1 -text -out test.pem
> {noformat}
> Removing the text section (but keeping params) is not sufficient.
> Re-arranging the sections such that the private key section appears first in
> the file makes `newt` recognise it correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYNEWT-343) nffs crash at bootloader
[
https://issues.apache.org/jira/browse/MYNEWT-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-343:
---
Fix Version/s: (was: v1_0_0_beta2)
v1_0_0_rel
> nffs crash at bootloader
>
>
> Key: MYNEWT-343
> URL: https://issues.apache.org/jira/browse/MYNEWT-343
> Project: Mynewt
> Issue Type: Bug
> Components: NFFS
> Environment: Arduino Zero with NFFS
>Reporter: Marko Kiiskila
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
> Attachments: arduino_nffs.bin, nffs-inode-invalid-id.bin
>
>
> System asserts. I was switching between images.
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __assert_func (file=, line=,
> func=, e=) at os_fault.c:124
> 124 asm("bkpt");
> (gdb) bt
> #0 __assert_func (file=, line=,
> func=, e=) at os_fault.c:124
> #1 0x105e in nffs_hash_remove (entry=entry@entry=0x20001ad8)
> at nffs_hash.c:179
> #2 0x2ff2 in nffs_block_delete_from_ram (
> block_entry=block_entry@entry=0x20001ad8) at nffs_block.c:266
> #3 0x26f2 in nffs_restore_sweep () at nffs_restore.c:353
> #4 0x283e in nffs_restore_full (area_descs=area_descs@entry=0x2000736c)
> at nffs_restore.c:1400
> #5 0x04ca in nffs_detect (area_descs=area_descs@entry=0x2000736c)
> at nffs.c:606
> #6 0x01e8 in setup_for_nffs () at boot.c:93
> #7 main () at boot.c:173
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYNEWT-293) Newt should make it easier to make custom packages
[ https://issues.apache.org/jira/browse/MYNEWT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-293: --- Assignee: Fabio Utzig (was: Sterling Hughes) > Newt should make it easier to make custom packages > -- > > Key: MYNEWT-293 > URL: https://issues.apache.org/jira/browse/MYNEWT-293 > Project: Mynewt > Issue Type: Improvement > Components: Newt >Affects Versions: v1_0_0_beta1 >Reporter: Sterling Hughes >Assignee: Fabio Utzig > Fix For: v1_0_0_rel > > > There are a few issues with current newt package creation: > - It's opaque as to how to create a local package in a project. > - Need to add two options: > - newt pkg new : create a new package in the current directory, > with a basic template > - newt pkg clone : Clone an existing package > into the currnet directory. > - Currently, there must be an exact match on repository descriptor, or the > newt tool will barf. This should be smarter -- > - If it can't resolve a dependency in the local project, it should look at > the current project/workspace, and try to resolve the package > - It should issue a warning if it can't find the package. > - Currently pkg.name and the name of the package directory can not match, and > the pkg.name will be taken over the pkg directory. There should be a warning > issued if the package directory does not match the package name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-338) NFFS - Can't delete from a completely full file system
[ https://issues.apache.org/jira/browse/MYNEWT-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-338: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > NFFS - Can't delete from a completely full file system > -- > > Key: MYNEWT-338 > URL: https://issues.apache.org/jira/browse/MYNEWT-338 > Project: Mynewt > Issue Type: Bug > Components: NFFS >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_0_0_rel > > > Deleting a file or directory requires writing an inode to the disk. If the > disk is completely full, there is not room for the deletion record, and the > delete attempt will fail with an FS_EFULL error. > It should be sufficient to always ensure that at least one area has room for > a deletion record. All deletion records are the same size. Once a deletion > record is written, the previous inode entry and all children inodes or > constituent data blocks can be removed during garbage collection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-335) use of fcb_offset_last_n() is limited
[ https://issues.apache.org/jira/browse/MYNEWT-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-335: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > use of fcb_offset_last_n() is limited > - > > Key: MYNEWT-335 > URL: https://issues.apache.org/jira/browse/MYNEWT-335 > Project: Mynewt > Issue Type: Improvement >Reporter: Marko Kiiskila >Assignee: Fabio Utzig > Fix For: v1_0_0_rel > > > The routine does not return the flash sector where the element is, therefore > this is difficult to use in generic case. It really should fill in an full > 'struct fcb_entry'. > Currently the routine is only usable if there is only one sector within FCB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-301) nffs corrupt
[ https://issues.apache.org/jira/browse/MYNEWT-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-301: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > nffs corrupt > > > Key: MYNEWT-301 > URL: https://issues.apache.org/jira/browse/MYNEWT-301 > Project: Mynewt > Issue Type: Bug > Components: NFFS >Affects Versions: v1_0_0_beta2 >Reporter: Marko Kiiskila >Assignee: Christopher Collins > Fix For: v1_0_0_rel > > Attachments: bad_arduino_nffs.bin, bad_arduino_nffs.bin2 > > > happened on arduino, bootloader does not come up as NFFS is asserting. > (gdb) bt > #0 __assert_func (file=0x742a "nffs_restore.c", line=229, func=0x0 > <_sfixed>, > e=0x0 <_sfixed>) at os_fault.c:113 > #1 0x22ac in nffs_restore_find_file_ends () at nffs_restore.c:285 > #2 nffs_restore_full (area_descs=area_descs@entry=0x2000736c) > at nffs_restore.c:1160 > #3 0x04ca in nffs_detect (area_descs=area_descs@entry=0x2000736c) > at nffs.c:605 > #4 0x01e8 in setup_for_nffs () at boot.c:80 > #5 main () at boot.c:160 > (gdb) up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYNEWT-318) Add FAT support
[ https://issues.apache.org/jira/browse/MYNEWT-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes resolved MYNEWT-318. Resolution: Fixed > Add FAT support > --- > > Key: MYNEWT-318 > URL: https://issues.apache.org/jira/browse/MYNEWT-318 > Project: Mynewt > Issue Type: New Feature > Components: Filesystem >Reporter: Sterling Hughes >Assignee: Fabio Utzig > Fix For: v1_0_0_beta2 > > > Add support for FAT filesystem to read external SD cards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-286) nRF51 crashes when receiving large(ish) ACL packet
[ https://issues.apache.org/jira/browse/MYNEWT-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-286: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > nRF51 crashes when receiving large(ish) ACL packet > -- > > Key: MYNEWT-286 > URL: https://issues.apache.org/jira/browse/MYNEWT-286 > Project: Mynewt > Issue Type: Bug > Components: Nimble > Environment: nRF51 USB dongle or devkit >Reporter: Johan Hedberg >Assignee: William San Filippo > Fix For: v1_0_0_rel > > > The default L2CAP MTUs of ATT and legacy SMP fixed channels is 23. This works > fine. As soon as LE Secure Connections SMP is attempted (MTU of 65) and the > public key sent the controller stops responding (gdb doesn't work. needs a > hard power cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-285) NRF52 decryption failures (intermittent)
[ https://issues.apache.org/jira/browse/MYNEWT-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-285: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > NRF52 decryption failures (intermittent) > > > Key: MYNEWT-285 > URL: https://issues.apache.org/jira/browse/MYNEWT-285 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Affects Versions: v1_0_0_beta2 >Reporter: William San Filippo >Assignee: William San Filippo > Fix For: v1_0_0_rel > > > The current ble phy driver for the nrf52 counts occasional errors when > decrypting received frames. What we see is that the CCM peripheral does not > set the ENDCRYPT event, indicating that decryption never finished (or even > started although we do see the ENDKSGEN event which signifies we generated > the key stream). When this occurs there is no other indication; the CRC check > passes and it passes the MIC. Note that we only see this occurring for LL > empty PDU's. These packets have zero length and are supposed to pass through > the CCM engine as empty pdu's are not encrypted. > A note on this bug: this only occurs when the device is the slave, not the > master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-293) Newt should make it easier to make custom packages
[ https://issues.apache.org/jira/browse/MYNEWT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-293: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > Newt should make it easier to make custom packages > -- > > Key: MYNEWT-293 > URL: https://issues.apache.org/jira/browse/MYNEWT-293 > Project: Mynewt > Issue Type: Improvement > Components: Newt >Affects Versions: v1_0_0_beta1 >Reporter: Sterling Hughes >Assignee: Sterling Hughes > Fix For: v1_0_0_rel > > > There are a few issues with current newt package creation: > - It's opaque as to how to create a local package in a project. > - Need to add two options: > - newt pkg new : create a new package in the current directory, > with a basic template > - newt pkg clone : Clone an existing package > into the currnet directory. > - Currently, there must be an exact match on repository descriptor, or the > newt tool will barf. This should be smarter -- > - If it can't resolve a dependency in the local project, it should look at > the current project/workspace, and try to resolve the package > - It should issue a warning if it can't find the package. > - Currently pkg.name and the name of the package directory can not match, and > the pkg.name will be taken over the pkg directory. There should be a warning > issued if the package directory does not match the package name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-287) Host Flow Control
[ https://issues.apache.org/jira/browse/MYNEWT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-287: --- Fix Version/s: (was: v1_0_0_beta2) v1_1_beta1 > Host Flow Control > - > > Key: MYNEWT-287 > URL: https://issues.apache.org/jira/browse/MYNEWT-287 > Project: Mynewt > Issue Type: New Feature > Components: Nimble > Environment: Using nimble from an external host stack >Reporter: Johan Hedberg >Assignee: Christopher Collins > Fix For: v1_1_beta1 > > > If the Nimble controller part is connected to an external host stack the host > may need to control the flow of ACL packets from the controller to the host. > This is particularly important for resource-constrained hosts that have a > limited amount of RX ACL data buffers. > The Bluetooth core specification provides a standard feature to accomplish > this called Host Flow Control. (Vol 2, Part E, Section 4.2). To implement > this the controller needs to support the "Set Controller To Host Flow > Control", "Host Buffer Size" and "Host Number Of Completed Packets" HCI > commands. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-292) Don't allow two tasks to have the same priority
[ https://issues.apache.org/jira/browse/MYNEWT-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-292: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > Don't allow two tasks to have the same priority > --- > > Key: MYNEWT-292 > URL: https://issues.apache.org/jira/browse/MYNEWT-292 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Fabio Utzig > Fix For: v1_0_0_rel > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-247) Document how to create a package
[ https://issues.apache.org/jira/browse/MYNEWT-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-247: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > Document how to create a package > > > Key: MYNEWT-247 > URL: https://issues.apache.org/jira/browse/MYNEWT-247 > Project: Mynewt > Issue Type: Improvement >Reporter: Paul Dietrich >Assignee: Christopher Collins > Fix For: v1_0_0_rel > > > Write a markdown doc on how to create a package in mynewt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-244) JSON decoder should complain when getting a NULL string
[
https://issues.apache.org/jira/browse/MYNEWT-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-244:
---
Fix Version/s: (was: v1_0_0_beta2)
v1_0_0_rel
> JSON decoder should complain when getting a NULL string
> ---
>
> Key: MYNEWT-244
> URL: https://issues.apache.org/jira/browse/MYNEWT-244
> Project: Mynewt
> Issue Type: Improvement
>Reporter: Paul Dietrich
>Assignee: Fabio Utzig
> Fix For: v1_0_0_rel
>
>
> Seems like the json decoder returns 0 when it gets a null string (empty
> element). Seems like it should do something. I know that its possible that
> all elements could have defaults, but that seems like a pretty meaningless
> message to send. Not sure if this is a bug, but consider what to do.
> NOTE: there was not even a {}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYNEWT-42) Need to run coverity scan on project source
[ https://issues.apache.org/jira/browse/MYNEWT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-42: -- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > 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.4#6332)
[jira] [Updated] (MYNEWT-139) Need a CI and build service for Mynewt
[ https://issues.apache.org/jira/browse/MYNEWT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-139: --- Fix Version/s: (was: v1_0_0_beta2) v1_0_0_rel > Need a CI and build service for Mynewt > -- > > Key: MYNEWT-139 > URL: https://issues.apache.org/jira/browse/MYNEWT-139 > Project: Mynewt > Issue Type: Improvement > Components: Newt, OS >Reporter: Sterling Hughes >Assignee: Peter Snyder > Fix For: v1_0_0_rel > > > We need a build service that compiles mynewt for common targets and runs > regression tests, on a: > - Every commit > - Nightly > Basis. The Nightly commits should generate tarballs that people can download > and play with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYNEWT-531) Add support for Segger RTT console
[ https://issues.apache.org/jira/browse/MYNEWT-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824742#comment-15824742 ] Sterling Hughes commented on MYNEWT-531: chris, can you look at this? > Add support for Segger RTT console > -- > > Key: MYNEWT-531 > URL: https://issues.apache.org/jira/browse/MYNEWT-531 > Project: Mynewt > Issue Type: New Feature > Components: OS >Affects Versions: WISHLIST > Environment: Mac OSX ,Linux >Reporter: Marcio Montenegro >Assignee: Christopher Collins >Priority: Minor > Fix For: WISHLIST > > > Sometimes UART console is not available and you can use j-link console. > https://www.segger.com/j-link-rtt.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-531) Add support for Segger RTT console
[ https://issues.apache.org/jira/browse/MYNEWT-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-531: --- Assignee: Christopher Collins > Add support for Segger RTT console > -- > > Key: MYNEWT-531 > URL: https://issues.apache.org/jira/browse/MYNEWT-531 > Project: Mynewt > Issue Type: New Feature > Components: OS >Affects Versions: WISHLIST > Environment: Mac OSX ,Linux >Reporter: Marcio Montenegro >Assignee: Christopher Collins >Priority: Minor > Fix For: WISHLIST > > > Sometimes UART console is not available and you can use j-link console. > https://www.segger.com/j-link-rtt.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYNEWT-525) Need a PWM driver
Sterling Hughes created MYNEWT-525: -- Summary: Need a PWM driver Key: MYNEWT-525 URL: https://issues.apache.org/jira/browse/MYNEWT-525 Project: Mynewt Issue Type: Wish Components: drivers Reporter: Sterling Hughes Desirable to have a PWM driver, as this is a very common function. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYNEWT-522) Callout API should be improved to add a "call back at" timer function.
Sterling Hughes created MYNEWT-522: -- Summary: 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 Components: OS Affects Versions: v1_0_0_rel Reporter: Sterling Hughes Fix For: v1_0_0_rel 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.4#6332)
[jira] [Created] (MYNEWT-497) Cleanup newtmgr debug output
Sterling Hughes created MYNEWT-497:
--
Summary: Cleanup newtmgr debug output
Key: MYNEWT-497
URL: https://issues.apache.org/jira/browse/MYNEWT-497
Project: Mynewt
Issue Type: Improvement
Affects Versions: v1_0_0_rel
Reporter: Sterling Hughes
Fix For: v1_0_0_rel
Hi Christopher,
The latest version has improved debug output with the combined HEX and DEC
which I don't remember in earlier versions, so thanks for that. We've been
using the -t trace option but it's good to point out to anyone who stumbles
across this thread anyway.
I don't find the DEC very useful in the [DEBUG] output lines within 'Data:'
which is what I was referring to in the original email, but the TX packet dump
is a nice approach where you list both HEX and ASCII. My brain is just
hard-wired to HEX and I find myself converting the verbose DEC values on top
(which are very useful for the labels) into the HEX payload below to match
things up. 100% HEX might be more natural for a lot of people.
Between -lDEBUG and -t we were able to get everything we needed and there are
higher priority things to cleanup, and I'm happy to have what is there today,
but I'd say just dropping DEC altogether probably isn't going to cause any
problems ... but perhaps other users will disagree???
On 30/11/16 17:42, Christopher Collins wrote:
I accidently wrapped the newtmgr output with short lines. Here is the
unadalterated output:
[ccollins@ccollins-mac:~/releases/1.0.0-b1/rc2]$ newtmgr -ldebug -c ttys010
echo abc123
2016/11/30 08:25:57 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:10
Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]}
2016/11/30 08:25:57 [DEBUG] Serializing request &{Op:2 Flags:0 Len:10 Group:0
Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]} into buffer [2 0 0 10 0 0 0
0 161 97 100 102 97 98 99 49 50 51]
2016/11/30 08:25:57 [DEBUG] Tx packet dump:
02 00 00 0a 00 00 00 00 a1 61 64 66 61 62 63 31 |.adfabc1|
0010 32 33 |23|
2016/11/30 08:25:57 [DEBUG] Writing [6 9] to data channel
2016/11/30 08:25:57 [DEBUG] Writing [65 66 81 67 65 65 65 75 65 65 65 65 65 75
70 104 90 71 90 104 89 109 77 120 77 106 79 53 57 65 61 61] to data channel
2016/11/30 08:25:57 [DEBUG] Writing [10] to data channel
^C
[ccollins@ccollins-mac:~/releases/1.0.0-b1/rc2]$ newtmgr -t -ldebug -c ttys010
echo abc123
2016/11/30 08:26:13 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:10
Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]}
2016/11/30 08:26:13 [DEBUG] Serializing request &{Op:2 Flags:0 Len:10 Group:0
Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]} into buffer [2 0 0 10 0 0 0
0 161 97 100 102 97 98 99 49 50 51]
2016/11/30 08:26:13 [DEBUG] Tx packet dump:
02 00 00 0a 00 00 00 00 a1 61 64 66 61 62 63 31 |.adfabc1|
0010 32 33 |23|
2016/11/30 08:26:13 [INFO] Outgoing:
06 09 |..|
2016/11/30 08:26:13 [DEBUG] Writing [6 9] to data channel
2016/11/30 08:26:13 [INFO] Outgoing:
41 42 51 43 41 41 41 4b 41 41 41 41 41 4b 46 68 |ABQCAAAKAKFh|
0010 5a 47 5a 68 59 6d 4d 78 4d 6a 4f 35 39 41 3d 3d |ZGZhYmMxMjO59A==|
2016/11/30 08:26:13 [DEBUG] Writing [65 66 81 67 65 65 65 75 65 65 65 65 65 75
70 104 90 71 90 104 89 109 77 120 77 106 79 53 57 65 61 61] to data channel
2016/11/30 08:26:13 [INFO] Outgoing:
0a|.|
2016/11/30 08:26:13 [DEBUG] Writing [10] to data channel
^C
Thanks,
Chris
On Wed, Nov 30, 2016 at 08:40:39AM -0800, Christopher Collins wrote:
Hi Kevin,
On Wed, Nov 30, 2016 at 01:37:38PM +0100, Kevin Townsend wrote:
We're currently working on a mobile version of newtmgr, and the DEBUG
output is very useful to sanity check commands and responses, but the
output in DEC is kind of a pain when most SW engineering on embedded
devices is done in HEX. Is there an option I'm missing to output HEX
instead of DEC, or is this something worth considering changing
internally in the tool to default to HEX which feels like a far more
natural choice from my PoV?
The newtmgr debug output is pretty much a mess at the moment. That
said, it does do a hex dump of incoming and outgoing packets when you
specify the "-ldebug" flag. If you are only seeing decimal output, then
is it possible you are using an old version of newtmgr?
The reason I say the debug output is a mess is that it prints both a
decimal and a hex dump. For example:
[ccollins@ccollins-mac:~/releases/1.0.0-b1/rc2]$ newtmgr -ldebug -c
ttys010 echo abc123
2016/11/30 08:25:57 [DEBUG] Writing newtmgr request &{Op:2 Flags:0
Len:10 Group:0 Seq:0 Id:0 Data:[161 97 100 102 97 98 99 49 50 51]}
2016/11/30 08:25:57 [DEBUG] Serializing request &{Op:2 F
[jira] [Created] (MYNEWT-495) newt sync needs a refactor
Sterling Hughes created MYNEWT-495: -- Summary: 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: Christopher Collins 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.4#6332)
[jira] [Created] (MYNEWT-494) Shell should assert() when a duplicate name/entry is registered.
Sterling Hughes created MYNEWT-494: -- Summary: Shell should assert() when a duplicate name/entry is registered. Key: MYNEWT-494 URL: https://issues.apache.org/jira/browse/MYNEWT-494 Project: Mynewt Issue Type: Improvement Affects Versions: v1_0_0_beta1 Reporter: Sterling Hughes Assignee: Christopher Collins Fix For: v1_0_0_rel Right now it just inserts it into the list, which can create a circular list search, when, for example calling shell help. It also just calls the first handler it finds when you issue the command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYNEWT-493) Should have the ability to generate and edit system configuration files at the target level
Sterling Hughes created MYNEWT-493: -- Summary: Should have the ability to generate and edit system configuration files at the target level Key: MYNEWT-493 URL: https://issues.apache.org/jira/browse/MYNEWT-493 Project: Mynewt Issue Type: Improvement Affects Versions: v1_0_0_beta1 Reporter: Sterling Hughes Assignee: Christopher Collins Fix For: v1_0_0_rel It would be helpful to have the ability to generate a system configuration file at the target level that contains the values of all the system configuration variables set (or overridden) by the various packages. It would also be good to have a function to edit target sys configuration (newt target edit ). That way you have a view of system configuration and the values all in a single file, that dictates the final value of all of these settings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYNEWT-492) System configuration needs to have descriptions
[ https://issues.apache.org/jira/browse/MYNEWT-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15688971#comment-15688971 ] Sterling Hughes commented on MYNEWT-492: hit enter too soon. we need to make sure to describe all defined system configurations. Additionally, dependencies between system configurations and warnings/errors should be generated, so when a system configuration is set, but, for example, it requires another setting to go into effect, newt can warn about these inconsistencies. > System configuration needs to have descriptions > --- > > Key: MYNEWT-492 > URL: https://issues.apache.org/jira/browse/MYNEWT-492 > Project: Mynewt > Issue Type: Improvement >Affects Versions: v1_0_0_beta1 >Reporter: Sterling Hughes > Fix For: v1_0_0_rel > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-492) System configuration needs to have descriptions
[ https://issues.apache.org/jira/browse/MYNEWT-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-492: --- Assignee: Christopher Collins > System configuration needs to have descriptions > --- > > Key: MYNEWT-492 > URL: https://issues.apache.org/jira/browse/MYNEWT-492 > Project: Mynewt > Issue Type: Improvement >Affects Versions: v1_0_0_beta1 >Reporter: Sterling Hughes >Assignee: Christopher Collins > Fix For: v1_0_0_rel > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYNEWT-492) System configuration needs to have descriptions
Sterling Hughes created MYNEWT-492: -- Summary: System configuration needs to have descriptions Key: MYNEWT-492 URL: https://issues.apache.org/jira/browse/MYNEWT-492 Project: Mynewt Issue Type: Improvement Affects Versions: v1_0_0_beta1 Reporter: Sterling Hughes Fix For: v1_0_0_rel -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYNEWT-491) Double calling init functions should be disallowed
Sterling Hughes created MYNEWT-491: -- Summary: Double calling init functions should be disallowed Key: MYNEWT-491 URL: https://issues.apache.org/jira/browse/MYNEWT-491 Project: Mynewt Issue Type: Improvement Components: Sysinit Affects Versions: v1_0_0_beta1 Reporter: Sterling Hughes Assignee: Christopher Collins Fix For: v1_0_0_rel When "init" functions are specified to sysinit, that should be the only place they are called. They should not be directly called, or bad things happen. There should be a macro SYSINIT_ASSERT_CALLED_ONCE() (name it better), at the beginning of these init functions, that asserts on double init. It can be hard to debug when this function is called twice, and I think it will be very common for users to not notice the init function exported by the package, and instead call it directly, so we should find helpful ways to inform them (at least when build_profile=debug). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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 ] Sterling Hughes updated MYNEWT-490: --- Fix Version/s: v1_0_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 >Reporter: Sterling Hughes > Fix For: v1_0_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.3.4#6332)
[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 ] Sterling Hughes updated MYNEWT-490: --- Assignee: Marko Kiiskila > 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 >Reporter: Sterling Hughes >Assignee: Marko Kiiskila > Fix For: v1_0_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.3.4#6332)
[jira] [Created] (MYNEWT-490) Move os_time_get() and parts of os_time_tick() into the HAL, rename os_tick HAL
Sterling Hughes created MYNEWT-490: -- Summary: 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 Reporter: Sterling Hughes 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.3.4#6332)
[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 ] Sterling Hughes updated MYNEWT-395: --- Fix Version/s: (was: WISHLIST) v1_1_beta1 > 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 > Components: Newt >Affects Versions: WISHLIST > Environment: all >Reporter: Wayne Keenan >Assignee: Sterling Hughes >Priority: Minor > Fix For: v1_1_beta1 > > > 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.3.4#6332)
[jira] [Updated] (MYNEWT-451) `newt create-image` does not recognise PEM unless private key is listed first
[
https://issues.apache.org/jira/browse/MYNEWT-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-451:
---
Fix Version/s: v1_0_0_rel
> `newt create-image` does not recognise PEM unless private key is listed first
> -
>
> Key: MYNEWT-451
> URL: https://issues.apache.org/jira/browse/MYNEWT-451
> Project: Mynewt
> Issue Type: Bug
> Components: Newt
>Affects Versions: v1_0_0_beta1
>Reporter: Simon Ratner
>Assignee: Sterling Hughes
> Fix For: v1_0_0_rel
>
>
> Here is an example of a PEM file not recognised by `newt create-image`:
> {noformat}
> ASN1 OID: secp224r1
> NIST CURVE: P-224
> -BEGIN EC PARAMETERS-
> BgUrgQQAIQ==
> -END EC PARAMETERS-
> -BEGIN EC PRIVATE KEY-
> MGgCAQEEHC+OSuFL+Y4G1vbb2Tuj3cAmmj99EJjxWVNQlc2gBwYFK4EEACGhPAM6
> AATnm3vSTozIAcjQVNKRzJ7RKk+S2qF6cuHfxaCf0jp8IaJlO2bY6cd/ArSKF8kQ
> Jl2kETQMT0B1OA==
> -END EC PRIVATE KEY-
> {noformat}
> This is the direct output of:
> {noformat}
> openssl ecparam -genkey -name secp224r1 -text -out test.pem
> {noformat}
> Removing the text section (but keeping params) is not sufficient.
> Re-arranging the sections such that the private key section appears first in
> the file makes `newt` recognise it correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYNEWT-396) Make the stats a 'feature' that can be compiled out
[ https://issues.apache.org/jira/browse/MYNEWT-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-396: --- Assignee: Marko Kiiskila (was: Sterling Hughes) > Make the stats a 'feature' that can be compiled out > --- > > Key: MYNEWT-396 > URL: https://issues.apache.org/jira/browse/MYNEWT-396 > Project: Mynewt > Issue Type: Wish > Components: Misc >Reporter: Wayne Keenan >Assignee: Marko Kiiskila >Priority: Critical > Fix For: v1_0_0_rel > > > Please allow all stats across all modules to be completely disabled and > compiled out, if required. > Very constrained devices, such as the 16k nrf51 as used in the BBC micro:bit > need the stats compiled out for running MicroPython. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-396) Make the stats a 'feature' that can be compiled out
[ https://issues.apache.org/jira/browse/MYNEWT-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-396: --- Fix Version/s: (was: WISHLIST) v1_0_0_rel > Make the stats a 'feature' that can be compiled out > --- > > Key: MYNEWT-396 > URL: https://issues.apache.org/jira/browse/MYNEWT-396 > Project: Mynewt > Issue Type: Wish > Components: Misc >Reporter: Wayne Keenan >Assignee: Sterling Hughes >Priority: Critical > Fix For: v1_0_0_rel > > > Please allow all stats across all modules to be completely disabled and > compiled out, if required. > Very constrained devices, such as the 16k nrf51 as used in the BBC micro:bit > need the stats compiled out for running MicroPython. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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 ] Sterling Hughes updated MYNEWT-395: --- Assignee: Marko Kiiskila (was: Sterling Hughes) > 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 > Components: Newt >Affects Versions: WISHLIST > Environment: all >Reporter: Wayne Keenan >Assignee: Marko Kiiskila >Priority: Minor > Fix For: v1_1_beta1 > > > 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.3.4#6332)
[jira] [Updated] (MYNEWT-451) `newt create-image` does not recognise PEM unless private key is listed first
[
https://issues.apache.org/jira/browse/MYNEWT-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-451:
---
Assignee: Marko Kiiskila (was: Sterling Hughes)
> `newt create-image` does not recognise PEM unless private key is listed first
> -
>
> Key: MYNEWT-451
> URL: https://issues.apache.org/jira/browse/MYNEWT-451
> Project: Mynewt
> Issue Type: Bug
> Components: Newt
>Affects Versions: v1_0_0_beta1
>Reporter: Simon Ratner
>Assignee: Marko Kiiskila
> Fix For: v1_0_0_rel
>
>
> Here is an example of a PEM file not recognised by `newt create-image`:
> {noformat}
> ASN1 OID: secp224r1
> NIST CURVE: P-224
> -BEGIN EC PARAMETERS-
> BgUrgQQAIQ==
> -END EC PARAMETERS-
> -BEGIN EC PRIVATE KEY-
> MGgCAQEEHC+OSuFL+Y4G1vbb2Tuj3cAmmj99EJjxWVNQlc2gBwYFK4EEACGhPAM6
> AATnm3vSTozIAcjQVNKRzJ7RKk+S2qF6cuHfxaCf0jp8IaJlO2bY6cd/ArSKF8kQ
> Jl2kETQMT0B1OA==
> -END EC PRIVATE KEY-
> {noformat}
> This is the direct output of:
> {noformat}
> openssl ecparam -genkey -name secp224r1 -text -out test.pem
> {noformat}
> Removing the text section (but keeping params) is not sufficient.
> Re-arranging the sections such that the private key section appears first in
> the file makes `newt` recognise it correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYNEWT-465) STATS_NEWTMGR breaks compile
[ https://issues.apache.org/jira/browse/MYNEWT-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-465: --- Assignee: Marko Kiiskila (was: Sterling Hughes) > STATS_NEWTMGR breaks compile > > > Key: MYNEWT-465 > URL: https://issues.apache.org/jira/browse/MYNEWT-465 > Project: Mynewt > Issue Type: Bug > Components: Newtmgr >Affects Versions: v1_0_0_beta1 > Environment: Mac OS X >Reporter: David G. Simmons >Assignee: Marko Kiiskila > Fix For: v1_0_0_rel > > > Adding STATS_NEWTMG: 1 > To syscfg.yml causes the following compile error: > Compiling mgmt.c > Error: mgmt.c:22:27: fatal error: tinycbor/cbor.h: No such file or directory > #include >^ > compilation terminated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYNEWT-384) Implement MQTT client protocol
[ https://issues.apache.org/jira/browse/MYNEWT-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sterling Hughes updated MYNEWT-384: --- Fix Version/s: v1_1_beta1 > Implement MQTT client protocol > -- > > Key: MYNEWT-384 > URL: https://issues.apache.org/jira/browse/MYNEWT-384 > Project: Mynewt > Issue Type: Wish > Components: Misc >Reporter: Iosif Gut >Assignee: Sterling Hughes >Priority: Minor > Labels: features > Fix For: v1_1_beta1 > > > 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.3.4#6332)
[jira] [Updated] (MYNEWT-477) newt - Split image requires split startup .s file to be in BSP package
[
https://issues.apache.org/jira/browse/MYNEWT-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sterling Hughes updated MYNEWT-477:
---
Fix Version/s: v1_1_beta1
> 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
> Components: Newt
>Reporter: Christopher Collins
>Assignee: Sterling Hughes
> Fix For: v1_1_beta1
>
>
> 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.4#6332)
