[jira] [Updated] (MYNEWT-364) Don't use bash scripts
[
https://issues.apache.org/jira/browse/MYNEWT-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-364:
---
Fix Version/s: (was: v1_1_0_rel)
> Don't use bash scripts
> --
>
> Key: MYNEWT-364
> URL: https://issues.apache.org/jira/browse/MYNEWT-364
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Affects Versions: v0_9_0
> Environment: Ubuntu 14.10 using the Docker version of newt
>Reporter: Tim
>Assignee: Christopher Collins
>
> The download and debug scripts are currently written using Bash. That is
> unfortunate because Bash is very error-prone and scripts tend to be buggy.
> Also, it makes distribution on Windows much harder.
> You're already using Go, I'd suggest rewriting them using that. Alternatives
> are Python, Powershell, Lua, etc.
> I've rewritten nrf52_download.sh in Go (below; compiled but not tested). It
> was very easy, and is only 7 lines longer (due to extra error
> checking/reporting).
> The main downside is the size - 2.7 MB, but it can be reduced to 523 kB by
> stripping debug symbols and compressing it with upx. I think that is
> reasonable for now. You can combine debug and download scripts for further
> savings if necessary.
> {code}
> // Licensed to the Apache Software Foundation (ASF) under one
> // or more contributor license agreements. See the NOTICE file
> // distributed with this work for additional information
> // regarding copyright ownership. The ASF licenses this file
> // to you under the Apache License, Version 2.0 (the
> // "License"); you may not use this file except in compliance
> // with the License. You may obtain a copy of the License at
> //
> // http://www.apache.org/licenses/LICENSE-2.0
> //
> // Unless required by applicable law or agreed to in writing,
> // software distributed under the License is distributed on an
> // "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> // KIND, either express or implied. See the License for the
> // specific language governing permissions and limitations
> // under the License.
> package main
> import (
> "fmt"
> "io/ioutil"
> "log"
> "os"
> "os/exec"
> "strings"
> )
> func main() {
> if len(os.Args) == 1 {
> log.Fatalf(`
> Usage: {} [features...]
> - bsp_directory_path is absolute path to hw/bsp/bsp_name
> - binary is the path to prefix to target binary, .elf.bin appended to this
> name is the raw binary format of the binary.
> - features are the target features. So you can have e.g. different
> flash offset for bootloader 'feature')
> `, os.Args[0])
> }
> if len(os.Args) < 3 {
> log.Fatal("Need binary to download")
> }
> // Look for 'bootloader' from 3rd arg onwards (in the features)
> isBootloader := false
> if len(os.Args) > 3 {
> for i := range os.Args[3:] {
> if os.Args[i] == "bootloader" {
> isBootloader = true
> }
> }
> }
> basename := os.Args[2]
> flashOffset := 0x8000
> filename := basename + ".img"
> if isBootloader {
> flashOffset = 0
> filename = basename + ".elf.bin"
> }
> gdbCmdFile := ".gdb_cmds"
> log.Printf("Downloading %s to %#x", filename, flashOffset)
> // XXX for some reason JLinkExe overwrites flash at offset 0 when
> // downloading somewhere in the flash. So need to figure out how to
> tell it
> // not to do that, or report failure if gdb fails to write this file
> gdbCmds := fmt.Sprintf(`
> shell /bin/sh -c 'trap \"\" 2;JLinkGDBServer -device nRF52 -speed 4000 -if
> SWD -port -singlerun' &
> target remote localhost:
> restore %s binary %#x
> quit
> `, filename, flashOffset)
> err := ioutil.WriteFile(gdbCmdFile, []byte(gdbCmds), 0664)
> if err != nil {
> log.Fatalf("Error writing to %s: %v", gdbCmdFile, err)
> }
> defer os.Remove(gdbCmdFile)
> msgs, err := exec.Command("arm-none-eabi-gdb", "-x",
> gdbCmdFile).CombinedOutput()
> ioutil.WriteFile(".gdb_out", msgs, 0664)
> if err != nil {
> log.Fatalf("Error running gdb: %v", err)
> }
> smsgs := string(msgs)
> if strings.Contains(smsgs, "error") ||
> strings.Contains(smsgs, "failed") ||
> strings.Contains(smsgs, "unknown / supported") ||
> strings.Contains(smsgs, "No such file or directory") {
> os.Exit(1)
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
[ https://issues.apache.org/jira/browse/MYNEWT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-774. Resolution: Fixed > Intermittent serial errors in newtmgr messages on Arduino Zero > -- > > Key: MYNEWT-774 > URL: https://issues.apache.org/jira/browse/MYNEWT-774 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/323) > Using the nmgr_shell transport (newtmgr over shell), some incoming commands > get dropped. The problem seems to be caused by an exhaustion of shell events. > By default, the shell only allocates a single event. > The sequence looks like this: > # Client sends newtmgr command to device. > # Console passes newtmgr command to shell. > # Shell allocates the only event and fills it with the data. > # Shell processes event, hands data to newtmgr code. > # Newtmgr processes command and sends response. > # Client sees response and sends follow-up command. > # Console passes newtmgr command to shell. > # Shell has no events left; drops incoming command. > # Initial event gets freed. > By changing the default event count from 1 to 2, we ensure there is always a > spare event available. Since we will never send the second response before > freeing the first event, two events is sufficient. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
[ https://issues.apache.org/jira/browse/MYNEWT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043486#comment-16043486 ] ASF subversion and git services commented on MYNEWT-774: Commit ee14e32eb54f3b93b6d632ad64ae57d26fbfbf2d in incubator-mynewt-core's branch refs/heads/master from ccollins476ad [ https://gitbox.apache.org/repos/asf?p=incubator-mynewt-core.git;h=ee14e32 ] Merge pull request #323 from ccollins476ad/shell-max-events MYNEWT-774 Serial errors in newtmgr messages > Intermittent serial errors in newtmgr messages on Arduino Zero > -- > > Key: MYNEWT-774 > URL: https://issues.apache.org/jira/browse/MYNEWT-774 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/323) > Using the nmgr_shell transport (newtmgr over shell), some incoming commands > get dropped. The problem seems to be caused by an exhaustion of shell events. > By default, the shell only allocates a single event. > The sequence looks like this: > # Client sends newtmgr command to device. > # Console passes newtmgr command to shell. > # Shell allocates the only event and fills it with the data. > # Shell processes event, hands data to newtmgr code. > # Newtmgr processes command and sends response. > # Client sees response and sends follow-up command. > # Console passes newtmgr command to shell. > # Shell has no events left; drops incoming command. > # Initial event gets freed. > By changing the default event count from 1 to 2, we ensure there is always a > spare event available. Since we will never send the second response before > freeing the first event, two events is sufficient. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-775) Crash due to unaligned accesses during CoAP parsing.
[ https://issues.apache.org/jira/browse/MYNEWT-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043482#comment-16043482 ] ASF subversion and git services commented on MYNEWT-775: Commit 2b23934335b25cde92ebb80a9330210aa662ab05 in incubator-mynewt-core's branch refs/heads/master from [~ccollins476] [ https://gitbox.apache.org/repos/asf?p=incubator-mynewt-core.git;h=2b23934 ] MYNEWT-775 Crash; unaligned accesses: CoAP parsing > Crash due to unaligned accesses during CoAP parsing. > > > Key: MYNEWT-775 > URL: https://issues.apache.org/jira/browse/MYNEWT-775 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/322) > Some code assumes that an mbuf's om_data pointer is suitably aligned for > struct pointer access. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-775) Crash due to unaligned accesses during CoAP parsing.
[ https://issues.apache.org/jira/browse/MYNEWT-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043483#comment-16043483 ] ASF subversion and git services commented on MYNEWT-775: Commit 258625bdc299d414d6ad4283b0e30e9dacdd62d8 in incubator-mynewt-core's branch refs/heads/master from ccollins476ad [ https://gitbox.apache.org/repos/asf?p=incubator-mynewt-core.git;h=258625b ] Merge pull request #322 from ccollins476ad/coap-unaligned MYNEWT-775 Crash; unaligned accesses: CoAP parsing > Crash due to unaligned accesses during CoAP parsing. > > > Key: MYNEWT-775 > URL: https://issues.apache.org/jira/browse/MYNEWT-775 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/322) > Some code assumes that an mbuf's om_data pointer is suitably aligned for > struct pointer access. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
[ https://issues.apache.org/jira/browse/MYNEWT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-774: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/323) Using the nmgr_shell transport (newtmgr over shell), some incoming commands get dropped. The problem seems to be caused by an exhaustion of shell events. By default, the shell only allocates a single event. The sequence looks like this: # Client sends newtmgr command to device. # Console passes newtmgr command to shell. # Shell allocates the only event and fills it with the data. # Shell processes event, hands data to newtmgr code. # Newtmgr processes command and sends response. # Client sees response and sends follow-up command. # Console passes newtmgr command to shell. # Shell has no events left; drops incoming command. # Initial event gets freed. By changing the default event count from 1 to 2, we ensure there is always a spare event available. Since we will never send the second response before freeing the first event, two events is sufficient. was: Using the nmgr_shell transport (newtmgr over shell), some incoming commands get dropped. The problem seems to be caused by an exhaustion of shell events. By default, the shell only allocates a single event. The sequence looks like this: # Client sends newtmgr command to device. # Console passes newtmgr command to shell. # Shell allocates the only event and fills it with the data. # Shell processes event, hands data to newtmgr code. # Newtmgr processes command and sends response. # Client sees response and sends follow-up command. # Console passes newtmgr command to shell. # Shell has no events left; drops incoming command. # Initial event gets freed. By changing the default event count from 1 to 2, we ensure there is always a spare event available. Since we will never send the second response before freeing the first event, two events is sufficient. > Intermittent serial errors in newtmgr messages on Arduino Zero > -- > > Key: MYNEWT-774 > URL: https://issues.apache.org/jira/browse/MYNEWT-774 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/323) > Using the nmgr_shell transport (newtmgr over shell), some incoming commands > get dropped. The problem seems to be caused by an exhaustion of shell events. > By default, the shell only allocates a single event. > The sequence looks like this: > # Client sends newtmgr command to device. > # Console passes newtmgr command to shell. > # Shell allocates the only event and fills it with the data. > # Shell processes event, hands data to newtmgr code. > # Newtmgr processes command and sends response. > # Client sees response and sends follow-up command. > # Console passes newtmgr command to shell. > # Shell has no events left; drops incoming command. > # Initial event gets freed. > By changing the default event count from 1 to 2, we ensure there is always a > spare event available. Since we will never send the second response before > freeing the first event, two events is sufficient. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
[ https://issues.apache.org/jira/browse/MYNEWT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-774: --- Description: Using the nmgr_shell transport (newtmgr over shell), some incoming commands get dropped. The problem seems to be caused by an exhaustion of shell events. By default, the shell only allocates a single event. The sequence looks like this: # Client sends newtmgr command to device. # Console passes newtmgr command to shell. # Shell allocates the only event and fills it with the data. # Shell processes event, hands data to newtmgr code. # Newtmgr processes command and sends response. # Client sees response and sends follow-up command. # Console passes newtmgr command to shell. # Shell has no events left; drops incoming command. # Initial event gets freed. By changing the default event count from 1 to 2, we ensure there is always a spare event available. Since we will never send the second response before freeing the first event, two events is sufficient. was: The problem seems to be caused by an exhaustion of shell events. By default, the shell only allocates a single event. The sequence looks like this: # Client sends newtmgr command to device. # Console passes newtmgr command to shell. # Shell allocates the only event and fills it with the data. # Shell processes event, hands data to newtmgr code. # Newtmgr processes command and sends response. # Client sees response and sends follow-up command. # Console passes newtmgr command to shell. # Shell has no events left; drops incoming command. # Initial event gets freed. By changing the default event count from 1 to 2, we ensure there is always a spare event available. Since we will never send the second response before freeing the first event, two events is sufficient. > Intermittent serial errors in newtmgr messages on Arduino Zero > -- > > Key: MYNEWT-774 > URL: https://issues.apache.org/jira/browse/MYNEWT-774 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > Using the nmgr_shell transport (newtmgr over shell), some incoming commands > get dropped. The problem seems to be caused by an exhaustion of shell events. > By default, the shell only allocates a single event. > The sequence looks like this: > # Client sends newtmgr command to device. > # Console passes newtmgr command to shell. > # Shell allocates the only event and fills it with the data. > # Shell processes event, hands data to newtmgr code. > # Newtmgr processes command and sends response. > # Client sees response and sends follow-up command. > # Console passes newtmgr command to shell. > # Shell has no events left; drops incoming command. > # Initial event gets freed. > By changing the default event count from 1 to 2, we ensure there is always a > spare event available. Since we will never send the second response before > freeing the first event, two events is sufficient. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
[ https://issues.apache.org/jira/browse/MYNEWT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-774: --- Description: The problem seems to be caused by an exhaustion of shell events. By default, the shell only allocates a single event. The sequence looks like this: # Client sends newtmgr command to device. # Console passes newtmgr command to shell. # Shell allocates the only event and fills it with the data. # Shell processes event, hands data to newtmgr code. # Newtmgr processes command and sends response. # Client sees response and sends follow-up command. # Console passes newtmgr command to shell. # Shell has no events left; drops incoming command. # Initial event gets freed. By changing the default event count from 1 to 2, we ensure there is always a spare event available. Since we will never send the second response before freeing the first event, two events is sufficient. > Intermittent serial errors in newtmgr messages on Arduino Zero > -- > > Key: MYNEWT-774 > URL: https://issues.apache.org/jira/browse/MYNEWT-774 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > The problem seems to be caused by an exhaustion of shell events. By > default, the shell only allocates a single event. > The sequence looks like this: > # Client sends newtmgr command to device. > # Console passes newtmgr command to shell. > # Shell allocates the only event and fills it with the data. > # Shell processes event, hands data to newtmgr code. > # Newtmgr processes command and sends response. > # Client sees response and sends follow-up command. > # Console passes newtmgr command to shell. > # Shell has no events left; drops incoming command. > # Initial event gets freed. > By changing the default event count from 1 to 2, we ensure there is > always a spare event available. Since we will never send the second > response before freeing the first event, two events is sufficient. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-775) Crash due to unaligned accesses during CoAP parsing.
[ https://issues.apache.org/jira/browse/MYNEWT-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-775: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/322) Some code assumes that an mbuf's om_data pointer is suitably aligned for struct pointer access. was: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/322) Some code assumes that an mbuf's om_data pointer is suitable aligned for struct pointer access. > Crash due to unaligned accesses during CoAP parsing. > > > Key: MYNEWT-775 > URL: https://issues.apache.org/jira/browse/MYNEWT-775 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/322) > Some code assumes that an mbuf's om_data pointer is suitably aligned for > struct pointer access. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-738) Fix Parameter arrays in events and elsewhere
[ https://issues.apache.org/jira/browse/MYNEWT-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043301#comment-16043301 ] ASF subversion and git services commented on MYNEWT-738: Commit f0ca77a427f0aca30400b71a21f3206471a878fa in incubator-mynewt-core's branch refs/heads/master from [~janc] [ https://gitbox.apache.org/repos/asf?p=incubator-mynewt-core.git;h=f0ca77a ] Merge pull request #311 from wes3/myn738 MYNEWT-738: Fix parameter arrays > Fix Parameter arrays in events and elsewhere > > > Key: MYNEWT-738 > URL: https://issues.apache.org/jira/browse/MYNEWT-738 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Affects Versions: v1_0_0_rel >Reporter: William San Filippo >Assignee: William San Filippo > Fix For: v1_1_0_rel > > > It appears that for some events and possible commands that the specification > was interpreted incorrectly. Multiple parameter arrays are treated in the > following manner: > Arrayed parameters are specified using the following notation: ParameterA[i]. > If more than one set of arrayed parameters are specified (e.g. ParameterA[i], > ParameterB[i]), then the order of the parameters are as follows: > ParameterA[0], ParameterB[0], ParameterA[1], ParameterB[1], ParameterA[2], > ParameterB[2], … ParameterA[n], ParameterB[n] > Need to go through the controller and host code to fix all places where this > is incorrect. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-738) Fix Parameter arrays in events and elsewhere
[ https://issues.apache.org/jira/browse/MYNEWT-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043300#comment-16043300 ] ASF subversion and git services commented on MYNEWT-738: Commit c921fd5c652fad3505d598f14f53441d4be32566 in incubator-mynewt-core's branch refs/heads/master from [~wes3] [ https://gitbox.apache.org/repos/asf?p=incubator-mynewt-core.git;h=c921fd5 ] MYNEWT-738: Fix parameter arrays This code change fixes our incorrect interpretation of the BLE specification regarding parameter arrays when parsing advertising reports. > Fix Parameter arrays in events and elsewhere > > > Key: MYNEWT-738 > URL: https://issues.apache.org/jira/browse/MYNEWT-738 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Affects Versions: v1_0_0_rel >Reporter: William San Filippo >Assignee: William San Filippo > Fix For: v1_1_0_rel > > > It appears that for some events and possible commands that the specification > was interpreted incorrectly. Multiple parameter arrays are treated in the > following manner: > Arrayed parameters are specified using the following notation: ParameterA[i]. > If more than one set of arrayed parameters are specified (e.g. ParameterA[i], > ParameterB[i]), then the order of the parameters are as follows: > ParameterA[0], ParameterB[0], ParameterA[1], ParameterB[1], ParameterA[2], > ParameterB[2], … ParameterA[n], ParameterB[n] > Need to go through the controller and host code to fix all places where this > is incorrect. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-775) Crash due to unaligned accesses during CoAP parsing.
Christopher Collins created MYNEWT-775: -- Summary: Crash due to unaligned accesses during CoAP parsing. Key: MYNEWT-775 URL: https://issues.apache.org/jira/browse/MYNEWT-775 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel Some code assumes that an mbuf's om_data pointer is suitable aligned for struct pointer access. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
Christopher Collins created MYNEWT-774: -- Summary: Intermittent serial errors in newtmgr messages on Arduino Zero Key: MYNEWT-774 URL: https://issues.apache.org/jira/browse/MYNEWT-774 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel -- This message was sent by Atlassian JIRA (v6.3.15#6346)
