[jira] [Resolved] (MYNEWT-759) Change BLE-over-CoAP UUID from 128-bit to 16-bit

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-759.

Resolution: Won't Fix

This will be part of the cloud connector package, not the 1.1.0 release.

> Change BLE-over-CoAP UUID from 128-bit to 16-bit
> 
>
> Key: MYNEWT-759
> URL: https://issues.apache.org/jira/browse/MYNEWT-759
> Project: Mynewt
>  Issue Type: Improvement
>  Security Level: Public(Viewable by anyone) 
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The plan is to reserve a 16-bit UUID with the Bluetooth SIG.  In the 
> meantime, we will use the (arbitrarilly chosen) UUID 0x9923.



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

Re: Conditional compilation based on BSP name

[Christopher Collins]

On Wed, Jun 14, 2017 at 04:22:52PM +0200, Ugo Mastracchio wrote:
> Hello everyone, may I throw an absolute beginner's question ? 
> 
> How do I conditionally compile based on the BSP the target is
> associated with ?I want to use different GPIO pins depending on the board
> 
> Is there a system configuration setting valued with the BSP name ?

After writing my previous response, I am thinking I may have
misunderstood the question.  Generally, the PIN mappings are defined in
the BSP package itself, so there should be no need to remap pins based
on the BSP being used.  Are you perhaps trying to use the same BSP
package for two slightly different boards?

If this is what you want to do, you may want to take a look at how the
arduino_zero BSP handles this.  The 1) arduino zero and 2) arduino zero
pro hardware is very similar.  I believe the only difference are a few
GPIO mappings.  Rather than create a separate BSP for each board, the
arduino BSP package code uses conditional compilation.

Within the arduino repo
(https://github.com/runtimeco/mynewt_arduino_zero), the arduino_zero BSP
defines these settings:

BSP_ARDUINO_ZERO:
description: 'TBD'
value: 0
restrictions:
- "!BSP_ARDUINO_ZERO_PRO"

BSP_ARDUINO_ZERO_PRO:
description: 'TBD'
value: 0
restrictions:
- "!BSP_ARDUINO_ZERO"

Then, in hw/bsp/arduino_zero/include/bsp/bsp.h, pins are mapped as
follows:

#if MYNEWT_VAL(BSP_ARDUINO_ZERO_PRO)
 ARDUINO_ZERO_D2 = (8),
 ARDUINO_ZERO_D4 = (14),
#endif

#if MYNEWT_VAL(BSP_ARDUINO_ZERO)
 ARDUINO_ZERO_D2 = (14),
 ARDUINO_ZERO_D4 = (8),
#endif

It is up to the target package to define one (and only one) of
BSP_ARDUINO_ZERO_PRO or BSP_ARDUINO_ZERO.

This approach is nice because it eliminates the need for a lot of
duplicate code in a second BSP package.  One hassle involved is the
necessity to define the appropriate syscfg setting in the target
package.

Chris

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

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-664.

Resolution: Fixed

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



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-752.

Resolution: Fixed

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



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

Re: Cannot resolve dependency

[Christopher Collins]

On Fri, Jun 09, 2017 at 05:59:26PM -0700, Christopher Collins wrote:
> By the way, there is an unfortunate bug in the current version of newt.
> The dependency resolution error message gets the depender name wrong; it
> prints the dependee package instead!

I forgot to mention that this bug has since been fixed in the master
branch.

Chris

Re: Cannot resolve dependency

[Christopher Collins]

Hi Greg,

On Fri, Jun 09, 2017 at 05:47:11PM -0700, Greg Strange wrote:
> Hi,
> 
> I'm new to mynewt. I went through the quick start and have successfully
> installed mynewt, and have built and run the blinky project targeted to a
> NRF52 board.
> 
> As a next step I decided to copy the ble peripheral sample project into my
> own apps directory as a starting point for a simple BLE project. After
> doing so though the project will not build and I get this error:
> 
> *Building target targets/nrf52_blep*
> *Error: Could not resolve package dependency: @apache-mynewt-core/kernel/os
> ; depender: kernel/os*
> 
> 
> 
> A little more background  When I say "copy the ble peripheral sample
> project", what I did is copy apache-mynewt-core/apps/bleprph into apps, and
> renamed it "blep" because it's easier to type. I edited pkg.yml and added
> @apache-mynewt-core to all the dependencies so that pkg.yml now looks like
> this:
> 
> pkg.name: apps/blep
> pkg.type: app
> pkg.description: Simple BLE peripheral application.
> pkg.author: "Apache Mynewt "
> pkg.homepage: "http://mynewt.apache.org/;
> pkg.keywords:
> 
> pkg.deps:
> - "@apache-mynewt-core/boot/split"
> - "@apache-mynewt-core/kernel/os "

I believe the issue is caused by the trailing space above.

> - "@apache-mynewt-core/mgmt/imgmgr"
> - "@apache-mynewt-core/mgmt/newtmgr"
> - "@apache-mynewt-core/mgmt/newtmgr/transport/ble"
> - "@apache-mynewt-core/net/nimble/controller"
> - "@apache-mynewt-core/net/nimble/host"
> - "@apache-mynewt-core/net/nimble/host/services/ans"
> - "@apache-mynewt-core/net/nimble/host/services/gap"
> - "@apache-mynewt-core/net/nimble/host/services/gatt"
> - "@apache-mynewt-core/net/nimble/host/store/ram"
> - "@apache-mynewt-core/net/nimble/transport/ram"
> - "@apache-mynewt-core/sys/console/full"
> - "@apache-mynewt-core/sys/log/full"
> - "@apache-mynewt-core/sys/stats/full"
> - "@apache-mynewt-core/sys/sysinit"
> - "@apache-mynewt-core/sys/id"
> 
> 
> I also created a nrf52 target for blep.
> 
> Am I missing something?  If I point my target to the original bleprph
> project in the apache-mynewt-core directory, it builds fine.  But if I move
> it to my own apps directory I cannot get it to build.

That is a good way to get started with a new app.  I don't anticipate
any more errors after this one is solved.

By the way, there is an unfortunate bug in the current version of newt.
The dependency resolution error message gets the depender name wrong; it
prints the dependee package instead!

Chris

[jira] [Created] (MYNEWT-778) newt - "newt run" fails for native targets

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-778:
--

 Summary: newt - "newt run" fails for native targets
 Key: MYNEWT-778
 URL: https://issues.apache.org/jira/browse/MYNEWT-778
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Newt
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


This issue seems to have been introduced by MYNEWT-694.

If the user runs "newt run" without specifying a version number, newt prompts 
the user for a version number and uses it to build an image.  This behavior is 
correct most of the time, but it is incorrect for sim targets.  Sim targets use 
plain elf files, not image files, so newt shouldn't prompt the user for a 
version number in this case.



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

[jira] [Updated] (MYNEWT-364) Don't use bash scripts

[Christopher Collins (JIRA)]

 [ 
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

[Christopher Collins (JIRA)]

 [ 
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] [Updated] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero

[Christopher Collins (JIRA)]

 [ 
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

[Christopher Collins (JIRA)]

 [ 
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

[Christopher Collins (JIRA)]

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

[Christopher Collins (JIRA)]

 [ 
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] [Created] (MYNEWT-775) Crash due to unaligned accesses during CoAP parsing.

[Christopher Collins (JIRA)]

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 (JIRA)]

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)

[jira] [Resolved] (MYNEWT-770) Sim - Share sig/no-sig implementation for all sim architectures

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-770.

Resolution: Fixed

> Sim - Share sig/no-sig implementation for all sim architectures
> ---
>
> Key: MYNEWT-770
> URL: https://issues.apache.org/jira/browse/MYNEWT-770
> 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/306)
> In MYNEWT-745, sim was split into two implementations:
> * signals
> * no-signals
> The above change was applied to the i386 version of sim, but not to the other 
> sim implementations (ARMv7 and MIPS).
> This ticket is for extracting the signals and no-signals code into a 
> standalone package that can be used by all sim implementations.



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-550.

Resolution: Fixed

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



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

Re: Host Only Project

[Christopher Collins]

Hi Khaled,

On Wed, Jun 07, 2017 at 04:26:01PM +0200, Khaled Elsayed wrote:
[...]
> So, it has the controller and uart only. My questions are:
> 
> 1) What glues the different parts together? How does the code identify that
> when I include the transport/ram that host and link layer will communicate
> via RAM not uart. Where in the code is this handled?
> Similarly, if host, gap, gatt, etc are missing from pkg.yml where in the
> code are these modules avoided to be initialized or loaded (or more clearly
> where in the code are they loaded and initialized when they exist in the
> dependency)?

The answer to both questions lies in the sysinit() call.  The code that
ultimately gets executed by sysinit() is magically generated by newt
each time you build a target.  The sysinit function initializes each
package in the project.  Each package specifies zero or more "init"
functions, each with a corresponding stage number.  The generated
sysinit function is a flat sequence calls to each of these init
functions, ordered by stage.

The benefits of this mechanism are:
1. Apps can be configured and re-used without needing code
   modifications.
2. App code is simplified by the elimination of boilerplate
   initialization code.

The downside is, of course, generated code, which everyone hates :).

This is discussed in more detail at:
http://mynewt.apache.org/latest/os/modules/sysinitconfig/sysinitconfig/

This explains the initialization of the host, gap, and gatt packages.
If these packages get pulled in to your project, newt generates calls to
their initialization function in sysinit().

The BLE transport case is slightly more complicated.  Here, another
Mynewt concept is required: APIs.  

When a package declares that it supports a particular API, it promises
to the rest of the system that it exposes a set of functions and global
variables.  This allows another package to express an "abstract
dependency."  That is, a package depends on a particular interface, but
it doesn't care which package actually provides that interface.  The
collection of bluetooth HCI transports packages is an example of this.
The host and controller code is written such that they don't know the
specific transport being used; they just use the abstract API provided
by all the HCI transport packages.

The host package doesn't have a hard dependency on a specific transport
package.  Instead, it requires the "ble_transport" API.  At build time,
newt ensures that one (and only one) package provides the required API,
and it gives the host code access to the transport package's header
files.

Note: The newt tool doesn't verify that a package actually implements
the APIs is claims to.  The newt tool just makes sure that for each
required API, one and only one package that supplies the API gets pulled
in to the build.

At init time, the host package configures the transport package
(whichever one it may be) with function pointer callbacks.  In this way,
the host doesn't need to know which transport is actually being used,
and the transport doesn't need to depend on the host or controller.

> 2)  If one wants to use mynewt as host only with nordic soft device as is,
> certainly pkg.yml will not include net/nimble/controller. So, how to tell
> the build system to load or leave nordic controller in place?

You need to make sure your project does not depend on the controller
package.  Generally, there are two changes you would make to an app's
pkg.yml file to convert it from a combined-host-controller app to a
host-only app:

1. Remove from pkg.deps:
@apache-mynewt-core/net/nimble/controller
@apache-mynewt-core/net/nimble/transport/ram

2. Add your desired transport package to pkg.deps, e.g.,
@apache-mynewt-core/net/nimble/transport/uart

Chris

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

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-661.

Resolution: Fixed

Thanks, Łukasz.  It looks good.

{noformat}
007743 compat> b sec start conn=1
008183 module: 0, command: b
008184 [ts=63937440ssb, mod=4 level=0] looking up peer sec; peer_addr_type=0 
peer_addr=0x34 0x22 0x00 0x99 0x99 0x99
008187 [ts=63960876ssb, mod=4 level=0] host tx hci data; handle=1 length=11
008189 [ts=63976500ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0b 0x00 
0x07 0x00 0x06 0x00 0x01 0x03 0x00 0x09 0x10 0x07 0x07
008193 [ts=64007812ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x0018 
len=0
008195 [ts=64023436ssb, mod=4 level=0] 0x18 0x20 0x00
008196 [ts=64031248ssb, mod=4 level=0] Command complete: cmd_pkts=1 ogf=0x8 
ocf=0x18 status=0 rand=0xc213c8492ede7859
008199 [ts=64054684ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x0018 
len=0
008202 [ts=64078120ssb, mod=4 level=0] 0x18 0x20 0x00
008203 [ts=64085932ssb, mod=4 level=0] Command complete: cmd_pkts=1 ogf=0x8 
ocf=0x18 status=0 rand=0x07be2ac5aa1e6e57
008206 compat> Number of Completed Packets: num_handles=1
008210 [ts=64140616ssb, mod=4 level=0] handle:1 pkts:1
008215 [ts=64179676ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): 
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x06 0x00 0x02 0x03 0x00 0x01 0x10 
0x07 0x07
008219 [ts=64210924ssb, mod=4 level=0] rxed sm command: pair rsp; conn=1 
io_cap=3 oob_data_flag=0 authreq=0x01 mac_enc_key_size=16 init_key_dist=7 
resp_key_dist=7
008223 [ts=64242172ssb, mod=4 level=0] host tx hci data; handle=1 length=6
008225 [ts=64257796ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x06 0x00 
0x02 0x00 0x06 0x00 0x05 0x03
008228 encryption change event; status=1027 handle=1 our_ota_addr_type=0 
our_ota_addr=0a:45:00:11:22:33 our_id_addr_type=0 our_id_addr=0a:45:00:11:22:33 
peer_ota_addr_type=0 peer_ota_addr=99:99:99:00:22:34 peer_id_addr_type=0 
peer_id_addr=99:99:99:00:22:34 conn_itvl=40 conn_latency=0 
supervision_timeout=256 encrypted=0 authenticated=0 bonded=0
008241 [ts=64382788ssb, mod=4 level=0] Number of Completed Packets: 
num_handles=1
008243 [ts=64398412ssb, mod=4 level=0] handle:1 pkts:1
{noformat}

(we get an authreq error now.)

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



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-752:


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

h3. Before fix:
{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph 
--name nimble-bleprph image test 
5ff2addc0fb7bde71fd03dd161834e61ded2041652c37196f180b12091c2ff55
Images:
 slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: bd42be9757549d4209ce873ab68f7cd290a9c494398d39af6b5702ec66aafb7d
 slot=1
version: 2.2.2.2
bootable: true
flags: pending
hash: 5ff2addc0fb7bde71fd03dd161834e61ded2041652c37196f180b12091c2ff55
Split status: N/A (0)
{noformat}

(reset device)

{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph 
--name nimble-bleprph image list
Images:
 slot=0
version: 2.2.2.2
bootable: true
flags: active
hash: 5ff2addc0fb7bde71fd03dd161834e61ded2041652c37196f180b12091c2ff55
 slot=1
version: 0.0.0
bootable: true
flags: confirmed
hash: bd42be9757549d4209ce873ab68f7cd290a9c494398d39af6b5702ec66aafb7d
Split status: N/A (0)

[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph 
--name nimble-bleprph image confirm 
5ff2addc0fb7bde71fd03dd161834e61ded2041652c37196f180b12091c2ff55
Images:
 slot=0
version: 2.2.2.2
bootable: true
flags: active confirmed
hash: 5ff2addc0fb7bde71fd03dd161834e61ded2041652c37196f180b12091c2ff55
 slot=1
version: 0.0.0
bootable: true
flags: pending permanent
hash: bd42be9757549d4209ce873ab68f7cd290a9c494398d39af6b5702ec66aafb7d
Split status: N/A (0)
{noformat}

h3. After fix:
{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph 
--name nimble-bleprph image test 
817b16111d40151345566e73a2a2f999fd2efd65d43a1a98cdccd991ee0be775
Images:
 slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: 1c71f96bcff94e6f2307f9b28bd0249fa73f0bb0819a99ee5bacc4db4e2179e3
 slot=1
version: 2.2.2.2
bootable: true
flags: pending
hash: 817b16111d40151345566e73a2a2f999fd2efd65d43a1a98cdccd991ee0be775
Split status: N/A (0)
{noformat}

(reset device)

{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph 
--name nimble-bleprph image list
Images:
 slot=0
version: 2.2.2.2
bootable: true
flags: active
hash: 817b16111d40151345566e73a2a2f999fd2efd65d43a1a98cdccd991ee0be775
 slot=1
version: 0.0.0
bootable: true
flags: confirmed
hash: 1c71f96bcff94e6f2307f9b28bd0249fa73f0bb0819a99ee5bacc4db4e2179e3
Split status: N/A (0)

[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph 
--name nimble-bleprph image confirm 
817b16111d40151345566e73a2a2f999fd2efd65d43a1a98cdccd991ee0be775
Images:
 slot=0
version: 2.2.2.2
bootable: true
flags: active confirmed
hash: 817b16111d40151345566e73a2a2f999fd2efd65d43a1a98cdccd991ee0be775
 slot=1
version: 0.0.0
bootable: true
flags:
hash: 1c71f96bcff94e6f2307f9b28bd0249fa73f0bb0819a99ee5bacc4db4e2179e3
Split status: N/A (0)
{noformat}

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



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-772.

Resolution: Fixed

> BLE Host - Initial set-event-mask specifies reserved bits
> -
>
> Key: MYNEWT-772
> URL: https://issues.apache.org/jira/browse/MYNEWT-772
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Nimble
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-core/pull/307)
> The host intends to enable the following events at start up:
> {noformat}
> /**
>  * Enable the following events:
>  * 0x0001 Inquiry Complete Event
>  * 0x0002 Inquiry Result Event
>  * 0x0004 Connection Complete Event
>  * 0x0008 Connection Request Event
>  * 0x0010 Disconnection Complete Event
>  * 0x0020 Authentication Complete Event
>  * 0x0040 Remote Name Request Complete Event
>  * 0x0080 Encryption Change Event
>  * 0x0100 Change Connection Link Key Complete Event
>  * 0x0200 Master Link Key Complete Event
>  * 0x0400 Read Remote Supported Features Complete Event
>  * 0x0800 Read Remote Version Information Complete Event
>  * 0x1000 QoS Setup Complete Event
>  * 0x2000 Reserved
>  * 0x4000 Reserved
>  * 0x8000 Hardware Error Event
>  * 0x0001 Flush Occurred Event
>  * 0x0002 Role Change Event
>  * 0x0004 Reserved
>  * 0x0008 Mode Change Event
>  * 0x0010 Return Link Keys Event
>  * 0x0020 PIN Code Request Event
>  * 0x0040 Link Key Request Event
>  * 0x0080 Link Key Notification Event
>  * 0x0100 Loopback Command Event
>  * 0x0200 Data Buffer Overflow Event
>  * 0x0400 Max Slots Change Event
>  * 0x0800 Read Clock Offset Complete Event
>  * 0x1000 Connection Packet Type Changed Event
>  * 0x2000 QoS Violation Event
>  * 0x4000 Page Scan Mode Change Event [deprecated]
>  * 0x8000 Page Scan Repetition Mode Change Event
>  * 0x0001 Flow Specification Complete Event
>  * 0x0002 Inquiry Result with RSSI Event
>  * 0x0004 Read Remote Extended Features Complete Event
>  * 0x0800 Synchronous Connection Complete Event
>  * 0x1000 Synchronous Connection Changed Event
>  * 0x8000 Encryption Key Refresh Complete Event
>  * 0x2000 LE Meta-Event
>  */
> {noformat}
> It does this by setting the following bit mask: {{0x20009fff}}.  This 
> mask is incorrect; it should be: {{0x20009807}}.



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

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

[Christopher Collins (JIRA)]

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

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

This would be analogous to the "image upload", "file upload", and "file 
download" commands.  Each of these indicate the total number of bytes in the 
first packet.

This change involves a backwards compatible modification to the NMP protocol.  
Compatibility is maintained because this change only requires the addition of a 
new field, not the modification or removal of existing fields.

  was:
This would be analogous to the "image upload", "file upload", and "file 
download" commands.  Each of these indicate the total number of bytes in the 
first packet.

This change involves a backwards compatible modification to the NMP protocol.  
Compatibility is maintained because this change only requires the addition of a 
new field, not the modification or removal of existing fields.


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



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

[jira] [Resolved] (MYNEWT-773) Implement oic_serial in "new" newtmgr

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-773.

Resolution: Fixed

> Implement oic_serial in "new" newtmgr
> -
>
> Key: MYNEWT-773
> URL: https://issues.apache.org/jira/browse/MYNEWT-773
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newtmgr
>    Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The old newtmgr 
> (https://github.com/apache/incubator-mynewt-newt/tree/master/newtmgr) 
> supports OMP (newtmgr over CoAP) over serial.
> The new newtmgr 
> (https://github.com/apache/incubator-mynewt-newtmgr/tree/master/newtmgr) 
> lacks this feature.



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-756:


Thanks, Jacob.  When I try with those msys settings (8 / 149), the device does 
not hang and I always receive the NOMEM response.  Here is my target:

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

syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_PUBLIC_DEV_ADDR=(uint8_t[6]){0x1c, 
0x22, 0x00, 0x99, 0x99, 
0x99}:BLE_SM_LEGACY=0:BLE_SM_SC=0:LOG_LEVEL=0:MSYS_1_BLOCK_COUNT=8:MSYS_1_BLOCK_SIZE=149
{noformat}

Could you please paste your target so I can try with your settings?

> mpstats (on nrf51) hangs indefinately
> -
>
> Key: MYNEWT-756
> URL: https://issues.apache.org/jira/browse/MYNEWT-756
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Reporter: Jacob
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> I believe core is failing before sending the last packet, as neither newtmgr 
> or node-newtmgr receives that packet.
> Jacobs-MacBook-Air:newtmgr jacobrosenthal$ GODEBUG=cgocheck=0 newtmgr mpstats 
> -cnimble_bleprph -t -ldebug
> 2017/05/11 22:28:46 [DEBUG] BLE Connection devaddr:[]
> 2017/05/11 22:28:46 [DEBUG] State:PoweredOn
> 2017/05/11 22:28:46 [DEBUG] scanning...
> 2017/05/11 22:28:46 [DEBUG] Peripheral Discovered: , Address:[0 0 0 0 0 0] 
> Address Type:0
> 2017/05/11 22:28:47 Unhandled event: xpc.Dict{"kCBMsgId":53, 
> "kCBMsgArgs":xpc.Dict{"kCBMsgArgDeviceUUID":xpc.UUID{0x2f, 0xd, 0xcb, 0x60, 
> 0xf, 0x3e, 0x47, 0x52, 0xb7, 0x74, 0x13, 0x29, 0x3a, 0x3, 0xd4, 0xd0}, 
> "kCBMsgArgATTMTU":104}}
> 2017/05/11 22:28:47 [DEBUG] Peripheral Connected
> 2017/05/11 22:28:47 [DEBUG] Newtmgr Service Found 
> 2017/05/11 22:28:47 [DEBUG] Newtmgr Characteristic Found
> 2017/05/11 22:28:47 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:0 
> Group:0 Seq:0 Id:3 Data:[]}
> 2017/05/11 22:28:47 [DEBUG] Serializing request &{Op:0 Flags:0 Len:0 Group:0 
> Seq:0 Id:3 Data:[]} into buffer [0 0 0 0 0 0 0 3]
> 2017/05/11 22:28:47 [DEBUG] Tx packet dump:
>   00 00 00 00 00 00 00 03   ||
> 2017/05/11 22:28:47 [DEBUG] Write BLE Packet:buf:: len::8
> 2017/05/11 22:28:47 [DEBUG] Read BLE 
> Packet:buf::l?brcfmpools?fmsys_1?fblksiz$enblks
>   
>   enfreecmin?wble_hci_ram_evt_hi_pool?fblksizHenblkse len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
>   01 00 02 6c 00 00 00 03  bf 62 72 63 00 66 6d 70  |...l.brc.fmp|
> 0010  6f 6f 6c 73 bf 66 6d 73  79 73 5f 31 bf 66 62 6c  |ools.fmsys_1.fbl|
> 0020  6b 73 69 7a 19 01 24 65  6e 62 6c 6b 73 0c 65 6e  |ksiz..$enblks.en|
> 0030  66 72 65 65 09 63 6d 69  6e 00 ff 77 62 6c 65 5f  |free.cmin..wble_|
> 0040  68 63 69 5f 72 61 6d 5f  65 76 74 5f 68 69 5f 70  |hci_ram_evt_hi_p|
> 0050  6f 6f 6c bf 66 62 6c 6b  73 69 7a 18 48 65 6e 62  |ool.fblksiz.Henb|
> 0060  6c 6b 73 02 65|lks.e|
> 2017/05/11 22:28:47 [DEBUG] Deserialized response &{Op:1 Flags:0 Len:620 
> Group:0 Seq:0 Id:3 Data:[191 98 114 99 0 102 109 112 111 111 108 115 191 102 
> 109 115 121 115 95 49 191 102 98 108 107 115 105 122 25 1 36 101 110 98 108 
> 107 115 12 101 110 102 114 101 101 9 99 109 105 110 0 255 119 98 108 101 95 
> 104 99 105 95 114 97 109 95 101 118 116 95 104 105 95 112 111 111 108 191 102 
> 98 108 107 115 105 122 24 72 101 110 98 108 107 115 2 101]}
> 2017/05/11 22:28:47 [DEBUG] Read BLE 
> Packet:buf::nfreecmin?wble_hci_ram_evt_lo_pool?fblksizHenblkenfrecmi?rble_hs_hci_ev_pool?fblksizenblks
>  len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
>   6e 66 72 65 65 02 63 6d  69 6e 00 ff 77 62 6c 65  |nfree.cmin..wble|
> 0010  5f 68 63 69 5f 72 61 6d  5f 65 76 74 5f 6c 6f 5f  |_hci_ram_evt_lo_|
> 0020  70 6f 6f 6c bf 66 62 6c  6b 73 69 7a 18 48 65 6e  |pool.fblksiz.Hen|
> 0030  62 6c 6b 73 08 65 6e 66  72 65 65 08 63 6d 69 6e  |blks.enfree.cmin|
> 0040  08 ff 72 62 6c 65 5f 68  73 5f 68 63 69 5f 65 76  |..rble_hs_hci_ev|
> 0050  5f 70 6f 6f 6c bf 66 62  6c 6b 73 69 7a 10 65 6e  |_pool.fblksiz.en|
> 0060  62 6c 6b 73 0a|blks.|
> 2017/05/11 22:28:47 [DEBUG] Read BLE Packet:buf::enfree
> cmin  
> ?pble_hs_conn_pool?fblksizTenblksenfreecmin?sble_l2cap_chan_pool?fblksizenblksenfr
>  len::1

Re: #if directives and the MYNEWT_VAL(..) macro

[Christopher Collins]

Hi Sigve,

On Tue, Jun 06, 2017 at 01:01:20PM +0200, Sigve Sebastian Farstad wrote:
[...]
> So, there are perhaps two bugs in here. 1) why is MYNEWT_VAL_I2C_0 0 and
> not '0', as it is defined in syscfg.yml?

The single quotes are a YAML escaping mechanism similar to shell
quoting.  So, values of '0' and 0 are identical here.  The newt tool
just puts everything in single quotes to avoid potential issues with
special characters.

> And 2) I2C code is not included properly.
> 
> For 1), CfgEntry structs in the newt tool's source only support string
> entries, so I imagine something gets when going from yml entries to C
> literals.
> 
> One way of solving 2) is to use #ifdef instead of #if when checking if a
> value is defined. However, this doesn't work with the MYNEWT_VAL(..) macro,
> as far as I can tell, so one would need to use MYNEWT_VAL_I2C_0 directly
> instead.
> 
> Currently, I've worked around the issue by setting the I2C_0 value in
> syscfg.yml to something truthy (e.g. true), but it seems to me that the
> intention is for it to be e.g. 0 for I2C_0 and 1 for I2C_1, since the code
> in hal_i2c.c seems to want to use these numbers as array indexes as well.
> 
> Lastly, this probably affects more than just I2C as the #if MYNEWT_VAL(..)
> pattern is used many places in the core.
> 
> 
> Thoughts?

As others have indicated, this particular setting is meant to be a
boolean.  A value of 0 means the I2C port is unused.

I do think you are right in the general case, though: there is a
potential ambiguity.  It is not possible to test if a particular syscfg
setting is undefined:

1. If the package which defines a setting is not part of your project,
the corresponding MYNEWT_VAL_<...> macro won't be defined.

2. If an undefined macro is used in an `#if` context, it evaluates to 0.

So, the use of `#if` depends on the assumption that 0 and undefined are
equivalent in your code.

If you ever need to know if a MYNEWT_VAL setting is truly undefined, I
think you will need to bypass the MYNEWT_VAL() macro and test the value
directly with `#ifdef`, e.g.,

#ifdef MYNEWT_VAL_I2C_0

I don't think I have run into any cases where I've needed to distinguish
undefined from 0, though.

Chris

[jira] [Created] (MYNEWT-773) Implement oic_serial in "new" newtmgr

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-773:
--

 Summary: Implement oic_serial in "new" newtmgr
 Key: MYNEWT-773
 URL: https://issues.apache.org/jira/browse/MYNEWT-773
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: Newtmgr
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


The old newtmgr 
(https://github.com/apache/incubator-mynewt-newt/tree/master/newtmgr) supports 
OMP (newtmgr over CoAP) over serial.

The new newtmgr 
(https://github.com/apache/incubator-mynewt-newtmgr/tree/master/newtmgr) lacks 
this feature.



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-550:


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

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



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-760:


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

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

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




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

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

[Christopher Collins (JIRA)]

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

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

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

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


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

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



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



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

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

[Christopher Collins (JIRA)]

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

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

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



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

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

[Christopher Collins (JIRA)]

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

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

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

I propose the following behavior in such a scenario:

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

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

I propose the following behavior in such a scenario:

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


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



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-756:


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

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

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

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

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

> mpstats (on nrf51) hangs indefinately
> -
>
> Key: MYNEWT-756
> URL: https://issues.apache.org/jira/browse/MYNEWT-756
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
>  Components: Newt
>Reporter: Jacob
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> I believe core is failing before sending the last packet, as neither newtmgr 
> or node-newtmgr receives that packet.
> Jacobs-MacBook-Air:newtmgr jacobrosenthal$ GODEBUG=cgocheck=0 newtmgr mpstats 
> -cnimble_bleprph -t -ldebug
> 2017/05/11 22:28:46 [DEBUG] BLE Connection devaddr:[]
> 2017/05/11 22:28:46 [DEBUG] State:PoweredOn
> 2017/05/11 22:28:46 [DEBUG] scanning...
> 2017/05/11 22:28:46 [DEBUG] Peripheral Discovered: , Address:[0 0 0 0 0 0] 
> Address Type:0
> 2017/05/11 22:28:47 Unhandled event: xpc.Dict{"kCBMsgId":53, 
> "kCBMsgArgs":xpc.Dict{"kCBMsgArgDeviceUUID":xpc.UUID{0x2f, 0xd, 0xcb, 0x60, 
> 0xf, 0x3e, 0x47, 0x52, 0xb7, 0x74, 0x13, 0x29, 0x3a, 0x3, 0xd4, 0xd0}, 
> "kCBMsgArgATTMTU":104}}
> 2017/05/11 22:28:47 [DEBUG] Peripheral Connected
> 2017/05/11 22:28:47 [DEBUG] Newtmgr Service Found 
> 2017/05/11 22:28:47 [DEBUG] Newtmgr Characteristic Found
> 2017/05/11 22:28:47 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:0 
> Group:0 Seq:0 Id:3 Data:[]}
> 2017/05/11 22:28:47 [DEBUG] Serializing request &{Op:0 Flags:0 Len:0 Group:0 
> Seq:0 Id:3 Data:[]} into buffer [0 0 0 0 0 0 0 3]
> 2017/05/11 22:28:47 [DEBUG] Tx packet dump:
>   00 00 00 00 00 00 00 03   ||
> 2017/05/11 22:28:47 [DEBUG] Write BLE Packet:buf:: len::8
> 2017/05/11 22:28:47 [DEBUG] Read BLE 
> Packet:buf::l?brcfmpools?fmsys_1?fblksiz$enblks
>   
>   enfreecmin?wble_hci_ram_evt_hi_pool?fblksizHenblkse len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
>   01 00 02 6c 00 00 00 03  bf 62 72 63 00 66 6d 70  |...l.brc.fmp|
> 0010  6f 6f 6c 73 bf 66 6d 73  79 73 5f 31 bf 66 62 6c  |ools.fmsys_1.fbl|
> 0020  6b 73 69 7a 19 01 24 65  6e 62 6c 6b 73 0c 65 6e  |ksiz..$enblks.en|
> 0030  66 72 65 65 09 63 6d 69  6e 00 ff 77 62 6c 65 5f  |free.cmin..wble_|
> 0040  68 63 69 5f 72 61 6d 5f  65 76 74 5f 68 69 5f 70  |hci_ram_evt_hi_p|
> 0050  6f 6f 6c bf 66 62 6c 6b  73 69 7a 18 48 65 6e 62  |ool.fblksiz.Henb|
> 0060  6c 6b 73 02 65|lks.e|
> 2017/05/11 22:28:47 [DEBUG] Deserialized response &{Op:1 Flags:0 Len:620 
> Group:0 Seq:0 Id:3 Data:[191 98 114 99 0 102 109 112 111 111 108 115 191 102 
> 109 115 121 115 95 49 191 102 98 108 107 115 105 122 25 1 36 101 110 98 108 
> 107 115 12 101 110 102 114 101 101 9 99 109 105 110 0 255 119 98 108 101 95 
> 104 99 105 95 114 97 109 95 101 118 116 95 104 105 95 112 111 111 108 191 102 
> 98 108 107 115 105 122 24 72 101 110 98 108 

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

[Christopher Collins (JIRA)]

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

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

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

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

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

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

[Christopher Collins (JIRA)]

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

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

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

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

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-772:
--

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


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

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



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

[jira] [Created] (MYNEWT-770) Sim - Share sig/no-sig implementation for all sim architectures

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-770:
--

 Summary: Sim - Share sig/no-sig implementation for all sim 
architectures
 Key: MYNEWT-770
 URL: https://issues.apache.org/jira/browse/MYNEWT-770
 Project: Mynewt
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


In MYNEWT-745, sim was split into two implementations:
* signals
* no-signals

The above change was applied to the i386 version of sim, but not to the other 
sim implementations (ARMv7 and MIPS).

This ticket is for extracting the signals and no-signals code into a standalone 
package that can be used by all sim implementations.



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

Re: segger jlink

[Christopher Collins]

Hi Pierre,

First, don't worry about asking a lot of questions.  There are probably
others with the same questions who will benefit from your asking them!

On Tue, May 30, 2017 at 04:32:20PM +0100, Pierre Kircher wrote:
[...]
> the breakpoint points on main.c 129 > apps/bleprph/src
> 
> Reading symbols from 
> /Users/pkircher/dev/puck/bin/targets/bleprph/app/apps/bleprph/bleprph.elf...
> done.
> os_tick_idle (ticks=595) at 
> repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_os_tick.c:200
> 200   if (ticks > 0) {
> Not implemented stop reason (assuming exception): undefined
> 
> never hits that breakpoint - is that a known issue ?

That is not a known issue.  My guess is that the API call immediately
before that point (ble_gap_adv_set_fields) is failing for some reason.
One common reason is that the app is trying to put too much data into
the advertisement.  For example, this happens if you are using a very
long name.  I would backtrack a bit; set a breakpoint on
bleprph_advertise() and see if your app gets there.

FYI, here is the expected sequence of events:
1. main()
2. bleprph_on_sync() (communication established among host and
   controller).
3. bleprph_advertise (called from bleprph_on_sync()).

Chris

Re: [VOTE] Graduation of podling Apache Mynewt to Top Level Project

[Christopher Collins]

+1

Chris

On Thu, May 25, 2017 at 05:55:26PM -0700, aditi hilbert wrote:
> Hi all,
> 
> We feel confident that we pass all the requirements to graduate.  Below is 
> the proposed Graduation Resolution (based on the standard template). A 
> separate thread of DISCUSS is also open for this.
> 
> The full text of the proposed resolution is as follows:
> 
> 
> The incubating Apache Mynewt community believes it is time to graduate to TLP.
> 
> Apache Mynewt entered incubation in October of 2015.  Since then, we've 
> overcome technical challenges and built Apache's first Operating System for 
> IoT devices, and made 6 releases.  Our most recent releases include NimBLE, 
> OIC1.1 support, MCUbootloader. We are a very helpful and engaged community, 
> ready to answer all questions and feedback directed to us via the user list.  
> We've added several committers from different organizations, and are actively 
> pursuing others. While we continue working on maturity, all projects are 
> ongoing processes, and we believe we no longer need the incubator to continue.
> 
> To inform the discussion, here is some basic project information:
> 
> Project status:
>   http://incubator.apache.org/projects/Mynewt.html
> 
> Project website:
>   http://Mynewt.incubator.apache.org/
> 
> Project documentation:
>  https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Project
> 
> Maturity assessment:
> https://cwiki.apache.org/confluence/display/MYNEWT/Maturity+model
> 
> DRAFT of the board resolution is at the bottom of this email
> 
> Proposed PMC size: 20 members
> 
> Total number of committers: 20 members
> 
> Various PMC/Committer affiliations (* indicated chair)
>Runtime (6)
>Google (1)
>Imagination Technologies (1)
>Codecoup (4)
>Adafruit (1)
> 
> 4,565 commits on develop
> 280 closed PR”s on GitHub
> 39 contributors across all branches
> 92 forks on Github
> 
> dev list averaged ~200 msgs/month in the last one year
> 
> 647 issues created
> 465 issues resolved/closed
>  
> --
> Resolution:
> 
> Establish the Apache Mynewt Project
> 
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to the
> public, related to a data management platform that provides
> real-time, consistent access to data-intensive applications
> throughout widely distributed cloud architectures.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Mynewt Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
> 
> RESOLVED, that the Apache Mynewt Project be and hereby is
> responsible for the creation and maintenance of software
> related to an embedded OS optimized for networking and built for remote 
> management of constrained devices that are incapable of running either Linux 
> or Android. 
> 
> RESOLVED, that the office of "Vice President, Apache Mynewt" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache Mynewt Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Mynewt Project; and be it further
> 
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Mynewt Project: 
> *Justin Mclean” <jmcl...@apache.org> 
> *P. Taylor Goetz” <ptgo...@apache.org>, 
> *Greg Stein <gst...@apache.org>, 
> *Jim Jagielski <j...@apache.org>, 
> *Sterling Hughes <sterl...@apache.org>, 
> *Marko Kiiskila <ma...@apache.org>, 
> *will sanfilippo <w...@apache.org>, 
> Christopher Collins <ccoll...@apache.org>, 
> Vipul Rahane <vipulrah...@apache.org>, 
> Fabio Utzig <ut...@apache.org>, 
> Andrzej Kaczmarek <a...@apache.org>, 
> Michał Narajowski <na...@apache.org>, 
> Szymon Janc <j...@apache.org>, 
> Łukasz Rymanowski <ry...@apache.org>, 
> Neel Natu <n...@apache.org>, 
> Peter Snyder <pete...@apache.org>, 
> Paul Dietrich <paulfdietr...@apache.org, 
> Julian Ingram <jul...@apache.org>, 
> Kevin Townsend <kt...@apache.org>,
> Aditi Hilbert <ad...@apache.org>
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Justin Mcclean
> be appointed to the office of Vice President, Apache M

[jira] [Comment Edited] (MYNEWT-765) os_mbuf memory corruption on native platform

[Christopher Collins (JIRA)]

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

Christopher Collins edited comment on MYNEWT-765 at 5/26/17 12:52 AM:
--

In addition, the double free issue 
(https://github.com/apache/incubator-mynewt-core/pull/292) was causing a 
problem.  After merging that PR, everything looks good to me.

I am going to merge the above PR now.  If you test this again, be sure to grab 
the latest from master.


was (Author: ccollins476):
Looks like I spoke too soon - I'm seeing another issue after letting it run for 
several minutes:
{noformat}
(gdb) p ble_hci_uart_acl_pool
$4 = {mp_block_size = 292, mp_num_blocks = 1000, mp_num_free = -1467022310, 
mp_min_free = 983, mp_membuf_addr = 1290240, mp_list = {stqe_next = 0xc0be0 
}, {slh_first = 0x13b248}, name = 0x3d0a1 
"ble_hci_uart_acl_pool"}
{noformat}

{{mp_num_free}} shouldn't be negative!  I am going to keep looking at this.  
Hopefully this and the memory corruption issue are related.

(The issues I mentioned in the above comment are still valid.)

> os_mbuf memory corruption on native platform
> 
>
> Key: MYNEWT-765
> URL: https://issues.apache.org/jira/browse/MYNEWT-765
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
> Environment: bsncent app on native 32-bit Ubuntu 17.04
>Reporter: Michał Narajowski
>Priority: Minor
>
> h4. General description:
> There is a segmentation fault error in function {{ble_hs_log_mbuf}} in file 
> {{net/nimble/host/src/ble_hs_log.c}} when receiving notifications at high 
> rate. Tested using *bsncent* app from 
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn and *bsnprph* also 
> from https://github.com/apache/incubator-mynewt-core/tree/bsnbranch
> Data from HCI command overwrites the os_mbuf struct instead of being written 
> to {{om->om_data}}. I tried to catch that memory violation earlier in code, 
> but somehow it is only triggered in the {{ble_hs_log_mbuf}} function.
> h4. How to reproduce:
> 1. Build and flash *bsnprph* app from 
> https://github.com/apache/incubator-mynewt-core/tree/bsnbranch with the 
> following configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsnprph
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> {quote}
> 2. Build *bsncent* app from 
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following 
> configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsncent
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
> {quote}
> 3. It is possible to reproduce it using Mynewt controller (but then another 
> issue shows up sometimes, described below) or some other controller like PTS 
> with some hacks in ble_hs_startup.c to start controller.
> 4. Run *bsncent* app from 32bit Ubuntu
> Here is the backtrace from GDB:
> {quote}
> Program received signal SIGSEGV, Segmentation fault.
> __memcpy_sse2_unaligned () at 
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> 651 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file 
> or directory.
> (gdb) bt
> #0  __memcpy_sse2_unaligned () at 
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> #1  0x80009fc0 in os_mbuf_copydata (m=0x8008fb6c, off=0, len=1, 
> dst=0x800746c7 <os_main_stack+32199>) at 
> repos/apache-mynewt-core/kernel/os/src/os_mbuf.c:722
> #2  0x8001fb5a in ble_hs_log_mbuf (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_log.c:32
> #3  0x8001f18c in ble_hs_hci_evt_acl_process (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_hci_evt.c:631
> #4  0x80018c1f in ble_hs_process_rx_data_queue ()
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:195
> #5  0x80019020 in ble_hs_event_data (ev=0x80075aec <ble_hs_rx_q+8>)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:379
> #6  0x80007009 in os_eventq_run (evq=0x80074908 )
> at repos/apache-mynewt-core/kernel/os/src/os_eventq.c:172
> #7  0x80002308 in main (argc=0, argv=0x0) at 
> repos/apache-mynewt-core/apps/bsncent/src/main.c:457
> {quote}
> h4. Another issue
> Actually, there is also a second problem. When using *blehci* as the 
> cont

[jira] [Comment Edited] (MYNEWT-765) os_mbuf memory corruption on native platform

[Christopher Collins (JIRA)]

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

Christopher Collins edited comment on MYNEWT-765 at 5/26/17 12:02 AM:
--

Looks like I spoke too soon - I'm seeing another issue after letting it run for 
several minutes:
{noformat}
(gdb) p ble_hci_uart_acl_pool
$4 = {mp_block_size = 292, mp_num_blocks = 1000, mp_num_free = -1467022310, 
mp_min_free = 983, mp_membuf_addr = 1290240, mp_list = {stqe_next = 0xc0be0 
}, {slh_first = 0x13b248}, name = 0x3d0a1 
"ble_hci_uart_acl_pool"}
{noformat}

{{mp_num_free}} shouldn't be negative!  I am going to keep looking at this.  
Hopefully this and the memory corruption issue are related.

(The issues I mentioned in the above comment are still valid.)


was (Author: ccollins476):
Looks like I spoke too soon - I'm seeing another issue after letting it run for 
several minutes:
```
(gdb) p ble_hci_uart_acl_pool
$4 = {mp_block_size = 292, mp_num_blocks = 1000, mp_num_free = -1467022310, 
mp_min_free = 983, mp_membuf_addr = 1290240, mp_list = {stqe_next = 0xc0be0 
}, {slh_first = 0x13b248}, name = 0x3d0a1 
"ble_hci_uart_acl_pool"}
```

`mp_num_free` shouldn't be negative!  I am going to keep looking at this.  
Hopefully this and the memory corruption issue are related.

(The issues I mentioned in the above comment are still valid.)

> os_mbuf memory corruption on native platform
> 
>
> Key: MYNEWT-765
> URL: https://issues.apache.org/jira/browse/MYNEWT-765
> Project: Mynewt
>  Issue Type: Bug
>  Security Level: Public(Viewable by anyone) 
> Environment: bsncent app on native 32-bit Ubuntu 17.04
>Reporter: Michał Narajowski
>Priority: Minor
>
> h4. General description:
> There is a segmentation fault error in function {{ble_hs_log_mbuf}} in file 
> {{net/nimble/host/src/ble_hs_log.c}} when receiving notifications at high 
> rate. Tested using *bsncent* app from 
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn and *bsnprph* also 
> from https://github.com/apache/incubator-mynewt-core/tree/bsnbranch
> Data from HCI command overwrites the os_mbuf struct instead of being written 
> to {{om->om_data}}. I tried to catch that memory violation earlier in code, 
> but somehow it is only triggered in the {{ble_hs_log_mbuf}} function.
> h4. How to reproduce:
> 1. Build and flash *bsnprph* app from 
> https://github.com/apache/incubator-mynewt-core/tree/bsnbranch with the 
> following configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsnprph
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> {quote}
> 2. Build *bsncent* app from 
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following 
> configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsncent
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
> {quote}
> 3. It is possible to reproduce it using Mynewt controller (but then another 
> issue shows up sometimes, described below) or some other controller like PTS 
> with some hacks in ble_hs_startup.c to start controller.
> 4. Run *bsncent* app from 32bit Ubuntu
> Here is the backtrace from GDB:
> {quote}
> Program received signal SIGSEGV, Segmentation fault.
> __memcpy_sse2_unaligned () at 
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> 651 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file 
> or directory.
> (gdb) bt
> #0  __memcpy_sse2_unaligned () at 
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> #1  0x80009fc0 in os_mbuf_copydata (m=0x8008fb6c, off=0, len=1, 
> dst=0x800746c7 <os_main_stack+32199>) at 
> repos/apache-mynewt-core/kernel/os/src/os_mbuf.c:722
> #2  0x8001fb5a in ble_hs_log_mbuf (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_log.c:32
> #3  0x8001f18c in ble_hs_hci_evt_acl_process (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_hci_evt.c:631
> #4  0x80018c1f in ble_hs_process_rx_data_queue ()
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:195
> #5  0x80019020 in ble_hs_event_data (ev=0x80075aec <ble_hs_rx_q+8>)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:379
> #6  0x80007009 in os_eventq_run (evq=0x80074908 )
&

[jira] [Comment Edited] (MYNEWT-765) os_mbuf memory corruption on native platform

[Christopher Collins (JIRA)]

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

Christopher Collins edited comment on MYNEWT-765 at 5/23/17 11:26 PM:
--

{quote}
2. Build bsncent app from 
https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following 
configuration:

app=@apache-mynewt-core/apps/bsncent
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug

syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
{quote}

MCU_NATIVE_USE_SIGNALS should probably be set to 0 here (not 1).  From 
{{hw/mcu/native/syscfg.yml}}:
{noformat}
MCU_NATIVE_USE_SIGNALS:
description: >
Whether to use POSIX signals to implement context switches.  Valid
values are as follows:
1: More correctness; less stability.  The OS tick timer will
   cause a high-priority task to preempt a low-priority task.
   This causes stability issues because a task can be preempted
   while it is in the middle of a system call, potentially
   causing deadlock or memory corruption.

0: Less correctness; more stability.  The OS tick timer only
   runs while the idle task is active.  Therefore, a sleeping
   high-priority task will not preempt a low-priority task due
   to a timing event (e.g., delay or callout expired).
   However, this version of sim does not suffer from the
   stability issues that affect the "signals" implementation.

Unit tests should use 1.  Long-running sim processes should use 0.
{noformat}

Setting this to 0 causes sim to use the new behavior implemented in 
{{9864f55e53df0b945fa3482d9b9ea63109c09123}}.

Hopefully this is the problem.  With this setting equal to 1, I have seen 
memory corruption like this (typically when mmap() or sbrk() gets longjmped out 
of (called via malloc()).


was (Author: ccollins476):
{quote}
2. Build bsncent app from 
https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following 
configuration:

app=@apache-mynewt-core/apps/bsncent
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug

syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
{quote}

MCU_NATIVE_USE_SIGNALS should probably be set to 0 here (not 1).  From 
{{hw/mcu/native/syscfg.yml}}:
{noformat}
MCU_NATIVE_USE_SIGNALS:
description: >
Whether to use POSIX signals to implement context switches.  Valid
values are as follows:
1: More correctness; less stability.  The OS tick timer will
   cause a high-priority task to preempt a low-priority task.
   This causes stability issues because a task can be preempted
   while it is in the middle of a system call, potentially
   causing deadlock or memory corruption.

0: Less correctness; more stability.  The OS tick timer only
   runs while the idle task is active.  Therefore, a sleeping
   high-priority task will not preempt a low-priority task due
   to a timing event (e.g., delay or callout expired).
   However, this version of sim does not suffer from the
   stability issues that affect the "signals" implementation.

Unit tests should use 1.  Long-running sim processes should use 0.
{noformat}

Setting this to 0 causes sim to use the new behavior implemented in 
{{9864f55e53df0b945fa3482d9b9ea63109c09123}}.

Hopefully this is the problem.  With this setting equal to 0, I have seen 
memory corruption like this (typically when mmap() or sbrk() gets longjmped out 
of (called via malloc()).

> os_mbuf memory corruption on native platform
> 
>
> Key: MYNEWT-765
> URL: https://issues.apache.org/jira/browse/MYNEWT-765
> Project: Mynewt
>  Issue Type: Bug
> Environment: bsncent app on native 32-bit Ubuntu 17.04
>Reporter: Michał Narajowski
>Priority: Minor
>
> h4. General description:
> There is a segmentation fault error in function {{ble_hs_log_mbuf}} in file 
&g

[jira] [Commented] (MYNEWT-765) os_mbuf memory corruption on native platform

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-765:


{quote}
2. Build bsncent app from 
https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following 
configuration:

app=@apache-mynewt-core/apps/bsncent
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug

syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
{quote}

MCU_NATIVE_USE_SIGNALS should probably be set to 0 here (not 1).  From 
{{hw/mcu/native/syscfg.yml}}:
{noformat}
MCU_NATIVE_USE_SIGNALS:
description: >
Whether to use POSIX signals to implement context switches.  Valid
values are as follows:
1: More correctness; less stability.  The OS tick timer will
   cause a high-priority task to preempt a low-priority task.
   This causes stability issues because a task can be preempted
   while it is in the middle of a system call, potentially
   causing deadlock or memory corruption.

0: Less correctness; more stability.  The OS tick timer only
   runs while the idle task is active.  Therefore, a sleeping
   high-priority task will not preempt a low-priority task due
   to a timing event (e.g., delay or callout expired).
   However, this version of sim does not suffer from the
   stability issues that affect the "signals" implementation.

Unit tests should use 1.  Long-running sim processes should use 0.
{noformat}

Setting this to 0 causes sim to use the new behavior implemented in 
{{9864f55e53df0b945fa3482d9b9ea63109c09123}}.

Hopefully this is the problem.  With this setting equal to 0, I have seen 
memory corruption like this (typically when mmap() or sbrk() gets longjmped out 
of (called via malloc()).

> os_mbuf memory corruption on native platform
> 
>
> Key: MYNEWT-765
> URL: https://issues.apache.org/jira/browse/MYNEWT-765
> Project: Mynewt
>  Issue Type: Bug
> Environment: bsncent app on native 32-bit Ubuntu 17.04
>Reporter: Michał Narajowski
>Priority: Minor
>
> h4. General description:
> There is a segmentation fault error in function {{ble_hs_log_mbuf}} in file 
> {{net/nimble/host/src/ble_hs_log.c}} when receiving notifications at high 
> rate. Tested using *bsncent* app from 
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn and *bsnprph* also 
> from https://github.com/apache/incubator-mynewt-core/tree/bsnbranch
> Data from HCI command overwrites the os_mbuf struct instead of being written 
> to {{om->om_data}}. I tried to catch that memory violation earlier in code, 
> but somehow it is only triggered in the {{ble_hs_log_mbuf}} function.
> h4. How to reproduce:
> 1. Build and flash *bsnprph* app from 
> https://github.com/apache/incubator-mynewt-core/tree/bsnbranch with the 
> following configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsnprph
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> {quote}
> 2. Build *bsncent* app from 
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following 
> configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsncent
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
> {quote}
> 3. It is possible to reproduce it using Mynewt controller (but then another 
> issue shows up sometimes, described below) or some other controller like PTS 
> with some hacks in ble_hs_startup.c to start controller.
> 4. Run *bsncent* app from 32bit Ubuntu
> Here is the backtrace from GDB:
> {quote}
> Program received signal SIGSEGV, Segmentation fault.
> __memcpy_sse2_unaligned () at 
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> 651 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file 
> or directory.
> (gdb) bt
> #0  __memcpy_sse2_unaligned () at 
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> #1  0x800

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-760:
--

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






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

[jira] [Updated] (MYNEWT-759) Change BLE-over-CoAP UUID from 128-bit to 16-bit

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-759:
---
Issue Type: Improvement  (was: Bug)

> Change BLE-over-CoAP UUID from 128-bit to 16-bit
> 
>
> Key: MYNEWT-759
> URL: https://issues.apache.org/jira/browse/MYNEWT-759
> Project: Mynewt
>  Issue Type: Improvement
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The plan is to reserve a 16-bit UUID with the Bluetooth SIG.  In the 
> meantime, we will use the (arbitrarilly chosen) UUID 0x9923.



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

[jira] [Created] (MYNEWT-759) Change BLE-over-CoAP UUID from 128-bit to 16-bit

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-759:
--

 Summary: Change BLE-over-CoAP UUID from 128-bit to 16-bit
 Key: MYNEWT-759
 URL: https://issues.apache.org/jira/browse/MYNEWT-759
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


The plan is to reserve a 16-bit UUID with the Bluetooth SIG.  In the meantime, 
we will use the (arbitrarilly chosen) UUID 0x9923.



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins reassigned MYNEWT-742:
--

Assignee: Christopher Collins

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



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

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-758:
--

 Summary: BLE Host - OOB security for SC
 Key: MYNEWT-758
 URL: https://issues.apache.org/jira/browse/MYNEWT-758
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
 Fix For: v1_1_0_rel






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

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

[Christopher Collins (JIRA)]

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

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

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


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

I propose the following behavior in such a scenario:
# Host notifies application of the duplicate pairing attempt via the gap event 
callback.  The callback would specify a new event code that specifically 
indicates a duplicate pairing attempt.
# The gap event callback would return an error code indicating which of the 
following behaviors to perform:
## Reject the pairing request.
## Delete the original bond and proceed with the pairing operation.

Summary: BLE Host - Ignore pairing attempt from already bonded peer  
(was: BLE Host - Reject pairing attempt from already bonded peer)

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



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins reassigned MYNEWT-750:
--

Assignee: Christopher Collins

> BLE Host - Reject pairing attempt from already bonded peer
> --
>
> Key: MYNEWT-750
> URL: https://issues.apache.org/jira/browse/MYNEWT-750
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> If a device is already bonded, the host should not allow the same device to 
> pair again.  Currently, the host blindly proceeds with the pairing operation. 
>  This should not be allowed because the second peer could be an imposter 
> masquerading as the original.
> I propose the following behavior in such a scenario:
> # Host notifies application of the duplicate pairing attempt via the gap 
> event callback.  The callback would specify a new event code that 
> specifically indicates a duplicate pairing attempt.
> # The gap event callback would return an error code indicating which of the 
> following behaviors to perform:
> ## Reject the pairing request.
> ## Delete the original bond and proceed with the pairing operation.



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

Re: Problems with erasing flash on nordic devices

[Christopher Collins]

On Tue, May 16, 2017 at 05:11:36PM -0700, Jacob Rosenthal wrote:
> Seems like it could go in flash_map?
> 
> Its also been requested to also have a function that detects if an area
> should be erased, based on it having any non 0xff bytes within.
> 
> Should that go there as well.

That is the same thing, isn't it?

> Whats a good method to loop through all bytes of a flash area?

Perhaps something like the following:

1. Allocate a buffer that is properly aligned to be accessed by an
unsigned int*.  It may take some testing to
determine a good size that balances speed and size efficiency; I would
start with 64 bytes.  I would also start by putting this buffer on the
stack.

2. Read a chunk of flash into the buffer
(min(size-of-buffer, num-unread-bytes).

3. Use an unsigned int* to iterate through the buffer.  If the pointer
points to something other than (unsigned int)-1, then the flash is not
erased.

4. If there are any remaining bytes (i.e., number of bytes read is not a
multiple of sizeof(unsigned int)), compare them individually against
0xff using a uint8_t*.

Chris

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-757:
--

 Summary: Inconsistent tags among newt, blinky, and core
 Key: MYNEWT-757
 URL: https://issues.apache.org/jira/browse/MYNEWT-757
 Project: Mynewt
  Issue Type: Bug
  Components: Newt
Reporter: Christopher Collins
Assignee: Sterling Hughes
 Fix For: v1_1_0_rel


* "newt install" should download the corresponding version of blinky.
* Blinky's project.yml should specify the corresponding version of core.

Currently, the versions don't match up properly:
* In master: newt specifies blinky's develop tag
* In develop: blinky's project.yml specifies core's 1-latest tag.



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

Re: Problems with erasing flash on nordic devices

[Christopher Collins]

Hi Jacob,

On Mon, May 15, 2017 at 02:51:35PM -0700, Jacob Rosenthal wrote:
> So Ill duplicate the upload command to an erase command.
> 
> Is there a bit of metadata I could check to see if a slot was filled and
> erase was necessary? If so I could conditionally erase in the upload
> command still, for backwards compat reasons.

No, I'm afraid there is no way to distinguish an empty slot from a
partially written one.  We would need to add a new newtmgr command for
that (or add an option to "image list").

Just to be clear, there also isn't an erase command at the moment.  This
still needs to be added.

Chris

[jira] [Resolved] (MYNEWT-753) newt - generated sysinit file inconsistent

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-753.

Resolution: Fixed

> newt - generated sysinit file inconsistent
> --
>
> Key: MYNEWT-753
> URL: https://issues.apache.org/jira/browse/MYNEWT-753
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> In the generated sysinit C file, calls to initialization functions are sorted 
> by stage number.  Within a stage number, the ordering is random, and varies 
> from one build to the next.  The randomness comes from Golang's random 
> iteration of maps.
> This is bad because it prevents repeatable builds, and causes unnecessary 
> rebuilds.
> The fix is to sort alphabetically by package name within a stage number. So,
> * First sort by stage number
> * Then sort by package name. 



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

[jira] [Resolved] (MYNEWT-745) Sim - deadlock involving system calls

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-745.

Resolution: Fixed

> Sim - deadlock involving system calls
> -
>
> Key: MYNEWT-745
> URL: https://issues.apache.org/jira/browse/MYNEWT-745
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
> Attachments: main.c
>
>
> The problem appears to occur when a system call is interrupted by a sim 
> context switch.  Because a sim context switch is implemented as a signal 
> handler that never returns (it calls longjmp()), the system call is left 
> unfinished.  In some cases, it seems the system call acquired some resources 
> that it never got a chance to release, leading to deadlock on a subsequent 
> system call. For whatever reason, when the original system call is resumed 
> (i.e., when Mynewt switch back to the original task), the syscall is unable 
> to recover.
> In sim, a context switch is triggered by delivery of a SIGURG signal. A few 
> events generate this signal:
> # A task calls an OS function with the potential to switch tasks (e.g., 
> os_eventq_get(), os_mutex_release(), etc.).
> # An OS tick occurs.
> The problem appears to occur when an OS tick generates the SIGURG signal.  
> The OS ticker is implemented via an itimer, which generates the SIG_ALRM 
> signal on each tick.  The SIG_ALRM handler advances the OS time, and then 
> calls os_sched(), potentially generating a SIGURG signal.  If the current 
> task happened to be in the middle of a syscall when the tick timer expired, 
> the SIGURG signal gets handled before the syscall returns.
> Here is a stack trace showing a context switch in the middle of a system call:
> {noformat}
> (gdb) whe
> #0  0x0804a3bd in ctxsw_handler (sig=23)
> at kernel/os/src/arch/sim/os_arch_sim.c:150
> #1  
> #2  0xf7ffdbe7 in __kernel_vsyscall ()
> #3  0x08097630 in __lll_lock_wait_private ()
> #4  0x080923b0 in __tz_convert ()
> #5  0x08091673 in localtime ()
> #6  0x0809162c in ctime ()
> #7  0x08048a5a in task1_handler (arg=0x0) at apps/slinky/src/main.c:162
> #8  0x0804a2c8 in os_arch_task_start (sf=0x8160314, rc=1)
> at kernel/os/src/arch/sim/os_arch_sim.c:88
> #9  0x0804ad90 in os_arch_frame_init ()
> at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
> #10 0x0804ad90 in os_arch_frame_init ()
> at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
> {noformat}
> Attached is a simple Mynewt app that can be used to replicate this issue 
> (main.c).



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

Re: Reducing GATT write attribute's timeout and read attribute's BLE_HS_ENOMEM

[Christopher Collins]

On Mon, May 15, 2017 at 11:01:38AM -0700, Christopher Collins wrote:
> Hi Łukasz,
> 
> On Mon, May 15, 2017 at 12:33:59PM +0100, Łukasz Wolnik wrote:
> > Hello,
> > 
> > From time to time my ble_gattc_write_flat (run as central) is timing out
> > after 20 seconds while sending to an Android 6 phone (in peripherial mode).
> > Is there a way to reduce the timeout to just 1 second? At the moment if
> > there's an issue with writing, my newt program has to wait 20 seconds until
> > it can respond to a timeout.
> > 
> > What's the best strategy here? Keep "bombarding" the peripherial with
> > multiple writes until receiving first confirmation. Or reduce the timeout
> > from 20 seconds (I don't know where this value is coming from) and resend
> > only when got an HCI 19 timeout error in the callback?

Oops, I forgot to respond to your actual question :).  Sorry about that.
The 30-second timeout is hardcoded in the spec, and is currently not
configurable (Vol. 3, Part F, 3.3.3).  It might be useful to make this
configurable, but the device would not be standards compliant.

Chris

Re: Reducing GATT write attribute's timeout and read attribute's BLE_HS_ENOMEM

[Christopher Collins]

Hi Łukasz,

On Mon, May 15, 2017 at 12:33:59PM +0100, Łukasz Wolnik wrote:
> Hello,
> 
> From time to time my ble_gattc_write_flat (run as central) is timing out
> after 20 seconds while sending to an Android 6 phone (in peripherial mode).
> Is there a way to reduce the timeout to just 1 second? At the moment if
> there's an issue with writing, my newt program has to wait 20 seconds until
> it can respond to a timeout.
> 
> What's the best strategy here? Keep "bombarding" the peripherial with
> multiple writes until receiving first confirmation. Or reduce the timeout
> from 20 seconds (I don't know where this value is coming from) and resend
> only when got an HCI 19 timeout error in the callback?

The lower layers should ensure all packets are delivered, so the
application should not perform any retries.  In fact, once an ATT
exchange times out, the connection is terminated.

I think the problem is the resource exhaustion, as indicated by the
BLE_HS_ENOMEM codes you are seeing.  This particular error code is,
unfortunately, quite general; it applies to several different resource
types.  Since your device is initiating several GATT procedures in
parallel, my guess is that the problematic resource is one of the
following:

* mbufs
* GATT client procedure objects

If you have gdb attached to your device, you can check if either of
these is the problem.  Let me know if you are interested in this.

I would recommend just increasing the following setting and seeing what
happens:

MSYS_1_BLOCK_COUNT  # default: 12
BLE_GATT_MAX_PROCS  # default: 4

As an aside, this issue tells me two things:
1. We need to make sure there are statistics available that indicate
   failure to allocate each resource type.
2. We should log the exact cause of failure when a procedure fails.

Chris

> My logs are below:
> 
> * CONNECTED 3 *
> 007034 [ts=54953064ssb, mod=64 level=1] peer's connection handle;
> conn_handle=3; addr=2000719b; attr_read=0 attr_write=0
> 007037 [ts=54976500ssb, mod=4 level=1] GATT procedure initiated: write;
> att_handle=42 len=4
> 007039 [ts=54992124ssb, mod=4 level=1] GAP procedure initiated: discovery;
> own_addr_type=0 filter_policy=0 passive=1 limited=0 filter_duplicates=0
> duration=forever
> 007059 [ts=55148428ssb, mod=64 level=1] wb_on_write msg=5, err=0
> 007060 [ts=55156240ssb, mod=64 level=1] Error: Failed to read
> characteristic; rc=6
> 
> 
> Again sometimes I'm getting BLE_HS_ENOMEM error while trying to read
> attribute from a different handle than the write one.
> 
> My syscfg.yml:
> 
> LOG_LEVEL: 1
> UART_0: 1
> 
> # Default task settings
> OS_MAIN_STACK_SIZE: 512
> 
> # BLE settings
> BLE_MAX_CONNECTIONS: 4
> 
> # Make BLE more stable
> BLE_LL_CFG_FEAT_DATA_LEN_EXT: 0
> 
> BLE_GATT_READ_MAX_ATTRS: 2
> BLE_GATT_WRITE_MAX_ATTRS: 2
> 
> I have tried reducing OS_MAIN_STACK_SIZE to 384, also tried with
> BLE_MAX_CONNECTIONS to 3, etc. This read BLE_HS_ENOMEM seems to pop up in a
> random manner.
> 
> Is there a way to check how much of device's RAM has been already used
> (nrf52xx)?
> 
> Kind regards,
> Łukasz

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

[Christopher Collins (JIRA)]

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

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

I propose the following behavior in such a scenario:

# Host checks that there is sufficient storage for a bond before it starts a 
pairing operation.
# If there is insufficient space, host notifies application of the issue via a 
callback.
# The callback would return an error code indicating which of the following 
behaviors to perform:
## Reject the pairing request.
## Proceed with the pairing operation (presumably the application would delete 
a security entry to make room before returning from the callback).

This raises two issues:
# The pre-check for sufficient storage only works if pairing operations are 
limited to one at a time.  Perhaps the check could include pairing operations 
in progress in the count of written entries.
# There isn't an API for the management of persisted security material.  The 
application would probably need the following functions:
** query the system about which bonds are persisted.
** delete a specified bond from persistence.

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

I propose the following behavior in such a scenario:

# Host checks that there is sufficient storage for a bond before it starts a 
pairing operation.
# If there is insufficient space, host notifies application of the issue via 
the gap event callback. The callback would specify a new event code that 
specifically indicates security storage exhaustion.
# The gap event callback would return an error code indicating which of the 
following behaviors to perform:
## Reject the pairing request.
## Proceed with the pairing operation (presumably the application would delete 
a security entry to make room before returning from the callback).

This raises two issues:
# The pre-check for sufficient storage only works if pairing operations are 
limited to one at a time.  Perhaps the check could include pairing operations 
in progress in the count of written entries.
# There isn't an API for the management of persisted security material.  The 
application would probably need the following functions:
** query the system about which bonds are persisted.
** delete a specified bond from persistence.


> BLE Host - Policy for SM key overflow
> -
>
> Key: MYNEWT-751
> URL: https://issues.apache.org/jira/browse/MYNEWT-751
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The BLE host needs a way to handle the case where a security store write 
> fails because the maximum number of entries have already been written.  
> Currently, the host simply fails to persist the record and returns an error 
> code.
> I propose the following behavior in such a scenario:
> # Host checks that there is sufficient storage for a bond before it starts a 
> pairing operation.
> # If there is insufficient space, host notifies application of the issue via 
> a callback.
> # The callback would return an error code indicating which of the following 
> behaviors to perform:
> ## Reject the pairing request.
> ## Proceed with the pairing operation (presumably the application would 
> delete a security entry to make room before returning from the callback).
> This raises two issues:
> # The pre-check for sufficient storage only works if pairing operations are 
> limited to one at a time.  Perhaps the check could include pairing operations 
> in progress in the count of written entries.
> # There isn't an API for the management of persisted security material.  The 
> application would probably need the following functions:
> ** query the system about which bonds are persisted.
> ** delete a specified bond from persistence.



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-754:
---
Component/s: Nimble

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



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

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

[Christopher Collins (JIRA)]

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

Christopher Collins reassigned MYNEWT-751:
--

Assignee: Christopher Collins

> BLE Host - Policy for SM key overflow
> -
>
> Key: MYNEWT-751
> URL: https://issues.apache.org/jira/browse/MYNEWT-751
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The BLE host needs a way to handle the case where a security store write 
> fails because the maximum number of entries have already been written.  
> Currently, the host simply fails to persist the record and returns an error 
> code.
> I propose the following behavior in such a scenario:
> # Host checks that there is sufficient storage for a bond before it starts a 
> pairing operation.
> # If there is insufficient space, host notifies application of the issue via 
> the gap event callback. The callback would specify a new event code that 
> specifically indicates security storage exhaustion.
> # The gap event callback would return an error code indicating which of the 
> following behaviors to perform:
> ## Reject the pairing request.
> ## Proceed with the pairing operation (presumably the application would 
> delete a security entry to make room before returning from the callback).
> This raises two issues:
> # The pre-check for sufficient storage only works if pairing operations are 
> limited to one at a time.  Perhaps the check could include pairing operations 
> in progress in the count of written entries.
> # There isn't an API for the management of persisted security material.  The 
> application would probably need the following functions:
> ** query the system about which bonds are persisted.
> ** delete a specified bond from persistence.



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

[jira] [Created] (MYNEWT-753) newt - generated sysinit file inconsistent

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-753:
--

 Summary: newt - generated sysinit file inconsistent
 Key: MYNEWT-753
 URL: https://issues.apache.org/jira/browse/MYNEWT-753
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


In the generated sysinit C file, calls to initialization functions are sorted 
by stage number.  Within a stage number, the ordering is random, and varies 
from one build to the next.  The randomness comes from Golang's random 
iteration of maps.

This is bad because it prevents repeatable builds, and causes unnecessary 
rebuilds.

The fix is to sort alphabetically by package name within a stage number. So,
* First sort by stage number
* Then sort by package name. 



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

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-751:
--

 Summary: BLE Host - Policy for SM key overflow
 Key: MYNEWT-751
 URL: https://issues.apache.org/jira/browse/MYNEWT-751
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
 Fix For: v1_1_0_rel


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

I propose the following behavior in such a scenario:

# Host checks that there is sufficient storage for a bond before it starts a 
pairing operation.
# If there is insufficient space, host notifies application of the issue via 
the gap event callback. The callback would specify a new event code that 
specifically indicates security storage exhaustion.
# The gap event callback would return an error code indicating which of the 
following behaviors to perform:
## Reject the pairing request.
## Proceed with the pairing operation (presumably the application would delete 
a security entry to make room before returning from the callback).

This raises two issues:
# The pre-check for sufficient storage only works if pairing operations are 
limited to one at a time.  Perhaps the check could include pairing operations 
in progress in the count of written entries.
# There isn't an API for the management of persisted security material.  The 
application would probably need the following functions:
** query the system about which bonds are persisted.
** delete a specified bond from persistence.



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

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-750:
--

 Summary: BLE Host - Reject pairing attempt from already bonded peer
 Key: MYNEWT-750
 URL: https://issues.apache.org/jira/browse/MYNEWT-750
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
 Fix For: v1_1_0_rel


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

I propose the following behavior in such a scenario:
# Host notifies application of the duplicate pairing attempt via the gap event 
callback.  The callback would specify a new event code that specifically 
indicates a duplicate pairing attempt.
# The gap event callback would return an error code indicating which of the 
following behaviors to perform:
## Reject the pairing request.
## Delete the original bond and proceed with the pairing operation.



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

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-749:
--

 Summary: BLE Host - Crash during key persistence if key-dist 
settings are 0
 Key: MYNEWT-749
 URL: https://issues.apache.org/jira/browse/MYNEWT-749
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins


If BLE_SM_BONDING is enabled, but one of the the following settings is 0:
* BLE_SM_OUR_KEY_DIST
* BLE_SM_THEIR_KEY_DIST

then Mynewt crashes when pairing completes.  Here is an example stack trace:

{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0, 
e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0  __assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0, 
e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1  0x000181f8 in ble_store_persist_sec (obj_type=, 
value_sec=) at net/nimble/host/src/ble_store.c:92
#2  0x000177ca in ble_sm_persist_keys (proc=0x181f9 <ble_store_persist_sec+20>) 
at net/nimble/host/src/ble_sm.c:565
#3  ble_sm_process_result (conn_handle=conn_handle@entry=1, 
res=res@entry=0x2000165c <os_main_stack+3968>) at 
net/nimble/host/src/ble_sm.c:860
#4  0x0001792c in ble_sm_enc_event_rx (conn_handle=, 
evt_status=, encrypted=1) at net/nimble/host/src/ble_sm.c:1042
#5  0x00017942 in ble_sm_enc_change_rx (evt=evt@entry=0x20001698 
<os_main_stack+4028>) at net/nimble/host/src/ble_sm.c:1051
#6  0x000153be in ble_hs_hci_evt_encrypt_change (event_code=, 
data=0x20004c20 "\b\004", len=) at 
net/nimble/host/src/ble_hs_hci_evt.c:163
#7  0x00015438 in ble_hs_hci_evt_process (data=0x20004c20 "\b\004") at 
net/nimble/host/src/ble_hs_hci_evt.c:593
#8  0x9016 in os_eventq_run (evq=) at 
kernel/os/src/os_eventq.c:172
#9  0x879e in main () at apps/bleprph/src/main.c:301
{noformat}



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

Re: Subscribing to peer notifications

[Christopher Collins]

Hi Simon,

On Wed, May 10, 2017 at 12:47:43PM -0700, Simon Ratner wrote:
> Hi dev list,
> 
> I may be completely missing this, but is there a gattc API for subscribing
> to notifications on a NOTIFY characteristic exposed by a peer peripheral?
> 
> Cheers,
> simon

You subscribe by writing a special value to the characteristic's CCCD:
* notifications:0x01:0x00
* indications:  0x02:0x00

You can do this via ble_gattc_write() (or more conveniently,
ble_gattc_write_flat()).  For an example of how this is done, see the
blecent_read_write_subscribe() function in apps/blecent/src/main.c.

The host API could probably benefit from a few convenience functions
here.

Chris

[jira] [Assigned] (MYNEWT-745) Sim - deadlock involving system calls

[Christopher Collins (JIRA)]

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

Christopher Collins reassigned MYNEWT-745:
--

Assignee: Christopher Collins

> Sim - deadlock involving system calls
> -
>
> Key: MYNEWT-745
> URL: https://issues.apache.org/jira/browse/MYNEWT-745
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
> Attachments: main.c
>
>
> The problem appears to occur when a system call is interrupted by a sim 
> context switch.  Because a sim context switch is implemented as a signal 
> handler that never returns (it calls longjmp()), the system call is left 
> unfinished.  In some cases, it seems the system call acquired some resources 
> that it never got a chance to release, leading to deadlock on a subsequent 
> system call. For whatever reason, when the original system call is resumed 
> (i.e., when Mynewt switch back to the original task), the syscall is unable 
> to recover.
> In sim, a context switch is triggered by delivery of a SIGURG signal. A few 
> events generate this signal:
> # A task calls an OS function with the potential to switch tasks (e.g., 
> os_eventq_get(), os_mutex_release(), etc.).
> # An OS tick occurs.
> The problem appears to occur when an OS tick generates the SIGURG signal.  
> The OS ticker is implemented via an itimer, which generates the SIG_ALRM 
> signal on each tick.  The SIG_ALRM handler advances the OS time, and then 
> calls os_sched(), potentially generating a SIGURG signal.  If the current 
> task happened to be in the middle of a syscall when the tick timer expired, 
> the SIGURG signal gets handled before the syscall returns.
> Here is a stack trace showing a context switch in the middle of a system call:
> {noformat}
> (gdb) whe
> #0  0x0804a3bd in ctxsw_handler (sig=23)
> at kernel/os/src/arch/sim/os_arch_sim.c:150
> #1  
> #2  0xf7ffdbe7 in __kernel_vsyscall ()
> #3  0x08097630 in __lll_lock_wait_private ()
> #4  0x080923b0 in __tz_convert ()
> #5  0x08091673 in localtime ()
> #6  0x0809162c in ctime ()
> #7  0x08048a5a in task1_handler (arg=0x0) at apps/slinky/src/main.c:162
> #8  0x0804a2c8 in os_arch_task_start (sf=0x8160314, rc=1)
> at kernel/os/src/arch/sim/os_arch_sim.c:88
> #9  0x0804ad90 in os_arch_frame_init ()
> at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
> #10 0x0804ad90 in os_arch_frame_init ()
> at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
> {noformat}
> Attached is a simple Mynewt app that can be used to replicate this issue 
> (main.c).



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

[jira] [Updated] (MYNEWT-745) Sim - deadlock involving system calls

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-745:
---
Description: 
The problem appears to occur when a system call is interrupted by a sim context 
switch.  Because a sim context switch is implemented as a signal handler that 
never returns (it calls longjmp()), the system call is left unfinished.  In 
some cases, it seems the system call acquired some resources that it never got 
a chance to release, leading to deadlock on a subsequent system call. For 
whatever reason, when the original system call is resumed (i.e., when Mynewt 
switch back to the original task), the syscall is unable to recover.

In sim, a context switch is triggered by delivery of a SIGURG signal. A few 
events generate this signal:
# A task calls an OS function with the potential to switch tasks (e.g., 
os_eventq_get(), os_mutex_release(), etc.).
# An OS tick occurs.

The problem appears to occur when an OS tick generates the SIGURG signal.  The 
OS ticker is implemented via an itimer, which generates the SIG_ALRM signal on 
each tick.  The SIG_ALRM handler advances the OS time, and then calls 
os_sched(), potentially generating a SIGURG signal.  If the current task 
happened to be in the middle of a syscall when the tick timer expired, the 
SIGURG signal gets handled before the syscall returns.

Here is a stack trace showing a context switch in the middle of a system call:

{noformat}
(gdb) whe
#0  0x0804a3bd in ctxsw_handler (sig=23)
at kernel/os/src/arch/sim/os_arch_sim.c:150
#1  
#2  0xf7ffdbe7 in __kernel_vsyscall ()
#3  0x08097630 in __lll_lock_wait_private ()
#4  0x080923b0 in __tz_convert ()
#5  0x08091673 in localtime ()
#6  0x0809162c in ctime ()
#7  0x08048a5a in task1_handler (arg=0x0) at apps/slinky/src/main.c:162
#8  0x0804a2c8 in os_arch_task_start (sf=0x8160314, rc=1)
at kernel/os/src/arch/sim/os_arch_sim.c:88
#9  0x0804ad90 in os_arch_frame_init ()
at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
#10 0x0804ad90 in os_arch_frame_init ()
at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
{noformat}

Attached is a simple Mynewt app that can be used to replicate this issue 
(main.c).

  was:
The problem appears to occur when a system call is interrupted by a sim context 
switch.  Because a sim context switch is implemented as a signal handler that 
never returns (it calls longjmp()), the system call is left unfinished.  In 
some cases, it seems the system call acquired some resources that it never got 
a chance to release, leading to deadlock on a subsequent system call.

Sim has protections in place to prevent this problem from happening.  
Specifically, a context switch is triggered by delivery of a SIGURG signal, and 
SIGURG is only sent from within the SIGALARM signal handler.  These handlers 
are configured such that all signals are blocked until the handlers complete (I 
am not sure how this works for the SIGURG handler, considering it never 
returns).

My initial guess was that a pending SIGURG signal does not get delivered as 
soon as it is unblocked at the end of the SIGALARM handler.  However, a simple 
test using sigpending() and sleep prove that this is not the case.

Here is a stack trace showing a context switch in the middle of a system call:

{noformat}
(gdb) whe
#0  0x0804a3bd in ctxsw_handler (sig=23)
at kernel/os/src/arch/sim/os_arch_sim.c:150
#1  
#2  0xf7ffdbe7 in __kernel_vsyscall ()
#3  0x08097630 in __lll_lock_wait_private ()
#4  0x080923b0 in __tz_convert ()
#5  0x08091673 in localtime ()
#6  0x0809162c in ctime ()
#7  0x08048a5a in task1_handler (arg=0x0) at apps/slinky/src/main.c:162
#8  0x0804a2c8 in os_arch_task_start (sf=0x8160314, rc=1)
at kernel/os/src/arch/sim/os_arch_sim.c:88
#9  0x0804ad90 in os_arch_frame_init ()
at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
#10 0x0804ad90 in os_arch_frame_init ()
at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
{noformat}

Attached is a simple Mynewt app that can be used to replicate this issue 
(main.c).


> Sim - deadlock involving system calls
> -
>
> Key: MYNEWT-745
> URL: https://issues.apache.org/jira/browse/MYNEWT-745
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
> Fix For: v1_1_0_rel
>
> Attachments: main.c
>
>
> The problem appears to occur when a system call is interrupted by a sim 
> context switch.  Because a sim context switch is implemented as a signal 
> handler that never returns (it calls longjmp()), the system call is left 
> unfinished.  In some cases, it seems the system call acquired some resources 
> that it never got a chance to release, leading to deadlock on a subsequent 
> system call. For whatever reason, when the original

Re: Problems with erasing flash on nordic devices

[Christopher Collins]

On Fri, May 05, 2017 at 05:58:52PM -0700, Jacob Rosenthal wrote:
> Thats basically what Im saying. Though  if you just do #2 I wont need a
> separate erase command. It'll erase and disconnect the first time, but not
> the second time. Ill get an erase command for free.

I don't think that will work without some more intelligence in the image
upload command handler.  Here is the typical sequence of events:

1. Image upload (offset=0) command received.
2. Command handler erases second image slot.
3. BLE connection drops during erase.
4. Command handler writes first part of image to beginning of second
   slot.

If you try to reconnect and upload again, the firmware will need to
erase the second slot once again, as the first image part has already
been written.  By separating the flash erase from the write, you can
ensure the slot is empty before starting the upload.

The extra "intelligence" I mentioned would be the command handler
comparing the flash contents against the data contained in the upload
request.  If the contents are identical, the firmware could skip the
erase and act like it just wrote the image segment (or indicate to the
client that it should resume the upgrade at a particular offset).

Chris

Re: Question about BLE GATT Services

[Christopher Collins]

On Wed, May 03, 2017 at 12:10:28PM -0700, Christopher Collins wrote:
> On Wed, May 03, 2017 at 10:59:59AM -0700, Pritish Gandhi wrote:
> > Hi All,
> > Just wanted to give an update to the community on the status of trying to
> > start the GATT server after the OS is initialized.
> > 
> > to ble_hs.c
> > @@ -606,5 +603,7 @@ ble_hs_init(void)
> >  /* Configure the HCI transport to communicate with a host. */
> >  ble_hci_trans_cfg_hs(ble_hs_hci_rx_evt, NULL, ble_hs_rx_data, NULL);
> > 
> > +#if 0 /* Let the Application set the queue and start the BLE stack */
> >  ble_hs_evq_set(os_eventq_dflt_get());
> > +#endif
> >  }
> 
> Is there a particular reason you removed the call to ble_hs_evq_set(),
> rather than the call to ble_hs_start()?  I think it is preferable to
> keep ble_hs_evq_set() here, and just hold off on starting the host.  If
> some other package tries to use the host before its eventq is set, it
> will result in a null pointer dereference.
> 
> > Then, I just have to call ble_hs_evq_set() with my ble thread's queue after
> > registering my GATT services.
> > 
> > The next thing I need to figure out though, is how to remove registered
> > GATT services and add new ones after the GATT server has started.
> > I think ble_hs_sched_reset() might work, if I move its function definition
> > from src/ble_hs_priv.h to include/ble_hs.h.
> > I haven't tried this out yet though. Will get to it soon.
> 
> Unfortunately, I don't think ble_hs_sched_reset() will work here.  That
> function just resets the controller and connection / procedure lists,
> but it does not have any effect on the registered GATT services.]
> 
> I haven't tried it, but I think the following sequence should do the
> trick:
> 
> 1. Register your new services with ble_gatts_add_svcs().
> 2. Call ble_gatts_start()
> 
> ble_gatts_start() should already get called at startup as soon as the
> host starts.  When this happens, the registered services get exposed to
> BLE peers, and the "working set" of services is cleared.  This is why
> you can just start adding new services in step 1; the working set has
> been cleared, so you are starting from scratch.  When you call
> ble_gatts_start() in step 2, the previously-exported services get
> replaced with the new ones.

Actually, there is one more thing that you'll need to do here: set
ble_gatts_num_cfgable_chrs to 0.  This is a static variable, so you'll
need to hack the code a bit to get access to it.  So the sequence should be:

1. ble_gatts_num_cfgable_chrs = 0;
2. Register your new services with ble_gatts_add_svcs().
3. Call ble_gatts_start()

Without this step, the GATT server will try to allocate too many CCCD
entries, which could cause the ble_gatts_start() call to fail.

Chris

Re: Question about BLE GATT Services

[Christopher Collins]

On Wed, May 03, 2017 at 10:59:59AM -0700, Pritish Gandhi wrote:
> Hi All,
> Just wanted to give an update to the community on the status of trying to
> start the GATT server after the OS is initialized.
> 
> to ble_hs.c
> @@ -606,5 +603,7 @@ ble_hs_init(void)
>  /* Configure the HCI transport to communicate with a host. */
>  ble_hci_trans_cfg_hs(ble_hs_hci_rx_evt, NULL, ble_hs_rx_data, NULL);
> 
> +#if 0 /* Let the Application set the queue and start the BLE stack */
>  ble_hs_evq_set(os_eventq_dflt_get());
> +#endif
>  }

Is there a particular reason you removed the call to ble_hs_evq_set(),
rather than the call to ble_hs_start()?  I think it is preferable to
keep ble_hs_evq_set() here, and just hold off on starting the host.  If
some other package tries to use the host before its eventq is set, it
will result in a null pointer dereference.

> Then, I just have to call ble_hs_evq_set() with my ble thread's queue after
> registering my GATT services.
> 
> The next thing I need to figure out though, is how to remove registered
> GATT services and add new ones after the GATT server has started.
> I think ble_hs_sched_reset() might work, if I move its function definition
> from src/ble_hs_priv.h to include/ble_hs.h.
> I haven't tried this out yet though. Will get to it soon.

Unfortunately, I don't think ble_hs_sched_reset() will work here.  That
function just resets the controller and connection / procedure lists,
but it does not have any effect on the registered GATT services.]

I haven't tried it, but I think the following sequence should do the
trick:

1. Register your new services with ble_gatts_add_svcs().
2. Call ble_gatts_start()

ble_gatts_start() should already get called at startup as soon as the
host starts.  When this happens, the registered services get exposed to
BLE peers, and the "working set" of services is cleared.  This is why
you can just start adding new services in step 1; the working set has
been cleared, so you are starting from scratch.  When you call
ble_gatts_start() in step 2, the previously-exported services get
replaced with the new ones.

Chris

Re: Config & FS command not working on newtmgr

[Christopher Collins]

On Sat, Apr 29, 2017 at 01:41:55AM +, Lm Chew wrote:
> Hi Chris,
> 
> 
> Ops... i did missed the FS_NMGR config, thanks.
> 
> 
> Now the FS command works for download.
> 
> 
> When i try to upload the same file back it just got stuck at "Reading from 
> data channel" as shown in the log below.
> 
> 
> newtmgr -c myserial fs upload test.txt /cfg/test.txt -ldebug
> 
> >>>
> 2017/04/29 09:31:51 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:7 
> Group:0 Seq:0 Id:1 Data:[161 100 101 99 104 111 0]}
> 2017/04/29 09:31:51 [DEBUG] Serializing request &{Op:2 Flags:0 Len:7 Group:0 
> Seq:0 Id:1 Data:[161 100 101 99 104 111 0]} into buffer [2 0 0 7 0 0 0 1 161 
> 100 101 99 104 111 0]
> 2017/04/29 09:31:51 [DEBUG] Tx packet dump:
>   02 00 00 07 00 00 00 01  a1 64 65 63 68 6f 00 |.decho.|
> 
> 2017/04/29 09:31:51 [DEBUG] Writing [6 9] to data channel
> 2017/04/29 09:31:51 [DEBUG] Writing [65 66 69 67 65 65 65 72 65 65 65 65 65 
> 97 70 107 90 87 78 111 98 119 68 51 122 81 61 61] to data channel
> 2017/04/29 09:31:51 [DEBUG] Writing [10] to data channel
> 2017/04/29 09:31:51 [DEBUG] Reading [] from data channel
> 2017/04/29 09:31:51 [DEBUG] Reading [6 9 65 65 119 68 65 65 65 67 65 65 65 65 
> 65 98 47 47 57 116 56 61] from data channel
> 2017/04/29 09:31:51 [DEBUG] Rx packet dump:
>   03 00 00 02 00 00 00 01  bf ff|..|
> 
> 2017/04/29 09:31:51 [DEBUG] Deserialized response &{Op:3 Flags:0 Len:2 
> Group:0 Seq:0 Id:1 Data:[191 255]}
> 2017/04/29 09:31:51 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:39 
> Group:8 Seq:0 Id:0 Data:[164 100 100 97 116 97 67 49 50 51 99 108 101 110 22 
> 100 110 97 109 101 109 47 99 102 103 47 116 101 115 116 46 116 120 116 99 111 
> 102 102 0]}
> 2017/04/29 09:31:51 [DEBUG] Serializing request &{Op:2 Flags:0 Len:39 Group:8 
> Seq:0 Id:0 Data:[164 100 100 97 116 97 67 49 50 51 99 108 101 110 22 100 110 
> 97 109 101 109 47 99 102 103 47 116 101 115 116 46 116 120 116 99 111 102 102 
> 0]} into buffer [2 0 0 39 0 8 0 0 164 100 100 97 116 97 67 49 50 51 99 108 
> 101 110 22 100 110 97 109 101 109 47 99 102 103 47 116 101 115 116 46 116 120 
> 116 99 111 102 102 0]
> 2017/04/29 09:31:51 [DEBUG] Tx packet dump:
>   02 00 00 27 00 08 00 00  a4 64 64 61 74 61 43 31  |...'.ddataC1|
> 0010  32 33 63 6c 65 6e 16 64  6e 61 6d 65 6d 2f 63 66  |23clen.dnamem/cf|
> 0020  67 2f 74 65 73 74 2e 74  78 74 63 6f 66 66 00 |g/test.txtcoff.|
> 
> 2017/04/29 09:31:51 [DEBUG] Writing [6 9] to data channel
> 2017/04/29 09:31:51 [DEBUG] Writing [65 68 69 67 65 65 65 110 65 65 103 65 65 
> 75 82 107 90 71 70 48 89 85 77 120 77 106 78 106 98 71 86 117 70 109 82 117 
> 89 87 49 108 98 83 57 106 90 109 99 118 100 71 86 122 100 67 53 48 101 72 82 
> 106 98 50 90 109 65 65 78 83] to data channel
> 2017/04/29 09:31:51 [DEBUG] Writing [10] to data channel
> 2017/04/29 09:31:51 [DEBUG] Reading [48 48 56 48 57 50 32 85 110 104 97 110 
> 100 108 101 100 32 105 110 116 101 114 114 117 112 116 32 40 51 41 44 32 101 
> 120 99 101 112 116 105 111 110 32 115 112 32 48 120 50 48 48 48 48 56 100 56] 
> from data channel
> 2017/04/29 09:31:51 [DEBUG] Reading [48 48 56 48 57 50 32 32 114 48 58 48 120 
> 50 48 48 48 48 101 56 52 32 32 114 49 58 48 120 48 48 48 48 48 48 48 48 32 32 
> 114 50 58 48 120 48 48 48 48 48 48 49 54 32 32 114 51 58 48 120 48 48 48 48 
> 48 56 48 48] from data channel
> 2017/04/29 09:31:51 [DEBUG] Reading [48 48 56 48 57 50 32 32 114 52 58 48 120 
> 50 48 48 48 48 101 56 52 32 32 114 53 58 48 120 50 48 48 48 48 57 102 56 32 
> 32 114 54 58 48 120 50 48 48 48 50 57 97 52 32 32 114 55 58 48 120 48 48 48 
> 48 48 52 48 48] from data channel
> 2017/04/29 09:31:51 [DEBUG] Reading [48 48 56 48 57 50 32 32 114 56 58 48 120 
> 48 48 48 50 53 51 49 100 32 32 114 57 58 48 120 50 48 48 48 48 102 99 48 32 
> 114 49 48 58 48 120 48 48 48 50 57 54 101 48 32 114 49 49 58 48 120 48 48 48 
> 48 48 48 50 102] from data channel
> 2017/04/29 09:31:51 [DEBUG] Reading [48 48 56 48 57 50 32 114 49 50 58 48 120 
> 48 48 48 48 48 48 48 48 32 32 108 114 58 48 120 48 48 48 48 56 56 57 98 32 32 
> 112 99 58 48 120 48 48 48 48 48 56 48 48 32 112 115 114 58 48 120 52 48 48 48 
> 48 48 48 48] from data channel
> 2017/04/29 09:31:51 [DEBUG] Reading [48 48 56 48 57 50 32 73 67 83 82 58 48 
> 120 48 48 52 50 49 56 48 51 32 72 70 83 82 58 48 120 52 48 48 48 48 48 48 48 
> 32 67 70 83 82 58 48 120 48 48 48 50 48 48 48 48] from data channel
> 2017/04/29 09:31:51 [DEBUG] Reading [48 48 56 48 57 50 32 66 70 65 82 58 48 
> 120 101 48 48 48 101 100 51 56 32 77 77 70 65 82 58 48 120 101 48 48 48 101 
> 100 51 52] from data channel
> >>>

It looks like newtmgr is sending a lot of little fragments.  Your device
might be running out of mbufs before it can reassemble the newtmgr
request.  I would try increasing the MSYS_1_BLOCK_COUNT setting if you
have the RAM for it.

> The Config 

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-743:
--

 Summary: BLE Host - Persist bonding material to sys/config.
 Key: MYNEWT-743
 URL: https://issues.apache.org/jira/browse/MYNEWT-743
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel






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

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-742:
--

 Summary: OIC requires some manual steps to initialize
 Key: MYNEWT-742
 URL: https://issues.apache.org/jira/browse/MYNEWT-742
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
 Fix For: v1_1_0_rel


E.g.,

{noformat}
static const oc_handler_t omgr_oc_handler = {
.init = omgr_app_init,
};

int
main(int argc, char **argv)
{
/* ... */
oc_main_init((oc_handler_t *)_oc_handler);
oc_ble_coap_gatt_srv_init();
}
{noformat}

If possible, it would be good if these calls happened automatically when the OS 
starts.  Unfortunately, the user will still need to configure the library with 
an oc_handler.




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

Re: Config & FS command not working on newtmgr

[Christopher Collins]

Hi Lm,

The device is reporting a newtmgr error of 5, which corresponds to
MGMT_ERR_ENOENT (Yes, we need better error reporting!).  This means the
device doesn't recognize the newtmgr command you sent it.

Did you enable file system newtmgr support?  The syscfg setting
"FS_NMGR" has to be set to 1.  You can see the value of this setting
with the "newt target config show " command.

Chris

On Fri, Apr 28, 2017 at 05:00:27PM +, Lm Chew wrote:
> Hi,
> 
> 
> 1. When i try to download a file i created on the device, i get the following 
> error when newtmgr crashes:
> 
> 
> newtmgr -c myserial fs download /cfg/test.txt test.txt -ldebug
> 
> 
> 2017/04/29 00:32:58 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:25 
> Group:8 Seq:0 Id:0 Data:[162 100 110 97 109 101 109 47 99 102 103 47 116 101 
> 115 116 46 116 120 116 99 111 102 102 0]}
> 2017/04/29 00:32:58 [DEBUG] Serializing request &{Op:0 Flags:0 Len:25 Group:8 
> Seq:0 Id:0 Data:[162 100 110 97 109 101 109 47 99 102 103 47 116 101 115 116 
> 46 116 120 116 99 111 102 102 0]} into buffer [0 0 0 25 0 8 0 0 162 100 110 
> 97 109 101 109 47 99 102 103 47 116 101 115 116 46 116 120 116 99 111 102 102 
> 0]
> 2017/04/29 00:32:58 [DEBUG] Tx packet dump:
>   00 00 00 19 00 08 00 00  a2 64 6e 61 6d 65 6d 2f  |.dnamem/|
> 0010  63 66 67 2f 74 65 73 74  2e 74 78 74 63 6f 66 66  |cfg/test.txtcoff|
> 0020  00|.|
> 
> 2017/04/29 00:32:58 [DEBUG] Writing [6 9] to data channel
> 2017/04/29 00:32:58 [DEBUG] Writing [65 67 77 65 65 65 65 90 65 65 103 65 65 
> 75 74 107 98 109 70 116 90 87 48 118 89 50 90 110 76 51 82 108 99 51 81 117 
> 100 72 104 48 89 50 57 109 90 103 66 78 111 65 61 61] to data channel
> 2017/04/29 00:32:58 [DEBUG] Writing [10] to data channel
> 2017/04/29 00:32:58 [DEBUG] Reading [] from data channel
> 2017/04/29 00:32:58 [DEBUG] Reading [6 9 65 66 65 66 65 65 65 71 65 65 103 65 
> 65 76 57 105 99 109 77 70 47 48 121 53] from data channel
> 2017/04/29 00:32:58 [DEBUG] Rx packet dump:
>   01 00 00 06 00 08 00 00  bf 62 72 63 05 ff|.brc..|
> 
> 2017/04/29 00:32:58 [DEBUG] Deserialized response &{Op:1 Flags:0 Len:6 
> Group:8 Seq:0 Id:0 Data:[191 98 114 99 5 255]}
> 2017/04/29 00:32:58 [DEBUG] goroutine 1 [running]:
> mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util.NewNewtError(0xc820136ce0,
>  0xf, 0xc820133a60)
> /home/dev/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util/util.go:75
>  +0x103
> mynewt.apache.org/newt/newtmgr/protocol.DecodeFileDownloadResponse(0xc820136c70,
>  0x6, 0x8, 0x0, 0x0, 0x0)
> /home/dev/dev/go/src/mynewt.apache.org/newt/newtmgr/protocol/fsdownload.go:90 
> +0x424
> mynewt.apache.org/newt/newtmgr/cli.fsDownloadCmd(0xc8201258c0, 0xc82001ac80, 
> 0x2, 0x5)
> /home/dev/dev/go/src/mynewt.apache.org/newt/newtmgr/cli/fs.go:161 +0x715
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).execute(0xc8201258c0,
>  0xc82001ac30, 0x5, 0x5, 0x0, 0x0)
> /home/dev/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:636
>  +0x8e9
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc820124240,
>  0xc8201258c0, 0x0, 0x0)
> /home/dev/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:722
>  +0x55c
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).Execute(0xc820124240,
>  0x0, 0x0)
> /home/dev/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:681
>  +0x2d
> main.main()
> /home/dev/dev/go/src/mynewt.apache.org/newt/newtmgr/newtmgr.go:25 +0x25
> 
> goroutine 17 [syscall, locked to thread]:
> runtime.goexit()
> /usr/lib/go-1.6/src/runtime/asm_amd64.s:1998 +0x1
> 
> goroutine 5 [syscall]:
> os/signal.signal_recv(0x0)
> /usr/lib/go-1.6/src/runtime/sigqueue.go:116 +0x132
> os/signal.loop()
> /usr/lib/go-1.6/src/os/signal/signal_unix.go:22 +0x18
> created by os/signal.init.1
> /usr/lib/go-1.6/src/os/signal/signal_unix.go:28 +0x37
> 
> Error: Target error: 5
> 
> 
> 2. When i try to write a config to /cfg/run i get the following response:
> 
> newtmgr -c myserial config testing "123" -ldebug
> 
> 
> 
> 
> 2017/04/29 00:33:36 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:22 
> Group:3 Seq:0 Id:0 Data:[162 100 110 97 109 101 103 116 101 115 116 105 110 
> 103 99 118 97 108 99 49 50 51]}
> 2017/04/29 00:33:36 [DEBUG] Serializing request &{Op:2 Flags:0 Len:22 Group:3 
> Seq:0 Id:0 Data:[162 100 110 97 109 101 103 116 101 115 116 105 110 103 99 
> 118 97 108 99 49 50 51]} into buffer [2 0 0 22 0 3 0 0 162 100 110 97 109 101 
> 103 116 101 115 116 105 110 103 99 118 97 108 99 49 50 51]
> 2017/04/29 00:33:36 [DEBUG] Tx packet dump:
>   02 00 00 16 00 03 00 00  a2 64 6e 61 6d 65 67 74  |.dnamegt|
> 0010  65 73 74 69 6e 67 63 76  61 6c 63 31 

[jira] [Resolved] (MYNEWT-736) NimBLE - UART transport can't send multi-buf chains

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-736.

Resolution: Fixed

> NimBLE - UART transport can't send multi-buf chains
> ---
>
> Key: MYNEWT-736
> URL: https://issues.apache.org/jira/browse/MYNEWT-736
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The UART transport assumes outgoing ACL data packets consist of a single 
> mbuf.  If the chain contains multiple buffers, the later part of the outgoing 
> packet consists of all zeros.



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

[jira] [Created] (MYNEWT-740) Text parsing package

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-740:
--

 Summary: Text parsing package
 Key: MYNEWT-740
 URL: https://issues.apache.org/jira/browse/MYNEWT-740
 Project: Mynewt
  Issue Type: Improvement
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


Code to parse numbers and byte strings is duplicated in a lot of apps.  It 
would be good to create a general purpose package that does this.



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

Re: newtmgr image upload nrf51dk disconnects with reason=8

[Christopher Collins]

On Fri, Apr 21, 2017 at 09:29:59PM -0700, Simon Ratner wrote:
> > itvl_min and itvl_max specify the range of connection interval values that
> > you're willing to accept. The controller chooses the value in that range
> > that it likes best. If you want an exact interval, then specify the same
> > number for both fields.
> 
> Note that iOS will reject such a request, see their accessory design
> guidelines.
> For one, itvl_max must be at least 20ms bigger than itvl_min.

Thanks, that is good to know.  I should also take this opportunity to
correct something I wrote above.  I said it is up to the slave
controller to select its preferred interval from the range specified by
the host.  This is wrong.  The slave sends both the min and max interval
values to the master, and the master chooses the interval to use (or
rejects the request entirely).  So this is how iOS can impose the
restriction you mentioned even though the iphone is acting as the master
(central).  Sorry for the misinformation.

Chris

Re: newtmgr image upload nrf51dk disconnects with reason=8

[Christopher Collins]

On Thu, Apr 20, 2017 at 09:43:12PM -0700, Jacob Rosenthal wrote:
> supervision_timeout = 300 appears to have done it! Any good way to find the
> existing params change just the 1 I actually want to change?

You can use ble_gap_conn_find() to determine the current connection
parameters.

> Maybe nrf51 devices should look up supervision_timeout and either send an
> error code or even request parameter update automatically?
> 
> static int
> bleprph_gap_event(struct ble_gap_event *event, void *arg)
> {
> struct ble_gap_conn_desc desc;
> int rc;
> 
> switch (event->type) {
> case BLE_GAP_EVENT_CONNECT:
> struct ble_gap_upd_params params = {
> .itvl_min = BLE_GAP_ADV_FAST_INTERVAL1_MIN,
> .itvl_max = BLE_GAP_ADV_FAST_INTERVAL1_MAX,
> .supervision_timeout = 300,
> .min_ce_len = BLE_GAP_INITIAL_CONN_MIN_CE_LEN,
> .max_ce_len = BLE_GAP_INITIAL_CONN_MAX_CE_LEN,
> };
> rc = ble_gap_update_params(event->connect.conn_handle, );
> assert(rc == 0);
> return 0;

Careful, you're specifying advertising interval values as connection
interval parameters.  Using ble_gap_conn_find() will take care of this.

Chris

Re: newtmgr image upload nrf51dk disconnects with reason=8

[Christopher Collins]

Hi Jacob,

On Thu, Apr 20, 2017 at 02:21:01PM -0700, Jacob Rosenthal wrote:
> I think the default intervals are here, which should be sufficiently over
> 20ms
> /** 30 ms. */
> #define BLE_GAP_ADV_FAST_INTERVAL1_MIN  (30 * 1000 / BLE_HCI_ADV_ITVL)
>   //48
> 
> /** 60 ms. */
> #define BLE_GAP_ADV_FAST_INTERVAL1_MAX  (60 * 1000 / BLE_HCI_ADV_ITVL).
>   //96
> 
> /** 100 ms. */
> #define BLE_GAP_ADV_FAST_INTERVAL2_MIN  (100 * 1000 / BLE_HCI_ADV_ITVL)
> //160
> 
> /** 150 ms. */
> #define BLE_GAP_ADV_FAST_INTERVAL2_MAX  (150 * 1000 / BLE_HCI_ADV_ITVL)
> //240
> 
> or I can even force to the higher ones in bleprph:
> 
> adv_params.itvl_min = BLE_GAP_ADV_FAST_INTERVAL2_MIN;
> adv_params.itvl_max = BLE_GAP_ADV_FAST_INTERVAL2_MAX;
[...]
> > 
> > In logs, interval advertises as adv_itvl_min=0 adv_itvl_max=0, on
> > connection logs ive seen both itvl=9 and itvl=12, not sure what that maps
> > to yet though..

These are advertising intervals, i.e., how frequently the device sends
out an advertisement, and not relevant here.  BLE has a lot of
"intervals," so I don't fault you for getting confused!

The interval of importance here is the connection interval, i.e., how
frequently the two connected peers attempt communication.  

I think adjusting the connection interval is not the best solution for
the supervision timeout problem.  If you increase the interval, this
might help maintain the connection, but it will also impair response
time between the two devices.  The correct setting to increase, in my
opinion, is the supervision timeout.  By increasing this, you allow the
peripheral device to stay quiet for a longer period of time without the
connection getting dropped.

Regardless of which parameter you change, there are two ways to do it:
1. Configure the central device such that it initiates connections
   with the preferred settings (this is what Vipul suggested in his
   newtmgr diff).

2. Have the peripheral device request a connection parameter update
   after the connection is established.  With NimBLE, you would use
   the ble_gap_update_params() function for this
   
(https://mynewt.apache.org/latest/network/ble/ble_hs/ble_gap/functions/ble_gap_update_params/).

Option 1 is the reliable way to do this.  With option 2, the central may
choose to disregard your requested parameters, so you're really at the
central's mercy.

Chris

Re: newtmgr image upload nrf51dk disconnects with reason=8

[Christopher Collins]

On Wed, Apr 19, 2017 at 04:33:05PM -0700, Jacob Rosenthal wrote:
> On Wed, Apr 19, 2017 at 11:19 AM, marko kiiskila  wrote:
> 
> > Just general comments, I hope I’m not saying things which are
> > too obvious.
> >
> More specific would be even better :) I dont think my gdb is up to par
> 
> Either g_os_run_list or one of the task structures is getting smashed.
> > As you know you tasks beforehand, you can walk through them manually
> > to figure which one it is.
> >
> How do I know the tasks beforehand? I would guess something in imgr_upload
> is corrupting it? So print as that function starts and ends? How do I walk
> through them manually?

You probably only have two tasks ("main" and the BLE controller).  My
first guess would be that the main stack is overflowing, since that is
used by both the host and newtmgr.  An easy way to tell if this is the
case is:

1. Reproduce the crash with gdb running.
2. In gdb type:

x/32wx os_main_stack

The first several values printed should be 0xdeadbeef.  If they are
something else, then you have a stack overflow.  You should increase the
size of the main stack by adjusting the OS_MAIN_STACK_SIZE syscfg
setting (default=1024 words).

> 
> >
> > Usually culprit is stack overflow, so once you find out which task
> > structure
> > is being corrupt, look for the stack just after that in memory.
> >
> > nm output piped to sort is your friend in locating that stack.
> >
> nm output?

The "nm" tool shows you the address and size of each symbol in an elf
file.  I recommend passing the "-S" option to it so that the sizes are
included in the output.

Chris

Re: newtmgr image upload nrf51dk disconnects with reason=8

[Christopher Collins]

Hi Jacob,

On Sun, Apr 16, 2017 at 03:47:24PM -0700, Jacob Rosenthal wrote:
> I got a linux partition and newtmgr working finally, However the upload
> command fails after writing one packet. The logs appear to show
> BLE_HS_ENOTSUP , but I just cant find where that could becoming from! any
> help appreciated :)

Welcome to return code hell :).  The status=8 is actually a Bluetooth
error code, not a NimBLE host error code.  In this case, the controller
belonging to the destination device has indicated a disconnect reason of
8, which translates to "supervision timeout."  In other words, your PC's
controller unexpectedly went silent, so the NimBLE device was forced to
drop the connection.

The GATT library (what newtmgr uses for BLE) is a bit sketchy, so it's
hard to tell who as at fault.  What controller are you using to send the
newtmgr command (e.g., built-in Bluetooth radio)?

Do you have any luck with a smaller newtmgr command (e.g., echo)?  The
image upload command is especially troublesome because it causes the
destination device to perform a flash erase operation.  This causes the
MCU to stall, which can lead to supervision timeouts.  I believe the
newtmgr tool uses fairly lenient connection settings for this reason,
but this could still be the problem, especially on the nRF51.

You could try connecting to the NimBLE device with a known good setup
such as the Lightblue app on OS X or an iphone.  Then, subscribe to the
newtmgr characteristic and try writing a value to the same
characteristic.  If the connection stays up and you get a notification
from the NimBLE device (newtmgr response), then I would suspect
something on the PC side.

Chris

> 
> 
> Jacobs-MacBook-Air:chippd3 jacobrosenthal$ newt target show split-nrf51dk
> targets/split-nrf51dk
> app=@apache-mynewt-core/apps/blesplit
> bsp=@apache-mynewt-core/hw/bsp/nrf51dk
> build_profile=optimized
> loader=@apache-mynewt-core/apps/bleprph
> 
> syscfg=BLE_ACL_BUF_SIZE=128:BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0:LOG_LEVEL=0
> 
> 
> [jacobrosenthal@localhost Downloads]$ sudo "$(which newtmgr)" -c ble image
> upload  blesplit.img -t -ldebug
> 2017/04/14 15:02:08 [DEBUG] BLE Connection devaddr:[]
> 2017/04/14 15:02:08 dev: hci0 up
> 2017/04/14 15:02:08 dev: hci0 down
> 2017/04/14 15:02:08 dev: hci0 opened
> 2017/04/14 15:02:08 [DEBUG] State:PoweredOn
> 2017/04/14 15:02:08 [DEBUG] scanning...
> 2017/04/14 15:02:08 [DEBUG] Peripheral Discovered: nimble-bleprph,
> Address:[10 10 10 10 10 10] Address Type:0
> 2017/04/14 15:02:08 [DEBUG] Peripheral Connected
> 2017/04/14 15:02:08 [DEBUG] Newtmgr Service Found
> 2017/04/14 15:02:08 [DEBUG] Newtmgr Characteristic Found
> 2017/04/14 15:02:08 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:99
> Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0
> 0 32 0 0 0 72 16 0 0 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64 0 32 41 56 2 0 0
> 26 128 243 20 136 128 243 16 136 3 33 24 72 2 104 10 67 2 96 23 72 2 104 10
> 67 2 96 0 26 22 74 22 75 154 66 1 210 1 99 108 101 110 25 16 140 99 111 102
> 102 0]}
> 2017/04/14 15:02:08 [DEBUG] Serializing request &{Op:2 Flags:0 Len:99
> Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0
> 0 32 0 0 0 72 16 0 0 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64 0 32 41 56 2 0 0
> 26 128 243 20 136 128 243 16 136 3 33 24 72 2 104 10 67 2 96 23 72 2 104 10
> 67 2 96 0 26 22 74 22 75 154 66 1 210 1 99 108 101 110 25 16 140 99 111 102
> 102 0]} into buffer [2 0 0 99 0 1 0 1 163 100 100 97 116 97 88 79 60 184
> 243 150 36 0 0 0 32 0 0 0 72 16 0 0 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64 0
> 32 41 56 2 0 0 26 128 243 20 136 128 243 16 136 3 33 24 72 2 104 10 67 2 96
> 23 72 2 104 10 67 2 96 0 26 22 74 22 75 154 66 1 210 1 99 108 101 110 25 16
> 140 99 111 102 102 0]
> 2017/04/14 15:02:08 [DEBUG] Tx packet dump:
>   02 00 00 63 00 01 00 01  a3 64 64 61 74 61 58 4f
>  |...c.ddataXO|
> 0010  3c b8 f3 96 24 00 00 00  20 00 00 00 48 10 00 00  |<...$...
> ...H...|
> 0020  12 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>  ||
> 0030  00 40 00 20 29 38 02 00  00 1a 80 f3 14 88 80 f3  |.@.
> )8..|
> 0040  10 88 03 21 18 48 02 68  0a 43 02 60 17 48 02 68
>  |...!.H.h.C.`.H.h|
> 0050  0a 43 02 60 00 1a 16 4a  16 4b 9a 42 01 d2 01 63
>  |.C.`...J.K.B...c|
> 0060  6c 65 6e 19 10 8c 63 6f  66 66 00 |len...coff.|
> 
> 2017/04/14 15:02:08 [DEBUG] Write BLE Packet:buf:: c �ddataXO<���$ H @ )8
> �� ��� � ! H h
> C ` H h
> C ` J K�B � clen �coff len::107
> 2017/04/14 15:02:12 [DEBUG] Disconnected%!(EXTRA )
> 
> 
> Logs show its 520, presumably BLE_HS_ENOTSUP???
> 
> 832:[ts=6499968ssb, mod=4 level=0] Disconnection Complete: status=0
> handle=1 reason=8
> 834:[ts=6515592ssb, mod=64 level=1] connection updated; status=520 handle=1
> our_ota_addr_type=0 our_ota_addr=0a:0a:0a:0a:0a:0a our_id_addr_type=0
> our_id_addr=0a:0a:0a:0a:0a:0a peer_ota_addr_type=0
> 

Re: Use of os_error_t and OS_OK

[Christopher Collins]

On Mon, Apr 10, 2017 at 04:42:09PM +0200, Sterling Hughes wrote:
> I don’t think we ever came to agreement, and things are a bit of a 
> mishmash.  Ben brings up a good point.
> 
> Mynewt wide, in my view:
> 
> * os_error is a relic, and sys/defs codes should be used.
> 
> * All functions should return “int” and not “os_error_t” or a 
> specific error type.
> 
> * 0 and -1 are SYS_EOK and SYS_EUNKNOWN (new value) respectively, and 
> can be safely returned as numbers not defines.
> 
> * For other errors, the SYS_* equivalents should be returned.
> 
> Thoughts?

Sounds good to me.  I particularly like using 0 rather than SYS_EOK.
It's completely subjective, but I think it makes the code easier to
read.

Chris

[jira] [Resolved] (MYNEWT-718) newt - Build failure under 32-bit OS

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-718.

Resolution: Fixed

> newt - Build failure under 32-bit OS
> 
>
> Key: MYNEWT-718
> URL: https://issues.apache.org/jira/browse/MYNEWT-718
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> {noformat}
> From: F Campos <filipe.al.cam...@gmail.com>   
>   
>   
>  
> To: d...@mynewt.incubator.apache.org 
> Date: Sat, 8 Apr 2017 19:06:24 +0100
> Subject: mynewt, build on ubuntu  
>   
>   
>  
> Hi,
> when building the mynewt on ubuntu I have an error on go builder: 
> *syscfg/syscfg.go:965: constant 4294967295 overflows int*
> Seems that the SYSCFG_INTERRUPT_PRIO_MAX is too big for the variable "int"
> *Linux Version:*
> lsb_release -a
> Distributor ID: Ubuntu
> Description: Ubuntu 14.04.4 LTS
> Release: 14.04
> Codename: trusty
> *Go version:*
> go version
> go version go1.7 linux/386
> Filipe
> {noformat}



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

Re: mynewt, build on ubuntu

[Christopher Collins]

Thanks Filipe.  I just pushed a fix for this issue.  The setting type
that caused this problem (interrupt_priority) was broken and unused
anyway.  I thought we had already removed it, but obviously not!  The
fix is to remove this setting type.

I believe the latest on master should build on a 32-bit system.

Chris

On Sat, Apr 08, 2017 at 07:06:24PM +0100, F Campos wrote:
> Hi,
> when building the mynewt on ubuntu I have an error on go builder:
> 
> *syscfg/syscfg.go:965: constant 4294967295 overflows int*
> 
> Seems that the SYSCFG_INTERRUPT_PRIO_MAX is too big for the variable "int"
> 
> 
> 
> *Linux Version:*
> lsb_release -a
> Distributor ID: Ubuntu
> Description: Ubuntu 14.04.4 LTS
> Release: 14.04
> Codename: trusty
> 
> 
> *Go version:*
> go version
> go version go1.7 linux/386
> 
> 
> Filipe

Develop branch deprecated

[Christopher Collins]

Hello all,

I have just merged develop to master (as you no doubt noticed if you are
subscribed to the commits list!).  From now on, all commits should go
into separate feature branches; develop is deprecated and should not be
used anymore.  The Mynewt branching policy is defined here:
https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Policy

There is a related annoyance that contributors will need to deal with:
existing pull requests.  All the existing PRs have a target branch of
"develop"; these will need to be updated to have a target branch of
"master".  Sorry for the hassle, everyone.

All questions and concerns are welcome.

Chris

[jira] [Created] (MYNEWT-711) testbench - Add BLE peripheral support

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-711:
--

 Summary: testbench - Add BLE peripheral support
 Key: MYNEWT-711
 URL: https://issues.apache.org/jira/browse/MYNEWT-711
 Project: Mynewt
  Issue Type: Improvement
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel






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

[jira] [Resolved] (MYNEWT-709) nffs - Occasional unit test failures

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-709.

Resolution: Fixed

> nffs - Occasional unit test failures
> 
>
> Key: MYNEWT-709
> URL: https://issues.apache.org/jira/browse/MYNEWT-709
> Project: Mynewt
>  Issue Type: Bug
>  Components: NFFS
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> {noformat}
> 03/31/2017, 18:42:11.997  Executing test: 
> /home/jenkins/workspace/0-testall-sim/newt_ci_templates/bin/targets/unittest/fs_nffs_test/app/fs/nffs/test/fs_nffs_test.elf
> 03/31/2017, 18:42:13.802  Test failure (fs/nffs/test):
> 03/31/2017, 18:42:13.803  [pass] nffs_test_suite/nffs_test_unlink
> 03/31/2017, 18:42:13.804  [pass] nffs_test_suite/nffs_test_mkdir
> 03/31/2017, 18:42:13.805  [pass] nffs_test_suite/nffs_test_rename
> 03/31/2017, 18:42:13.805  [pass] nffs_test_suite/nffs_test_truncate
> 03/31/2017, 18:42:13.806  [pass] nffs_test_suite/nffs_test_append
> 03/31/2017, 18:42:13.807  [pass] nffs_test_suite/nffs_test_read
> 03/31/2017, 18:42:13.808  [pass] nffs_test_suite/nffs_test_open
> 03/31/2017, 18:42:13.809  [pass] nffs_test_suite/nffs_test_overwrite_one
> 03/31/2017, 18:42:13.809  [pass] nffs_test_suite/nffs_test_overwrite_two
> 03/31/2017, 18:42:13.810  [pass] nffs_test_suite/nffs_test_overwrite_three
> 03/31/2017, 18:42:13.811  [pass] nffs_test_suite/nffs_test_overwrite_many
> 03/31/2017, 18:42:13.812  [pass] nffs_test_suite/nffs_test_long_filename
> 03/31/2017, 18:42:13.813  [pass] nffs_test_suite/nffs_test_large_write
> 03/31/2017, 18:42:13.813  [pass] nffs_test_suite/nffs_test_many_children
> 03/31/2017, 18:42:13.814  [pass] nffs_test_suite/nffs_test_gc
> 03/31/2017, 18:42:13.815  [pass] nffs_test_suite/nffs_test_wear_level
> 03/31/2017, 18:42:13.816  [pass] nffs_test_suite/nffs_test_corrupt_scratch
> 03/31/2017, 18:42:13.817  [pass] 
> nffs_test_suite/nffs_test_incomplete_block
> 03/31/2017, 18:42:13.817  [FAIL] nffs_test_suite/nffs_test_corrupt_block 
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.818  [FAIL] nffs_test_suite/nffs_test_corrupt_block 
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.819  [FAIL] nffs_test_suite/nffs_test_corrupt_block 
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.820  [pass] nffs_test_suite/nffs_test_large_unlink
> 03/31/2017, 18:42:13.821  
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.821  [pass] nffs_test_suite/nffs_test_large_system
> 03/31/2017, 18:42:13.822  
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.823  [pass] nffs_test_suite/nffs_test_lost_found
> 03/31/2017, 18:42:13.824  
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.824  [pass] nffs_test_suite/nffs_test_readdir
> 03/31/2017, 18:42:13.825  
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.826  [pass] nffs_test_suite/nffs_test_split_file
> 03/31/2017, 18:42:13.827  
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.828  [pass] nffs_test_suite/nffs_test_gc_on_oom
> 03/31/2017, 18:42:13.828  
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.829  [pass] nffs_test_suite/nffs_test_unlink
> 03/31/2017, 18:42:13.830  
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.831  [pass] nffs_test_suite/nffs_test_mkdir
> 03/31/2017, 18:42:13.832  
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 1

[jira] [Created] (MYNEWT-709) nffs - Occasional unit test failures

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-709:
--

 Summary: nffs - Occasional unit test failures
 Key: MYNEWT-709
 URL: https://issues.apache.org/jira/browse/MYNEWT-709
 Project: Mynewt
  Issue Type: Bug
  Components: NFFS
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


{noformat}
03/31/2017, 18:42:11.997Executing test: 
/home/jenkins/workspace/0-testall-sim/newt_ci_templates/bin/targets/unittest/fs_nffs_test/app/fs/nffs/test/fs_nffs_test.elf
03/31/2017, 18:42:13.802Test failure (fs/nffs/test):
03/31/2017, 18:42:13.803[pass] nffs_test_suite/nffs_test_unlink
03/31/2017, 18:42:13.804[pass] nffs_test_suite/nffs_test_mkdir
03/31/2017, 18:42:13.805[pass] nffs_test_suite/nffs_test_rename
03/31/2017, 18:42:13.805[pass] nffs_test_suite/nffs_test_truncate
03/31/2017, 18:42:13.806[pass] nffs_test_suite/nffs_test_append
03/31/2017, 18:42:13.807[pass] nffs_test_suite/nffs_test_read
03/31/2017, 18:42:13.808[pass] nffs_test_suite/nffs_test_open
03/31/2017, 18:42:13.809[pass] nffs_test_suite/nffs_test_overwrite_one
03/31/2017, 18:42:13.809[pass] nffs_test_suite/nffs_test_overwrite_two
03/31/2017, 18:42:13.810[pass] nffs_test_suite/nffs_test_overwrite_three
03/31/2017, 18:42:13.811[pass] nffs_test_suite/nffs_test_overwrite_many
03/31/2017, 18:42:13.812[pass] nffs_test_suite/nffs_test_long_filename
03/31/2017, 18:42:13.813[pass] nffs_test_suite/nffs_test_large_write
03/31/2017, 18:42:13.813[pass] nffs_test_suite/nffs_test_many_children
03/31/2017, 18:42:13.814[pass] nffs_test_suite/nffs_test_gc
03/31/2017, 18:42:13.815[pass] nffs_test_suite/nffs_test_wear_level
03/31/2017, 18:42:13.816[pass] nffs_test_suite/nffs_test_corrupt_scratch
03/31/2017, 18:42:13.817[pass] 
nffs_test_suite/nffs_test_incomplete_block
03/31/2017, 18:42:13.817[FAIL] nffs_test_suite/nffs_test_corrupt_block 
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.818[FAIL] nffs_test_suite/nffs_test_corrupt_block 
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.819[FAIL] nffs_test_suite/nffs_test_corrupt_block 
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.820[pass] nffs_test_suite/nffs_test_large_unlink
03/31/2017, 18:42:13.821
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.821[pass] nffs_test_suite/nffs_test_large_system
03/31/2017, 18:42:13.822
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.823[pass] nffs_test_suite/nffs_test_lost_found
03/31/2017, 18:42:13.824
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.824[pass] nffs_test_suite/nffs_test_readdir
03/31/2017, 18:42:13.825
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.826[pass] nffs_test_suite/nffs_test_split_file
03/31/2017, 18:42:13.827
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.828[pass] nffs_test_suite/nffs_test_gc_on_oom
03/31/2017, 18:42:13.828
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.829[pass] nffs_test_suite/nffs_test_unlink
03/31/2017, 18:42:13.830
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.831[pass] nffs_test_suite/nffs_test_mkdir
03/31/2017, 18:42:13.832
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.832[pass] nffs_test_suite/nffs_test_rename
03/31/2017, 18:42:13.833
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.834[pass] nffs_test_suite/nffs_test_truncate
03/31/2017, 18:42:13.835
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed 
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.835[pass]

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

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-708:
---
Description: 
Now that main() runs after the OS is started, tasks may preempt the main task 
as soon as they are created.  If such a task expects all packages to have been 
initialized, then a crash or other unpredictable behavior will occur.

Here is an example crash that happens when the BLE link layer task runs before 
the host package is fully initialized:

{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0  __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1  0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at 
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2  0xea5e in ble_ll_hci_send_noop () at 
net/nimble/controller/src/ble_ll_hci.c:106
#3  0xa438 in ble_ll_task (arg=) at 
net/nimble/controller/src/ble_ll.c:1008
#4  0x in ?? ()
{noformat}

  was:
Now that main() runs after the OS is started, tasks may preempt the main task 
as soon as they are created.  If such a task expects all packages to have been 
initialized, then a crash or other unpredictable behavior will occur.

Here is an example crash that happens when the BLE link layer task runs before 
the host package is fully initialized:

{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0  __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1  0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at 
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2  0xea5e in ble_ll_hci_send_noop () at 
net/nimble/controller/src/ble_ll_hci.c:106
#3  0xa438 in ble_ll_task (arg=) at 
net/nimble/controller/src/ble_ll.c:1008
#4  0x in ?? ()
(gdb)
#0  __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1  0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at 
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2  0xea5e in ble_ll_hci_send_noop () at 
net/nimble/controller/src/ble_ll_hci.c:106
#3  0xa438 in ble_ll_task (arg=) at 
net/nimble/controller/src/ble_ll.c:1008
#4  0x in ?? ()
{noformat}


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



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

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-708:
--

 Summary: Lock scheduler during init
 Key: MYNEWT-708
 URL: https://issues.apache.org/jira/browse/MYNEWT-708
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
 Fix For: v1_1_0_rel


Now that main() runs after the OS is started, tasks may preempt the main task 
as soon as they are created.  If such a task expects all packages to have been 
initialized, then a crash or other unpredictable behavior will occur.

Here is an example crash that happens when the BLE link layer task runs before 
the host package is fully initialized:

{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0  __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1  0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at 
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2  0xea5e in ble_ll_hci_send_noop () at 
net/nimble/controller/src/ble_ll_hci.c:106
#3  0xa438 in ble_ll_task (arg=) at 
net/nimble/controller/src/ble_ll.c:1008
#4  0x in ?? ()
(gdb)
#0  __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1  0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at 
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2  0xea5e in ble_ll_hci_send_noop () at 
net/nimble/controller/src/ble_ll_hci.c:106
#3  0xa438 in ble_ll_task (arg=) at 
net/nimble/controller/src/ble_ll.c:1008
#4  0x in ?? ()
{noformat}



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

Re: Problem loading images to nRF52DK board

[Christopher Collins]

Hi Greg,

On Tue, Apr 04, 2017 at 06:48:31PM +, Greg Foringer wrote:
> Hello,
> 
> I've spent about 16 hours trying to get the nrf52_boot and blehci image
> flashed to my board. I'm hoping someone has some insight about my problem.
> 
> I have installed all the SEGGER JLink tools and drivers (v6.14c) on both my
> OSX host and my Ubuntu 16.04 guest. When using JLinkExe, it can connect to
> the board over USB. I'm using the latest 1.0.0 version of newt. I've
> followed the instructions to build the nrf52_boot bootloader for my nRF52DK
> board (PCA10040 v1.1.0) as well as the blehci app.

[...]

> gdb_cmds:2: Error in sourced command file: localhost:: Connection timed
> out.

Hmm, it looks like JLinkGDBServer isn't staying up (or isn't getting
started at all).  Probably unlikely, but still worth asking: could you
have an instance of JLinkExe already running on that machine?  If any
JLink tool is already running, a second invocation will fail.

One way to debug this is to manually do what newt does and see where
the process fails:

In terminal 1:
JLinkGDBServer -device nRF52 -speed 4000 -if SWD -port 
-singlerun -reset

In terminal 2:
arm-none-eabi-gdb

(gdb) mon reset
Resetting target

(gdb) restore 
/Users/ccollins/repos/mynewt/core/bin/targets/boot-nrf52dk/app/apps/boot/boot.elf.bin
 binary 0
Restoring binary file 
/Users/ccollins/repos/mynewt/core/bin/targets/boot-nrf52dk/app/apps/boot/boot.elf.bin
 into memory (0x0 to 0x23e0)

(of course you will need to adjust the path of your boot binary).

You can also load the image into slot 0:

(gdb) restore 
/Users/ccollins/repos/mynewt/core/bin/targets/blehci-nrf52dk/app/apps/blehci/blehci.img
 binary 0x8000

Chris

[jira] [Resolved] (MYNEWT-702) BLE Host - duplicate connection update entries

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-702.

Resolution: Fixed

> BLE Host - duplicate connection update entries
> --
>
> Key: MYNEWT-702
> URL: https://issues.apache.org/jira/browse/MYNEWT-702
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> If the application calls ble_gap_update_params() while an update connection 
> procedure for that connection is already in progress, the existing entry gets 
> re-inserted in the ble_gap_update_entries list.  This yields a cycle in the 
> list, causing the host task to loop endlessly during iteration.
> More details:
> # Host initiates a connection update procedure; creates an entry and inserts 
> it into the list (ble_gap_update_entries).
> # Host attempts to initiate a second connection update procedure for the same 
> connection.  Since an existing update procedure is ongoing, this attempt 
> fails with a status code of BLE_HS_EALREADY.
> # On detecting the error, the ble_gap_update_params() function tries to clean 
> up (goto done).  Part of this cleanup involves freeing the update entry that 
> got allocated earlier in the function but never got inserted into the list.  
> In this case, no entry was allocated, but it looks like one was, because the 
> entry pointer was used to detect a duplicate entry.  Consequently, the entry 
> is freed but never removed from the list!
> # The host initiates a third connection update procedure for the same 
> connection.  This time, no duplicate is detected because the entry in the 
> list got corrupted when it was freed, making its connection handle value 
> indeterminate.  The host allocates the same entry from the pool, populates 
> it, and inserts it into the list.  Now the same entry is in the list twice, 
> creating a cycle.  When the host iterates this list, it loops forever.



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

[jira] [Resolved] (MYNEWT-696) NMP datetime response uses inconsistent format

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-696.

Resolution: Fixed

> NMP datetime response uses inconsistent format
> --
>
> Key: MYNEWT-696
> URL: https://issues.apache.org/jira/browse/MYNEWT-696
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> If the time was set with a time zone, the datetime response includes the time 
> zone at the end of the string.  Otherwise, no time zone is present.
> This inconsistency makes parsing more difficult.  The fix is to report UTC as 
> the time zone if none was explicitly specified.



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

Re: Adding platform specific API to get public and/or random static address

[Christopher Collins]

On Sat, Apr 01, 2017 at 09:53:03AM +0200, Marcel Holtmann wrote:
> > Some things about writing apps and the BLE spec:
> > 1) I realize that it is the host that tells the controller the
> > random address to use. The controller will NOT automatically use the
> > random address from ble_hw_get_static_addr(). That API will be added
> > as a convenience so that the app developer does not have to generate
> > their own. If the app wants to use this random address it needs to
> > tell the controller to use it using LE_Set_Random_Addr.
> > 
> > 2) Regarding the public device address. We have an app called
> > bletiny that can set the public device address I think. If the above
> > gets approved we are going to remove g_dev_addr from the code; it
> > will be kept in the controller and not available globally. The
> > Zephyr project is considering adding vendor specific HCI commands,
> > one of which is “set public device address”. I think if we go with
> > the above approach we should add this vendor specific command and
> > that should be the way an app can set the public device address if
> > it so chooses.
> 
> The public BD_ADDR needs to be inside the controller before the call
> of HCI_Reset. Otherwise all sort of assumptions on HCI break. Until
> then the HCI_Read_BD_ADDR has to return 00:00:00:00:00:00 to indicate
> the controller has no public address. Switching the BD_ADDR mid-flight
> with a backdoor is going to fail in the most funny ways left and
> right.

The bletiny app is a sandbox test tool, and it does some things that a
more robust application shouldn't do.  One such underhanded thing it
does is change its own public address whenever the user requests it.  It
does this by simply overwriting the global public address byte array and
hoping for the best.  In practice, I've never seen anything funny
happen, either to the left or the right :), but this is certainly not
guaranteed to work.  Also, this won't work at all unless bletiny is
running on a combined host-controller, since that is the only occasion
in which the host has access to the public address global variable.

I don't want to speak for Will, but my guess is he just looked at what
existing code accesses the public address global to determine the scope
of the proposed API.  My understanding from reading his email is that
bletiny is doing something sketchy, and that the proposed API won't
support this particular use case.

Chris

Re: Adding platform specific API to get public and/or random static address

[Christopher Collins]

On Fri, Mar 31, 2017 at 03:49:05PM -0700, will sanfilippo wrote:
> Hello:
> 
> There has been some discussion of this already on the list but nothing has 
> been done yet so I wanted to resurrect the conversation with some proposals.
> 
> What we are trying to do here is the following:
> 1) Have the controller get a public device address without it being hardcoded.
> 2) Have the ability to read a chip-specific random static address if the chip 
> has one programmed.
> 
> The proposal is the following:

> 1) Add two new API. These will be platform specific and will be placed
> in the ble_hw.c file:

> /* These API will return -1 if no address available. If available, will
> return 0
> and will place the address in *addr */
> int ble_hw_get_public_addr(ble_addr_t *addr)
> int ble_hw_get_static_addr(ble_addr_t *addr)

[...]

That sounds good to me.  This covers all the use cases I can think of.

As you mentioned, Bluetooth is somewhat asymmetric regarding public and
random addresses.  The controller is in charge of the public address
while the host is in charge of the static random address.

With the API you proposed, I think the workflow would look something
like this:

1. At init time, controller calls ble_hs_get_public_addr().  If this
call yields an address, the controller configures itself to use it.

2. If app wants a static random address, it calls
ble_hw_get_static_addr().  If a random address is available, the
application configures the host to use it with a call to
ble_hs_id_set_rnd().

Does that sound about right?

In thinking about this, I realized the host interface is missing
something.  There is currently no way for an application to ask the host
for its public address.  An application may want to know this to
determine if it should configure a random address (or just for
reporting purposes).  The host does know its own public address--it gets
it from the controller at startup--it just doesn't expose it to the
application.

Chris

[jira] [Updated] (MYNEWT-702) BLE Host - duplicate connection update entries

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-702:
---
Description: 
If the application calls ble_gap_update_params() while an update connection 
procedure for that connection is already in progress, the existing entry gets 
re-inserted in the ble_gap_update_entries list.  This yields a cycle in the 
list, causing the host task to loop endlessly during iteration.

More details:
# Host initiates a connection update procedure; creates an entry and inserts it 
into the list (ble_gap_update_entries).
# Host attempts to initiate a second connection update procedure for the same 
connection.  Since an existing update procedure is ongoing, this attempt fails 
with a status code of BLE_HS_EALREADY.
# On detecting the error, the ble_gap_update_params() function tries to clean 
up (goto done).  Part of this cleanup involves freeing the update entry that 
got allocated earlier in the function but never got inserted into the list.  In 
this case, no entry was allocated, but it looks like one was, because the entry 
pointer was used to detect a duplicate entry.  Consequently, the entry is freed 
but never removed from the list!
# The host initiates a third connection update procedure for the same 
connection.  This time, no duplicate is detected because the entry in the list 
got corrupted when it was freed, making its connection handle value 
indeterminate.  The host allocates the same entry from the pool, populates it, 
and inserts it into the list.  Now the same entry is in the list twice, 
creating a cycle.  When the host iterates this list, it loops forever.

  was:If the application calls ble_gap_update_params() while an update 
connection procedure for that connection is already in progress, the existing 
entry gets re-inserted in the ble_gap_update_entries list.  This yields a cycle 
in the list, causing the host task to loop endlessly during iteration.


> BLE Host - duplicate connection update entries
> --
>
> Key: MYNEWT-702
> URL: https://issues.apache.org/jira/browse/MYNEWT-702
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> If the application calls ble_gap_update_params() while an update connection 
> procedure for that connection is already in progress, the existing entry gets 
> re-inserted in the ble_gap_update_entries list.  This yields a cycle in the 
> list, causing the host task to loop endlessly during iteration.
> More details:
> # Host initiates a connection update procedure; creates an entry and inserts 
> it into the list (ble_gap_update_entries).
> # Host attempts to initiate a second connection update procedure for the same 
> connection.  Since an existing update procedure is ongoing, this attempt 
> fails with a status code of BLE_HS_EALREADY.
> # On detecting the error, the ble_gap_update_params() function tries to clean 
> up (goto done).  Part of this cleanup involves freeing the update entry that 
> got allocated earlier in the function but never got inserted into the list.  
> In this case, no entry was allocated, but it looks like one was, because the 
> entry pointer was used to detect a duplicate entry.  Consequently, the entry 
> is freed but never removed from the list!
> # The host initiates a third connection update procedure for the same 
> connection.  This time, no duplicate is detected because the entry in the 
> list got corrupted when it was freed, making its connection handle value 
> indeterminate.  The host allocates the same entry from the pool, populates 
> it, and inserts it into the list.  Now the same entry is in the list twice, 
> creating a cycle.  When the host iterates this list, it loops forever.



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

[jira] [Created] (MYNEWT-702) BLE Host - duplicate connection update entries

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-702:
--

 Summary: BLE Host - duplicate connection update entries
 Key: MYNEWT-702
 URL: https://issues.apache.org/jira/browse/MYNEWT-702
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


If the application calls ble_gap_update_params() while an update connection 
procedure for that connection is already in progress, the existing entry gets 
re-inserted in the ble_gap_update_entries list.  This yields a cycle in the 
list, causing the host task to loop endlessly during iteration.



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

[jira] [Created] (MYNEWT-700) BLE Host - Race condition: disconnect + att-tx

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-700:
--

 Summary: BLE Host - Race condition: disconnect + att-tx
 Key: MYNEWT-700
 URL: https://issues.apache.org/jira/browse/MYNEWT-700
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


Some parts of the ATT code assume a peer is still connected after an initial 
check.  This assumption leads to a race condition when a task other than the 
host task is doing the transmitting (e.g., tx of unsolicited notification).  It 
is possible that the peer gets disconnected after the tx function is called, 
but before it completes.  When this occurs, an assertion fails 
(ble_att_conn_chan_find()).

The fix is to remove this assumption.  Always check that the connection / 
channel lookup succeeds before accessing the returned pointers.



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

Re: Newtmgr over BLE not Working

[Christopher Collins]

Hi Lm,

On Sun, Mar 26, 2017 at 07:45:37AM +, Lm Chew wrote:
> I also tried setting up a nrf52 DK with blehci app + BlueZ as explained in 
> this tutorial(with a few changes).
> 
> - http://mynewt.apache.org/latest/os/tutorials/blehci_project/
> 
> - Use this to connect with btattach instead: sudo btattach -B /dev/ttyACM0 -S 
> 100 -P h4
> 
> - Skip the btmgmt step since in BlueZ 5.44 we no longer need to set the 
> static-address manually and newtmgr will handle the rest.
> 
> - Used the nrf52 DK onboard USB to UART bridge, did not use a FTDI USB TTL 
> Serial Cable.
> 
> 
> But unfortunately I can't get it to work either, in fact it is one step 
> backward.

When you use the USB virtual COM port on an nRF board, there are two
things you will want to do:

1. Disable mass storage device capability on your board (from JLinkExe):

MSDDisable

2. Reduce the BLE_ACL_BUF_SIZE setting to 128 (default=255) (in your
target's syscfg.yml file):

syscfg.vals:
BLE_ACL_BUF_SIZE: 128

Both of these changes prevent the virtual COM port's buffer from
overflowing.

For 1: nRF boards normally reserve a large portion of the buffer
for mass storage device functionality.  By disabling this functionality,
the entire buffer is made available to UART opertaions.  

For 2: The buffer can overflow if the host floods the controller with
large ACL data packets, especially at high baud rates.  Reducing the
maximum transmission size down to 128 solved this problem for me.

I don't know if these will solve your problem, though.  If you still
have issues, could you please send the entire btmon log?

Thanks,
Chris

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

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-657:
---
Description: 
Currently, the log level can only be configured globally (via the LOG_LEVEL 
syscfg setting).  It would be useful if each module had its own log level.

Unfortunately, I don't know of a better way to do this than to define 
module-specific versions of all the LOG_... macros.

  was:Currently, the log level can only be configured globally (via the 
LOG_LEVEL syscfg setting).  It would be useful if each module had its own log 
level.

Summary: Ability to configure per-module log level at compile time  
(was: Ability to configure log level per module)

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



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

[jira] [Resolved] (MYNEWT-677) NMP: Include next_index in log show response

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-677.

Resolution: Fixed

> NMP: Include next_index in log show response
> 
>
> Key: MYNEWT-677
> URL: https://issues.apache.org/jira/browse/MYNEWT-677
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The next_index value (index of next log entry to be written) is useful for 
> determining if a device's flash has been wiped since the last time logs were 
> scoured.
> The new value is at the top-level of the log show response with the following 
> name: {{next_index}}.



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