[jira] [Updated] (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 updated MYNEWT-677:
---
Description: 
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}}.

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


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

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-677:
--

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



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

[jira] [Created] (MYNEWT-676) Reboot counter value inconsistent

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-676:
--

 Summary: Reboot counter value inconsistent
 Key: MYNEWT-676
 URL: https://issues.apache.org/jira/browse/MYNEWT-676
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


The value that gets logged to the reboot log is one greater than the actual 
reboot counter (the value retrieved via "newtmgr config reboot/reboot_cnt").



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

Re: Problem to use newtmgr through ble

[Christopher Collins]

On Fri, Mar 17, 2017 at 08:36:01AM -0300, Fabio Utzig wrote:
> On Fri, Mar 17, 2017, at 08:24 AM, then yon wrote:
> > Dear Chris,
> > 
> > When i put sudo newtmgr -c BT01 stat list, it gave me sudo: newtmgr: 
> > command not found.
> 
> It looks like sudo is not preserving your user path, you could try:
> 
> sudo "PATH=$PATH" newtmgr -c BT01 stat list

Hmm, I don't think you'll be able to set environment variables unless
you execute a new shell instance in sudo (e.g., sudo bash -c ...), which
is painful.

This might be the easiest way forward:

sudo "$(which newtmgr)" -c BT01 stat list

Chris

Re: Debugging blecent application on nrf52dk

[Christopher Collins]

Hi Pritish,

On Thu, Mar 16, 2017 at 01:50:12PM -0700, Pritish Gandhi wrote:
> Hi All,
> I'm trying to run blecent on an nrf52dk and am running the bleprph
> application on another BLE module (stm32f4discovery talking to a broadcom
> BLE core). Anyways, when try to run blecent it seems like I successfully
> connect to the peripheral and are able to discover it, however after that
> the connection seems to be timing out and then am never able to discover
> the peripheral again.

[...]

Hmm, that is odd, indeed.  The disconnect reason codes you are seeing
are mapped as follows:

546 - LMP RESPONSE TIMEOUT / LL RESPONSE TIMEOUT
520 - CONNECTION TIMEOUT

I'm afraid I don't have any ideas at the moment.  Could you please
clarify the setup you are using?  Here is my understanding:

Device A: blecent on nRF52dk (combined host-controller)
Device B:
* bleprph on stm32f4discovery (host-only)
* broadcom controller

Is that correct?  If so, I assume the host and controller on device B
communicate via UART?

Thanks,
Chris

> 
> 1) Connected and Discovered the bleprph:
> 
> 37493:[ts=292914004ssb, mod=4 level=1] GAP procedure initiated: discovery;
> own_addr_type=0 filter_policy=0 passive=1 limited=0 filter_duplicates=1
> duration=forever
> 
> 37503:[ts=292992124ssb, mod=4 level=1] GAP procedure initiated: connect;
> peer_addr_type=0 peer_addr=aa:aa:aa:aa:aa:aa scan_itvl=16 scan_window=16
> itvl_min=24 itvl_max=40 latency=0 supervision_timeout=256 min_ce_len=16
> max_ce_len=768 own_addr_ty
> 
> 37517:[ts=293101556ssb, mod=64 level=1] Connection established
> 
> 37519:[ts=293117180ssb, mod=4 level=1] GATT procedure initiated: discover
> all services
> 
> 37588:[ts=293656208ssb, mod=4 level=1] GATT procedure initiated: discover
> all characteristics; start_handle=1 end_handle=11
> 
> 37627:[ts=293960876ssb, mod=4 level=1] GATT procedure initiated: discover
> all characteristics; start_handle=12 end_handle=15
> 
> 37658:[ts=294203112ssb, mod=4 level=1] GATT procedure initiated: discover
> all characteristics; start_handle=16 end_handle=19
> 
> 37684:[ts=294406224ssb, mod=4 level=1] GATT procedure initiated: discover
> all characteristics; start_handle=20 end_handle=32
> 
> 37722:[ts=294703080ssb, mod=4 level=1] GATT procedure initiated: discover
> all characteristics; start_handle=33 end_handle=65535
> 
> 37761:[ts=295007812ssb, mod=4 level=1] GATT procedure initiated: discover
> all descriptors; chr_val_handle=14 end_handle=15
> 
> 37774:[ts=295109368ssb, mod=4 level=1] GATT procedure initiated: discover
> all descriptors; chr_val_handle=18 end_handle=19
> 
> 37786:[ts=295203112ssb, mod=4 level=1] GATT procedure initiated: discover
> all descriptors; chr_val_handle=24 end_handle=25
> 
> 37799:[ts=295304668ssb, mod=4 level=1] GATT procedure initiated: discover
> all descriptors; chr_val_handle=29 end_handle=30
> 
> 37812:[ts=295406224ssb, mod=4 level=1] GATT procedure initiated: discover
> all descriptors; chr_val_handle=37 end_handle=65535
> 
> 37825:[ts=295507780ssb, mod=64 level=3] Service discovery complete;
> status=0 conn_handle=1
> 
> 2) Read/Write/Subscribe for notifications. Finally fails with reason=546
> 
> 37827:[ts=295523404ssb, mod=4 level=1] GATT procedure initiated: read;
> att_handle=22
> 
> 37829:[ts=295539028ssb, mod=4 level=1] GATT procedure initiated: write;
> att_handle=32 len=2
> 
> 37832:[ts=295562464ssb, mod=4 level=1] GATT procedure initiated: write;
> att_handle=30 len=2
> 
> 37851:[ts=295710892ssb, mod=64 level=1] Read complete; status=0
> conn_handle=1 attr_handle=22 value=
> 
> 37857:[ts=295757764ssb, mod=64 level=1] Write complete; status=0
> conn_handle=1 attr_handle=32
> 
> 37863:[ts=295804636ssb, mod=64 level=1] Subscribe complete; status=0
> conn_handle=1 attr_handle=30
> 
> 42637:[ts=333101556ssb, mod=64 level=1] disconnect; reason=546
> 
> 
> 3) Once it disconnects, blecent gets stuck in this loop of trying to
> discover, but the discovery always fails:
> 
> 42638:[ts=333109368ssb, mod=4 level=1] GAP procedure initiated: discovery;
> own_addr_type=0 filter_policy=0 passive=1 limited=0 filter_duplicates=1
> duration=forever
> 
> 42973:[ts=335726516ssb, mod=4 level=1] GAP procedure initiated: connect;
> peer_addr_type=0 peer_addr=aa:aa:aa:aa:aa:aa scan_itvl=16 scan_window=16
> itvl_min=24 itvl_max=40 latency=0 supervision_timeout=256 min_ce_len=16
> max_ce_len=768 own_addr_ty
> 
> 42982:[ts=335796824ssb, mod=64 level=1] Connection established
> 
> 42983:[ts=335804636ssb, mod=4 level=1] GATT procedure initiated: discover
> all services
> 
> 43020:[ts=336093744ssb, mod=64 level=3] Error: Service discovery failed;
> status=7 conn_handle=1
> 
> 43022:[ts=336109368ssb, mod=4 level=1] GAP procedure initiated: terminate
> connection; conn_handle=1 hci_reason=19
> 
> 43025:[ts=336132804ssb, mod=64 level=1] disconnect; reason=520
> 
> 43027:[ts=336148428ssb, mod=4 level=1] GAP procedure initiated: discovery;
> own_addr_type=0 filter_policy=0 passive=1 limited=0 filter_duplicates=1

[jira] [Resolved] (MYNEWT-674) newt - Remove use of new io.SeekCurrent symbol

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-674.

Resolution: Fixed

> newt - Remove use of new io.SeekCurrent symbol
> --
>
> Key: MYNEWT-674
> URL: https://issues.apache.org/jira/browse/MYNEWT-674
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> This constant was added in go 1.7.  A lot of package manager repos only carry 
> go 1.6, so the use of this constant makes newt unbuildable for a lot of users.



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

[jira] [Created] (MYNEWT-674) newt - Remove use of new io.SeekCurrent symbol

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-674:
--

 Summary: newt - Remove use of new io.SeekCurrent symbol
 Key: MYNEWT-674
 URL: https://issues.apache.org/jira/browse/MYNEWT-674
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


This constant was added in go 1.7.  A lot of package manager repos only carry 
go 1.6, so the use of this constant makes newt unbuildable for a lot of users.



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

Re: Problem to use newtmgr through ble

[Christopher Collins]

Hi Then,

I have found that I need to run newtmgr as root when using ble (e.g.,
sudo newtmgr ...)

Chris

On Thu, Mar 16, 2017 at 05:22:01PM +0800, then yon wrote:
> Dear Support,
> 
> Anyone have answer on this?
> 
> Some updates on the newtmgr setting:
> 
> Connection profiles: BT01: type=ble, connstring='nimble-bleprph'
> 
> Whenever i sent newtmgr command i get the following:
> 
> 2017/03/16 17:11:35 dev: hci0 up 2017/03/16 17:11:35 dev: hci1 up Error: 
> no supported devices available
> 
> I'm using V2TEC Bluetooth dongle (Bus 001 Device 016: ID 0a12:0001 
> Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode))
> 
> Thank you.
> 
> Regards,
> 
> Then Yoong Ze
> 
> 
> On 10/3/2017 6:59 PM, then yon wrote:
> > Dear Support,
> >
> > After the being success to do image upgrade with slinky app, now i
> > moving forward to image upgrade through ble with bleprph example.
> >
> > With the target.yml as below:
> > ### Target: targets/split_slinky
> > target.app: "@apache-mynewt-core/apps/splitty"
> > target.bsp: "@apache-mynewt-core/hw/bsp/nrf52dk"
> > target.build_profile: "optimized"
> > target.loader: "@apache-mynewt-core/apps/bleprph"
> > target.syscfg: "BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0"
> >
> > The problem is i do not get any newtmgr response in serial with this
> > example; and i can't detect any BT packet from bleprph example.
> >
> > if i changed the target.yml as below; i can detect bleprph advertising
> > packet:
> > ### Target: targets/split_slinky
> > target.bsp: "@apache-mynewt-core/hw/bsp/nrf52dk"
> > target.build_profile: "optimized"
> > target.app: "@apache-mynewt-core/apps/bleprph"
> > target.syscfg: "BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0"
> >
> >
> > The command i used to detect ble advertising packet is "sudo hcitool
> > lescan --duplicates &"
> >
> >
> > Thank you.
> >
> > Regards,
> >
> > Then Yoong Ze
> >
> 

[jira] [Resolved] (MYNEWT-673) testbench app reports some fails as passes

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-673.

Resolution: Fixed

> testbench app reports some fails as passes
> --
>
> Key: MYNEWT-673
> URL: https://issues.apache.org/jira/browse/MYNEWT-673
> 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] [Assigned] (MYNEWT-660) newt - Quotes get stripped from syscfg values when they are written

[Christopher Collins (JIRA)]

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

Christopher Collins reassigned MYNEWT-660:
--

Assignee: Christopher Collins  (was: Sterling Hughes)
 Summary: newt - Quotes get stripped from syscfg values when they are 
written  (was: newt - Quotes get stripped from yaml files when they are written)

> newt - Quotes get stripped from syscfg values when they are written
> ---
>
> Key: MYNEWT-660
> URL: https://issues.apache.org/jira/browse/MYNEWT-660
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>    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-671) UART support in sim

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-671.

Resolution: Fixed

> UART support in sim
> ---
>
> Key: MYNEWT-671
> URL: https://issues.apache.org/jira/browse/MYNEWT-671
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Currently, sim always maps UARTs to ptys.  This change allows the application 
> to specify a file (e.g., /dev/...) to map a UART to.



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

[jira] [Created] (MYNEWT-671) UART support in sim

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-671:
--

 Summary: UART support in sim
 Key: MYNEWT-671
 URL: https://issues.apache.org/jira/browse/MYNEWT-671
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


Currently, sim always maps UARTs to ptys.  This change allows the application 
to specify a file (e.g., /dev/...) to map a UART to.



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

[jira] [Resolved] (MYNEWT-670) NMP: Make max chunk size configurable

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-670.

Resolution: Fixed

> NMP: Make max chunk size configurable
> -
>
> Key: MYNEWT-670
> URL: https://issues.apache.org/jira/browse/MYNEWT-670
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Newtmgr
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Currently, the largest image or file chunk that a Mynewt device can receive 
> is hardcoded at 400 bytes.  Furthermore, the largets CBOR attribute that we 
> can decode is 300 bytes long.This is not great because this number is 
> independent of the transport MTU, so the client has no way of knowing the 
> limit.
> The fix is to create three new compile-time settings:
> * CBORATTR_MAX_SIZE
> * FS_UPLOAD_MAX_CHUNK_SIZE
> * IMGMGR_MAX_CHUNK_SIZE
> and set them to 512 by default.  This value is large enough to accommodate 
> full-size BLE packets.
> This is still not a perfect solution because these values are not tied to the 
> MTU in any way.  One way to truly solve this would be to have an "NMP MTU" 
> that the client can discover.  That would be a pretty big change.



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

[jira] [Updated] (MYNEWT-670) NMP: Make max chunk size configurable

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-670:
---
Description: 
Currently, the largest image or file chunk that a Mynewt device can receive is 
hardcoded at 400 bytes.  Furthermore, the largets CBOR attribute that we can 
decode is 300 bytes long.This is not great because this number is independent 
of the transport MTU, so the client has no way of knowing the limit.

The fix is to create three new compile-time settings:
* CBORATTR_MAX_SIZE
* FS_UPLOAD_MAX_CHUNK_SIZE
* IMGMGR_MAX_CHUNK_SIZE

and set them to 512 by default.  This value is large enough to accommodate 
full-size BLE packets.

This is still not a perfect solution because these values are not tied to the 
MTU in any way.  One way to truly solve this would be to have an "NMP MTU" that 
the client can discover.  That would be a pretty big change.

  was:
Currently, the largest image or file chunk that a Mynewt device can receive is 
hardcoded at 400 bytes.  This is not great because this number is independent 
of the transport MTU, so the client has no way of knowing the limit.

The fix is to create two new compile-time settings:
* FS_UPLOAD_MAX_CHUNK_SIZE
* IMGMGR_MAX_CHUNK_SIZE

and set them to 512 by default.  This value is large enough to accommodate 
full-size BLE packets.

This is still not a perfect solution because these values are not tied to the 
MTU in any way.  One way to truly solve this would be to have an "NMP MTU" that 
the client can discover.  That would be a pretty big change.

Summary: NMP: Make max chunk size configurable  (was: image / fs NMP: 
Make max chunk size configurable)

> NMP: Make max chunk size configurable
> -
>
> Key: MYNEWT-670
> URL: https://issues.apache.org/jira/browse/MYNEWT-670
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Newtmgr
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Currently, the largest image or file chunk that a Mynewt device can receive 
> is hardcoded at 400 bytes.  Furthermore, the largets CBOR attribute that we 
> can decode is 300 bytes long.This is not great because this number is 
> independent of the transport MTU, so the client has no way of knowing the 
> limit.
> The fix is to create three new compile-time settings:
> * CBORATTR_MAX_SIZE
> * FS_UPLOAD_MAX_CHUNK_SIZE
> * IMGMGR_MAX_CHUNK_SIZE
> and set them to 512 by default.  This value is large enough to accommodate 
> full-size BLE packets.
> This is still not a perfect solution because these values are not tied to the 
> MTU in any way.  One way to truly solve this would be to have an "NMP MTU" 
> that the client can discover.  That would be a pretty big change.



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

[jira] [Created] (MYNEWT-670) image / fs NMP: Make max chunk size configurable

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-670:
--

 Summary: image / fs NMP: Make max chunk size configurable
 Key: MYNEWT-670
 URL: https://issues.apache.org/jira/browse/MYNEWT-670
 Project: Mynewt
  Issue Type: Improvement
  Components: Newtmgr
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


Currently, the largest image or file chunk that a Mynewt device can receive is 
hardcoded at 400 bytes.  This is not great because this number is independent 
of the transport MTU, so the client has no way of knowing the limit.

The fix is to create two new compile-time settings:
* FS_UPLOAD_MAX_CHUNK_SIZE
* IMGMGR_MAX_CHUNK_SIZE

and set them to 512 by default.  This value is large enough to accommodate 
full-size BLE packets.

This is still not a perfect solution because these values are not tied to the 
MTU in any way.  One way to truly solve this would be to have an "NMP MTU" that 
the client can discover.  That would be a pretty big change.



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

Re: [VOTE] Release Apache Mynewt 1.0.0-incubating-rc1

[Christopher Collins]

On Thu, Mar 09, 2017 at 10:24:32AM -0800, marko kiiskila wrote:
> [X] +1 Release this package

+1 (Binding)

Chris

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


> 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
>Reporter: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> This would be analogous to the "image upload", "file upload", and "file 
> download" commands.  Each of these indicate the total number of bytes in the 
> first packet.
> This change involves a backwards compatible modification to the NMP protocol. 
>  Compatibility is maintained because this change only requires the addition 
> of a new field, not the modification or removal of existing fields.



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

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-664:
--

 Summary: 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
Reporter: Christopher Collins
 Fix For: v1_1_0_rel


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



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

Re: building newt using go

[Christopher Collins]

On Thu, Mar 09, 2017 at 07:52:58AM +, David Brown wrote:
> I would suggest we remove this particular dependency. Although it is nice
> to have symbolic names, go 1.6 is the latest version that is in a LTS
> ubuntu release, so I suspect it is the easiest version for a lot of people
> to have available.
> 
> The symbol in question is just an integer constant.

[io.SeekCurrent]

That is a good idea.  I didn't realize that symbol got added in 1.7.  I
just used it because the Go docs said it is a replacement for a
deprecated symbol.

Chris

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

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-661:
--

 Summary: 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
  Components: Nimble
Reporter: 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] [Created] (MYNEWT-660) newt - Quotes get stripped from yaml files when they are written

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-660:
--

 Summary: newt - Quotes get stripped from yaml files when they are 
written
 Key: MYNEWT-660
 URL: https://issues.apache.org/jira/browse/MYNEWT-660
 Project: Mynewt
  Issue Type: Bug
  Components: Newt
Reporter: Christopher Collins
Assignee: Sterling Hughes
 Fix For: v1_1_0_rel






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

Re: MyNewt: NimBLE: Question regarding large file transfer over Bluetooth

[Christopher Collins]

Hi Pritish,

On Tue, Mar 07, 2017 at 03:15:49PM -0800, Pritish Gandhi wrote:
> Hi All,
> Disclaimer: I don't know much about Bluetooth so I might sound like a novice
> 
> I've been thinking about writing an application to transfer an OTA image
> over Bluetooth and am wondering what would be the best way to go about it.
> I was looking at the generic Object Transfer Services in the Bluetooth Spec:
> https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.object_transfer.xml
> 
> And it seems to suggest that this service uses a separate L2CAP connection.
> I wonder whether NimBLE supports this or any other file transfer protocol
> over Bluetooth.
> Has anyone tried this or some other means of doing an OTA over Bluetooth?

I'm not familiar with the object transfer service, but it looks like it
would work pretty well for this.  Łukasz has added support for
connection oriented channels to nimble, so I think the required
functionality is all there.  This service looks rather complicated,
though, so there may be a fair amount of work involved in implementing
it.

Alternatively, Mynewt already supports file transfer using the newtmgr
protocol (NMP).  NMP is a simple request-response protocol described in
more detail here:
http://mynewt.apache.org/latest/os/modules/devmgmt/newtmgr/

This works today, but it is not particularly well suited to large data
transfers over BLE.  The need to wait for a response to each file chunk
prevents the kind of throughput that a BLE link can support.

Chris

[jira] [Created] (MYNEWT-657) Ability to configure log level per module

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-657:
--

 Summary: Ability to configure log level per module
 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.



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

[jira] [Updated] (MYNEWT-655) newt - Detect repo / newt version incompatibilities

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-655:
---
Description: 
This is done with a separate map "repo.newt_compatibility" in the repo's 
repository.yml file.

Example:
{noformat}
repo.newt_compatibility:
1.0.0:
1.1.0: error
1.0.0: good
0.9.99: warn
0.9.9: error
{noformat}

This says that this version 1.0.0 of this repo is compatible with newt versions 
[1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a warning 
message.  All other newt versions generate an error.

A project can also indicate newt version restrictions

Example (project.yml):
{noformat}
project.newt_compatibility:
1.1.0: error
1.0.0: good
0.9.99: warn
0.9.9: error
{noformat}

Just to be clear, the newt version numbers are *minimum* version numbers.  The 
following table:
{noformat}
1.0.0: good
0.1.0: error
{noformat}

Says that newt versions >= 0.1.0 and < 1.0.0 elicit an error.  All newt 
versions >= 1.0.0 are OK.

  was:
This is done with a separate map "repo.newt_compatibility" in the repo's 
repository.yml file.

Example:
{noformat}
repo.newt_compatibility:
1.0.0:
1.1.0: error
1.0.0: good
0.9.99: warn
0.9.9: error
{noformat}

This says that this version 1.0.0 of this repo is compatible with newt versions 
[1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a warning 
message.  All other newt versions generate an error.

A project can also indicate newt version restrictions

Example (project.yml):
{noformat}
project.newt_compatibility:
1.1.0: error
1.0.0: good
0.9.99: warn
0.9.9: error
{noformat}

Just to be clear, the newt version numbers are *minimum* version numbers.  The 
following table:
{noformat}
1.0.0: good
0.1.0: error

Says that newt versions >= 0.1.0 and < 1.0.0 elicit an error.  All newt 
versions >= 1.0.0 are OK.


> newt - Detect repo / newt version incompatibilities
> ---
>
> Key: MYNEWT-655
> URL: https://issues.apache.org/jira/browse/MYNEWT-655
> Project: Mynewt
>  Issue Type: Improvement
>    Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> This is done with a separate map "repo.newt_compatibility" in the repo's 
> repository.yml file.
> Example:
> {noformat}
> repo.newt_compatibility:
> 1.0.0:
> 1.1.0: error
> 1.0.0: good
> 0.9.99: warn
> 0.9.9: error
> {noformat}
> This says that this version 1.0.0 of this repo is compatible with newt 
> versions [1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a 
> warning message.  All other newt versions generate an error.
> A project can also indicate newt version restrictions
> Example (project.yml):
> {noformat}
> project.newt_compatibility:
> 1.1.0: error
> 1.0.0: good
> 0.9.99: warn
> 0.9.9: error
> {noformat}
> Just to be clear, the newt version numbers are *minimum* version numbers.  
> The following table:
> {noformat}
> 1.0.0: good
> 0.1.0: error
> {noformat}
> Says that newt versions >= 0.1.0 and < 1.0.0 elicit an error.  All newt 
> versions >= 1.0.0 are OK.



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

[jira] [Updated] (MYNEWT-655) newt - Detect repo / newt version incompatibilities

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-655:
---
Fix Version/s: (was: v1_1_0_rel)
   v1_0_0_rel

> newt - Detect repo / newt version incompatibilities
> ---
>
> Key: MYNEWT-655
> URL: https://issues.apache.org/jira/browse/MYNEWT-655
> Project: Mynewt
>  Issue Type: Improvement
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> This is done with a separate map "repo.newt_compatibility" in the repo's 
> repository.yml file.
> Example:
> {noformat}
> repo.newt_compatibility:
> 1.0.0:
> 1.1.0: error
> 1.0.0: good
> 0.9.99: warn
> 0.9.9: error
> {noformat}
> This says that this version 1.0.0 of this repo is compatible with newt 
> versions [1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a 
> warning message.  All other newt versions generate an error.



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

[jira] [Resolved] (MYNEWT-655) newt - Detect repo / newt version incompatibilities

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-655.

Resolution: Fixed

> newt - Detect repo / newt version incompatibilities
> ---
>
> Key: MYNEWT-655
> URL: https://issues.apache.org/jira/browse/MYNEWT-655
> Project: Mynewt
>  Issue Type: Improvement
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> This is done with a separate map "repo.newt_compatibility" in the repo's 
> repository.yml file.
> Example:
> {noformat}
> repo.newt_compatibility:
> 1.0.0:
> 1.1.0: error
> 1.0.0: good
> 0.9.99: warn
> 0.9.9: error
> {noformat}
> This says that this version 1.0.0 of this repo is compatible with newt 
> versions [1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a 
> warning message.  All other newt versions generate an error.



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

[jira] [Updated] (MYNEWT-655) newt - Detect repo / newt version incompatibilities

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-655:
---
Description: 
This is done with a separate map "repo.newt_compatibility" in the repo's 
repository.yml file.

Example:
{noformat}
repo.newt_compatibility:
1.0.0:
1.1.0: error
1.0.0: good
0.9.99: warn
0.9.9: error
{noformat}

This says that this version 1.0.0 of this repo is compatible with newt versions 
[1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a warning 
message.  All other newt versions generate an error.

  was:
This is done with a separate map "repo.newt_compatibility" in the repo's 
repository.yml file.

Example:
{noformat}
repo.newt_compatibility:
1.0.0:
1.1.0: error
1.0.0: good
0.9.99: warn
0.9.9: error
{noformat}

This says that this version 1.0.0 of this repo is compatible with newt versions 
[1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a warning 
message.  All other newt versions generate an error (unless the "-f" force 
option is specified).


> newt - Detect repo / newt version incompatibilities
> ---
>
> Key: MYNEWT-655
> URL: https://issues.apache.org/jira/browse/MYNEWT-655
> Project: Mynewt
>  Issue Type: Improvement
>    Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> This is done with a separate map "repo.newt_compatibility" in the repo's 
> repository.yml file.
> Example:
> {noformat}
> repo.newt_compatibility:
> 1.0.0:
> 1.1.0: error
> 1.0.0: good
> 0.9.99: warn
> 0.9.9: error
> {noformat}
> This says that this version 1.0.0 of this repo is compatible with newt 
> versions [1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a 
> warning message.  All other newt versions generate an error.



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

[jira] [Updated] (MYNEWT-655) newt - Detect repo / newt version incompatibilities

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-655:
---
Description: 
This is done with a separate map "repo.newt_compatibility" in the repo's 
repository.yml file.

Example:
{noformat}
repo.newt_compatibility:
1.0.0:
1.1.0: error
1.0.0: good
0.9.99: warn
0.9.9: error
{noformat}

This says that this version 1.0.0 of this repo is compatible with newt versions 
[1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a warning 
message.  All other newt versions generate an error (unless the "-f" force 
option is specified).

  was:
This is done with a separate map "" in the repo's repository.yml file.

Example:
{noformat}
repo.newt_compatibility:
1.0.0:
1.1.0: error
1.0.0: good
0.9.99: warn
0.9.9: error
{noformat}

This says that this version 1.0.0 of this repo is compatible with newt versions 
[1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a warning 
message.  All other newt versions generate an error (unless the "-f" force 
option is specified).


> newt - Detect repo / newt version incompatibilities
> ---
>
> Key: MYNEWT-655
> URL: https://issues.apache.org/jira/browse/MYNEWT-655
> Project: Mynewt
>      Issue Type: Improvement
>    Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> This is done with a separate map "repo.newt_compatibility" in the repo's 
> repository.yml file.
> Example:
> {noformat}
> repo.newt_compatibility:
> 1.0.0:
> 1.1.0: error
> 1.0.0: good
> 0.9.99: warn
> 0.9.9: error
> {noformat}
> This says that this version 1.0.0 of this repo is compatible with newt 
> versions [1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a 
> warning message.  All other newt versions generate an error (unless the "-f" 
> force option is specified).



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

[jira] [Created] (MYNEWT-655) newt - Detect repo / newt version incompatibilities

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-655:
--

 Summary: newt - Detect repo / newt version incompatibilities
 Key: MYNEWT-655
 URL: https://issues.apache.org/jira/browse/MYNEWT-655
 Project: Mynewt
  Issue Type: Improvement
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_1_0_rel


This is done with a separate map "" in the repo's repository.yml file.

Example:
{noformat}
repo.newt_compatibility:
1.0.0:
1.1.0: error
1.0.0: good
0.9.99: warn
0.9.9: error
{noformat}

This says that this version 1.0.0 of this repo is compatible with newt versions 
[1.0.0, 1.1.0).  Newt versions in the range [0.9.99, 1.0.0) elicit a warning 
message.  All other newt versions generate an error (unless the "-f" force 
option is specified).



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

[jira] [Resolved] (MYNEWT-654) datetime command may crash device

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-654.

Resolution: Fixed

> datetime command may crash device
> -
>
> Key: MYNEWT-654
> URL: https://issues.apache.org/jira/browse/MYNEWT-654
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> There are two issues here:
> 1. newtmgr tool always includes an extraneous rc:0 key-value pair in its 
> outgoing datetime commands.
> 2. Server-side, the firmware parses the "rc" value and writes the result to 
> null.
> The solutions are:
> 1. Remove the rc entry from the datetime request.
> 2. Don't attempt to parse the rc entry in incoming requests.



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

[jira] [Resolved] (MYNEWT-653) Change Golang imports from runtimeinc to runtimeco

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-653.

Resolution: Fixed

> Change Golang imports from runtimeinc to runtimeco
> --
>
> Key: MYNEWT-653
> URL: https://issues.apache.org/jira/browse/MYNEWT-653
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>




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

[jira] [Created] (MYNEWT-653) Change Golang imports from runtimeinc to runtimeco

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-653:
--

 Summary: Change Golang imports from runtimeinc to runtimeco
 Key: MYNEWT-653
 URL: https://issues.apache.org/jira/browse/MYNEWT-653
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_rel






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

[jira] [Resolved] (MYNEWT-492) System configuration needs to have descriptions

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-492.

Resolution: Fixed

> System configuration needs to have descriptions
> ---
>
> Key: MYNEWT-492
> URL: https://issues.apache.org/jira/browse/MYNEWT-492
> Project: Mynewt
>  Issue Type: Improvement
>Affects Versions: v1_0_0_beta1
>Reporter: Sterling Hughes
>        Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>




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

[jira] [Resolved] (MYNEWT-647) Changes to NMP over OIC scheme

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-647.

Resolution: Fixed

> Changes to NMP over OIC scheme
> --
>
> Key: MYNEWT-647
> URL: https://issues.apache.org/jira/browse/MYNEWT-647
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> This ticket was created to address the following three issues with NMP over 
> OIC (OMP):
> 1. Parts of NMP header missing from OMP responses.  This causes problems when 
> multiplexing OMP among many target devices.
> 2. Parts of the NMP header are scattered in a few different places.  This 
> works, but it makes it difficult to debug packet traces.
> 3. NMP errors get lost in translation.  Instead of an NMP message with an 
> error code, the OMP server sends back a generic "Bad Request" OICmessage.
> h4. Current Scheme
> h5. Requests
> The NMP op is indicated by the OIC op:
> NMP read <=> OIC get
> NMP write <=> OIC put
> The NMP group and ID are indicated as CoAP URI Query options:
> * {{gr=}}
> * {{id=}}
> The remaining NMP header fields, seq and flags, are not present.
> The NMP payload is the entire CoAP request body.  This is identical to the 
> body of a plain NMP request.
> h5. Responses
> The NMP header is not present.  The NMP op is indicated in the payload (see 
> below), but other header fields cannot be inferred.
> Payload consists of a single CBOR key-value pair.  For read responses, the 
> key is "r"; for write responses, the key is "w".  The value is a second CBOR 
> map containing the actual NMP response fields.
> Errors encountered during processing of NMP requests are reported via OIC  
> error responses (bad request, internal server error).
> h4. Proposed Scheme
> h5. Requests
> # The OIC op is always the same: put.
> # No URI Query CoAP options.
> # The NMP header is included in the payload as a key-value pair (key="_h").  
> This pair is in the root map of the request and is a sibling of the other 
> request fields.  The value of this pair is the big-endian eight-byte NMP 
> header with a length field of 0.
> h5. Responses
> * As with requests, the NMP header is included in the payload as a key-value 
> pair (key="_h").
> * No "r" or "w" field.  The response fields are inserted into the root map as 
> a sibling of the "_h" pair.
> * Errors encountered during processing of NMP requests are reported 
> identically to other NMP responses (embedded NMP response).
> h5. Notes
> * Keys that start with an underscore are reserved to the OIC manager protocol 
> (e.g., "_h").  NMP requests and responses must not name any of their fields 
> with a leading underscore.



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

[jira] [Commented] (MYNEWT-509) Linker script should limit image size to allow for trailer

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-509:


Unfortunately, I wasn't able to accomplish this with linker script 
modifications.  For completeness, here is what I tried:

h4. Reduce size of FLASH region by (tlvs-size + boot-trailer-size)
{noformat}
MEMORY
{
  FLASH (rx) : ORIGIN = 0x8000, LENGTH = 0x3a000 - _imgtlvs_size - 
_boot_trailer_size
  RAM (rwx) : ORIGIN = 0x2000, LENGTH = 0x1
}
{noformat}

Where _imgtlvs_size and _boot_trailer_size are linker script variables.  This 
elicits the following ld error:
{quote}
Error: /Users/ccollins/repos/mynewt/core/hw/bsp/nrf52dk/nrf52xxaa.ld:41: 
nonconstant expression for length
{quote}

_boot_trailer_size needs to be a variable because its value depends on the 
MCU's minimum flash write size.

h4. Create NOLOAD sections corresponding to the TLVs and boot trailer.
{noformat}
.imgtlvs (NOLOAD):
{
. = . + _imgtlvs_size;
} > FLASH
.boottrailer (NOLOAD):
{
. = . + _boot_trailer_size;
} > FLASH
{noformat}

This is what we do to reserve 32 bytes for the image header.  Sadly, this 
doesn't work in this case.  Since these sections don't come at the start of the 
image (they are at the end), they are zero-filled in the generated binary.  
This is obviously not what we want.  We need these sections to be unwritten.

h4. Adjust the location counter by hand
{noformat}
__exidx_end = .;

. += _imgtlvs_size;
. += _boot_trailer_size;

__etext = .;
{noformat}

This works in that __etext gets the correct value.  Unfortunately, ld does not 
report an error when these adjustments push the location counter beyond the end 
of flash.  The linker only seems to report an error if it tries to place a 
section outside the bounds of the region.


> Linker script should limit image size to allow for trailer
> --
>
> Key: MYNEWT-509
> URL: https://issues.apache.org/jira/browse/MYNEWT-509
> Project: Mynewt
>  Issue Type: Bug
>        Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>




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

[jira] [Updated] (MYNEWT-647) Changes to NMP over OIC scheme

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-647:
---
Description: 
This ticket was created to address the following three issues with NMP over OIC 
(OMP):

1. Parts of NMP header missing from OMP responses.  This causes problems when 
multiplexing OMP among many target devices.
2. Parts of the NMP header are scattered in a few different places.  This 
works, but it makes it difficult to debug packet traces.
3. NMP errors get lost in translation.  Instead of an NMP message with an error 
code, the OMP server sends back a generic "Bad Request" OICmessage.

h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The NMP payload is the entire CoAP request body.  This is identical to the body 
of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read responses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

Errors encountered during processing of NMP requests are reported via OIC  
error responses (bad request, internal server error).

h4. Proposed Scheme

h5. Requests

# The OIC op is always the same: put.
# No URI Query CoAP options.
# The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requests, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.
* Errors encountered during processing of NMP requests are reported identically 
to other NMP responses (embedded NMP response).

h5. Notes

* Keys that start with an underscore are reserved to the OIC manager protocol 
(e.g., "_h").  NMP requests and responses must not name any of their fields 
with a leading underscore.

  was:
h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The NMP payload is the entire CoAP request body.  This is identical to the body 
of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read responses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

Errors encountered during processing of NMP requests are reported via OIC  
error responses (bad request, internal server error).

h4. Proposed Scheme

h5. Requests

* The OIC op is always the same: put.
* No URI Query CoAP options.
* The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requests, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.
* Errors encountered during processing of NMP requests are reported identically 
to other NMP responses (embedded NMP response).

h5. Notes

* Keys that start with an underscore are reserved to the OIC manager protocol 
(e.g., "_h").  NMP requests and responses must not name any of their fields 
with a leading underscore.


> Changes to NMP over OIC scheme
> --
>
>     Key: MYNEWT-647
> URL: https://issues.apache.org/jira/browse/MYNEWT-647
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> This ticket was created to address the following three issues with NMP over 
> OIC (OMP):
> 1. Parts of NMP header missing fro

NMP over OIC

[Christopher Collins]

Hello all,

I encountered some issues while using the newtmgr protocol (NMP) over
OIC.  In this email, I will call this protocol stack (NMP over OIC) OMP.
The issues, as I see them, are:

1. Parts of NMP header missing from OMP responses.  This causes problems
when multiplexing OMP among many target devices.

2. Parts of the NMP header are scattered in a few different places.
This works, but it makes it difficult to debug packet traces.

3. NMP errors get lost in translation.  Instead of an NMP message with
an error code, the OMP server sends back a generic "Bad Request" OIC
message.

I have addressed these issues in the following proposal:
https://issues.apache.org/jira/browse/MYNEWT-647

If you're like me, you might not bother reading something unless it is
reproduced in the email body :).  The contents of the aforementioned jira
ticket are below.

Comments welcome.

Thanks,
Chris

--

* Current Scheme

*** Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:

gr=
id=

The remaining NMP header fields, seq and flags, are not present.

The NMP payload is the entire CoAP request body. This is identical to the body
of a plain NMP request.

*** Responses

The NMP header is not present. The NMP op is indicated in the payload (see
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair. For read responses, the key
is "r"; for write responses, the key is "w". The value is a second CBOR map
containing the actual NMP response fields.

Errors encountered during processing of NMP requests are reported via OIC error
responses (bad request, internal server error).

* Proposed Scheme

*** Requests

* The OIC op is always the same: put.

* No URI Query CoAP options.

* The NMP header is included in the payload as a key-value pair (key="_h").
  This pair is in the root map of the request and is a sibling of the other
  request fields. The value of this pair is the big-endian eight-byte NMP
  header with a length field of 0.

*** Responses

* As with requests, the NMP header is included in the payload as a
  key-value pair (key="_h").

* No "r" or "w" field. The response fields are inserted into the root map
  as a sibling of the "_h" pair.

* Errors encountered during processing of NMP requests are reported
  identically to other NMP responses (embedded NMP response).

*** Notes

* Keys that start with an underscore are reserved to the OIC manager
  protocol (e.g., "_h"). NMP requests and responses must not name any of
  their fields with a leading underscore.

[jira] [Updated] (MYNEWT-647) Changes to NMP over OIC scheme

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-647:
---
Description: 
h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The NMP payload is the entire CoAP request body.  This is identical to the body 
of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read responses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

Errors encountered during processing of NMP requests are reported via OIC  
error responses (bad request, internal server error).

h4. Proposed Scheme

h5. Requests

* The OIC op is always the same: put.
* No URI Query CoAP options.
* The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requets, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.
* Errors encountered during processing of NMP requests are reported identically 
to other NMP responses (embedded NMP response).

h5. Notes

* Keys that start with an underscore are reserved to the OIC manager protocol 
(e.g., "_h").  NMP requests and responses must not name any of their fields 
with a leading underscore.

  was:
h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The payload is the CBOR encoding the the request body.  This is identical to 
the body of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read responses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

Errors encountered during processing of NMP requests are reported via OIC  
error responses (bad request, internal server error).

h4. Proposed Scheme

h5. Requests

* The OIC op is always the same: put.
* No URI Query CoAP options.
* The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requets, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.
* Errors encountered during processing of NMP requests are reported identically 
to other NMP responses (embedded NMP response).

h5. Notes

* Keys that start with an underscore are reserved to the OIC manager protocol 
(e.g., "_h").  NMP requests and responses must not name any of their fields 
with a leading underscore.


> Changes to NMP over OIC scheme
> --
>
> Key: MYNEWT-647
>     URL: https://issues.apache.org/jira/browse/MYNEWT-647
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> h4. Current Scheme
> h5. Requests
> The NMP op is indicated by the OIC op:
> NMP read <=> OIC get
> NMP write <=> OIC put
> The NMP group and ID are indicated as CoAP URI Query options:
> * {{gr=}}
> * {{id=}}
> The remaining NMP header fields, seq and flags, are not present.
> The NMP payload is the entire CoAP request body.  This is identical to the 
> body of a plain NMP request.
> h5. Responses
> The NMP header is not present.  The NMP op is indicated in the payload (see 
> below), but other header fields cannot be inferred.
> Payload consists of a single CBOR key-value

[jira] [Updated] (MYNEWT-647) Changes to NMP over OIC scheme

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-647:
---
Description: 
h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The NMP payload is the entire CoAP request body.  This is identical to the body 
of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read responses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

Errors encountered during processing of NMP requests are reported via OIC  
error responses (bad request, internal server error).

h4. Proposed Scheme

h5. Requests

* The OIC op is always the same: put.
* No URI Query CoAP options.
* The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requests, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.
* Errors encountered during processing of NMP requests are reported identically 
to other NMP responses (embedded NMP response).

h5. Notes

* Keys that start with an underscore are reserved to the OIC manager protocol 
(e.g., "_h").  NMP requests and responses must not name any of their fields 
with a leading underscore.

  was:
h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The NMP payload is the entire CoAP request body.  This is identical to the body 
of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read responses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

Errors encountered during processing of NMP requests are reported via OIC  
error responses (bad request, internal server error).

h4. Proposed Scheme

h5. Requests

* The OIC op is always the same: put.
* No URI Query CoAP options.
* The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requets, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.
* Errors encountered during processing of NMP requests are reported identically 
to other NMP responses (embedded NMP response).

h5. Notes

* Keys that start with an underscore are reserved to the OIC manager protocol 
(e.g., "_h").  NMP requests and responses must not name any of their fields 
with a leading underscore.


> Changes to NMP over OIC scheme
> --
>
> Key: MYNEWT-647
>     URL: https://issues.apache.org/jira/browse/MYNEWT-647
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> h4. Current Scheme
> h5. Requests
> The NMP op is indicated by the OIC op:
> NMP read <=> OIC get
> NMP write <=> OIC put
> The NMP group and ID are indicated as CoAP URI Query options:
> * {{gr=}}
> * {{id=}}
> The remaining NMP header fields, seq and flags, are not present.
> The NMP payload is the entire CoAP request body.  This is identical to the 
> body of a plain NMP request.
> h5. Responses
> The NMP header is not present.  The NMP op is indicated in the payload (see 
> below), but other header fields cannot be inferred.
> Payload consists of a single CBOR key-value

[jira] [Resolved] (MYNEWT-650) fs/fs/test build errors for non-native platforms

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-650.

Resolution: Fixed

> fs/fs/test build errors for non-native platforms
> 
>
> Key: MYNEWT-650
> URL: https://issues.apache.org/jira/browse/MYNEWT-650
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> E.g.,
> {noformat}
> fs/nffs/test/src/nffs_test_debug.c:68:12: error: format '%d' expects argument 
> of type 'int', but argument 5 has type 'uint32_t' [-Werror=format=]
> inode.ni_seq, inode.ni_inode_entry->nie_flags);
> ^
> fs/nffs/test/src/nffs_test_debug.c: In function 'print_nffs_flash_inode':
> fs/nffs/test/src/nffs_test_debug.c:112:12: error: format '%x' expects 
> argument of type 'unsigned int', but argument 2 has type 'uint32_t' 
> [-Werror=format=]
> filename);
> ^
> fs/nffs/test/src/nffs_test_debug.c:112:12: error: format '%x' expects 
> argument of type 'unsigned int', but argument 4 has type 'uint32_t' 
> [-Werror=format=]
> fs/nffs/test/src/nffs_test_debug.c:112:12: error: format '%x' expects 
> argument of type 'unsigned int', but argument 7 has type 'uint32_t' 
> [-Werror=format=]
> fs/nffs/test/src/nffs_test_debug.c:112:12: error: format '%x' expects 
> argument of type 'unsigned int', but argument 8 has type 'uint32_t' 
> [-Werror=format=]
> fs/nffs/test/src/nffs_test_debug.c: In function 'print_nffs_flash_block':
> fs/nffs/test/src/nffs_test_debug.c:132:12: error: format '%x' expects 
> argument of type 'unsigned int', but argument 2 has type 'uint32_t' 
> [-Werror=format=]
> ndb.ndb_inode_id);
> {noformat}
> The problem is that the fixed-size integer types map to different "natural" 
> integer types, depending on the target platform.  Unfortunately, the PRIxxx 
> macros in inttypes.h don't work here, since gcc assumes no cross compile when 
> it generates the warning.  The next best solution is to cast everything to 
> uintmax_t and apply the {{j}} format specifier.



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

[jira] [Updated] (MYNEWT-647) Changes to NMP over OIC scheme

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-647:
---
Description: 
h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The payload is the CBOR encoding the the request body.  This is identical to 
the body of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read responses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

Errors encountered during processing of NMP requests are reported via OIC  
error responses (bad request, internal server error).

h4. Proposed Scheme

h5. Requests

* The OIC op is always the same: put.
* No URI Query CoAP options.
* The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requets, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.
* Errors encountered during processing of NMP requests are reported identically 
to other NMP responses (embedded NMP response).

h5. Notes

* Keys that start with an underscore are reserved to the OIC manager protocol 
(e.g., "_h").  NMP requests and responses must not name any of their fields 
with a leading underscore.

  was:
h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The payload is the CBOR encoding the the request body.  This is identical to 
the body of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read resonses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

h4. Proposed Scheme

h5. Requests

* The OIC op is always the same: put.
* No URI Query CoAP options.
* The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requets, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.

h5. Notes

* Keys that start with an underscore are reserved to the OIC manager protocol 
(e.g., "_h").  NMP requests and responses must not name any of their fields 
with a leading underscore.


> Changes to NMP over OIC scheme
> --
>
> Key: MYNEWT-647
>     URL: https://issues.apache.org/jira/browse/MYNEWT-647
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> h4. Current Scheme
> h5. Requests
> The NMP op is indicated by the OIC op:
> NMP read <=> OIC get
> NMP write <=> OIC put
> The NMP group and ID are indicated as CoAP URI Query options:
> * {{gr=}}
> * {{id=}}
> The remaining NMP header fields, seq and flags, are not present.
> The payload is the CBOR encoding the the request body.  This is identical to 
> the body of a plain NMP request.
> h5. Responses
> The NMP header is not present.  The NMP op is indicated in the payload (see 
> below), but other header fields cannot be inferred.
> Payload consists of a single CBOR key-value pair.  For read responses, the 
> key is "r"; for write responses, the key is "w".  The value is a second CBOR 
> map containing the actual NMP response fields.
> Errors encountered during processing of NMP requests are

[jira] [Updated] (MYNEWT-647) Changes to NMP over OIC scheme

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-647:
---
Description: 
h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The payload is the CBOR encoding the the request body.  This is identical to 
the body of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read resonses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

h4. Proposed Scheme

h5. Requests

* The OIC op is always the same: put.
* No URI Query CoAP options.
* The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requets, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.

h5. Notes

* Keys that start with an underscore are reserved to the OIC manager protocol 
(e.g., "_h").  NMP requests and responses must not name any of their fields 
with a leading underscore.

  was:
h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The payload is the CBOR encoding the the request body.  This is identical to 
the body of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read resonses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

h4. Proposed Scheme

h5. Requests

* The OIC op is always the same: put.
* No URI Query CoAP options.
* The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requets, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.


> Changes to NMP over OIC scheme
> --
>
> Key: MYNEWT-647
>     URL: https://issues.apache.org/jira/browse/MYNEWT-647
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> h4. Current Scheme
> h5. Requests
> The NMP op is indicated by the OIC op:
> NMP read <=> OIC get
> NMP write <=> OIC put
> The NMP group and ID are indicated as CoAP URI Query options:
> * {{gr=}}
> * {{id=}}
> The remaining NMP header fields, seq and flags, are not present.
> The payload is the CBOR encoding the the request body.  This is identical to 
> the body of a plain NMP request.
> h5. Responses
> The NMP header is not present.  The NMP op is indicated in the payload (see 
> below), but other header fields cannot be inferred.
> Payload consists of a single CBOR key-value pair.  For read resonses, the key 
> is "r"; for write responses, the key is "w".  The value is a second CBOR map 
> containing the actual NMP response fields.
> h4. Proposed Scheme
> h5. Requests
> * The OIC op is always the same: put.
> * No URI Query CoAP options.
> * The NMP header is included in the payload as a key-value pair (key="_h").  
> This pair is in the root map of the request and is a sibling of the other 
> request fields.  The value of this pair is the big-endian eight-byte NMP 
> header with a length field of 0.
> h5. Responses
> * As with requets, the NMP header is included in the payload as a key-value 
> pair (ke

[jira] [Created] (MYNEWT-647) Changes to NMP over OIC scheme

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-647:
--

 Summary: Changes to NMP over OIC scheme
 Key: MYNEWT-647
 URL: https://issues.apache.org/jira/browse/MYNEWT-647
 Project: Mynewt
  Issue Type: Bug
  Components: Newtmgr
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_rel


h4. Current Scheme

h5. Requests

The NMP op is indicated by the OIC op:
NMP read <=> OIC get
NMP write <=> OIC put

The NMP group and ID are indicated as CoAP URI Query options:
* {{gr=}}
* {{id=}}

The remaining NMP header fields, seq and flags, are not present.

The payload is the CBOR encoding the the request body.  This is identical to 
the body of a plain NMP request.

h5. Responses

The NMP header is not present.  The NMP op is indicated in the payload (see 
below), but other header fields cannot be inferred.

Payload consists of a single CBOR key-value pair.  For read resonses, the key 
is "r"; for write responses, the key is "w".  The value is a second CBOR map 
containing the actual NMP response fields.

h4. Proposed Scheme

h5. Requests

* The OIC op is always the same: put.
* No URI Query CoAP options.
* The NMP header is included in the payload as a key-value pair (key="_h").  
This pair is in the root map of the request and is a sibling of the other 
request fields.  The value of this pair is the big-endian eight-byte NMP header 
with a length field of 0.


h5. Responses

* As with requets, the NMP header is included in the payload as a key-value 
pair (key="_h").
* No "r" or "w" field.  The response fields are inserted into the root map as a 
sibling of the "_h" pair.



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

[jira] [Resolved] (MYNEWT-572) newtmgr reset command succeeds under the hood, yet fails to recover

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-572.

Resolution: Not A Problem

> newtmgr reset command succeeds under the hood, yet fails to recover
> ---
>
> Key: MYNEWT-572
> URL: https://issues.apache.org/jira/browse/MYNEWT-572
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
> Environment: develop branch
> macos
> nrf51-16kbram target
>Reporter: Jacob
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The reset after image confirm is successful, but newtmgr is having trouble 
> recovering from the command:
> Ive seen it error like this:
> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr reset -cserial1 
> -t -ldebug
> 2017/01/25 17:13:31 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:2 
> Group:0 Seq:0 Id:5 Data:[123 125]}
> 2017/01/25 17:13:31 [DEBUG] Serializing request &{Op:2 Flags:0 Len:2 Group:0 
> Seq:0 Id:5 Data:[123 125]} into buffer [2 0 0 2 0 0 0 5 123 125]
> 2017/01/25 17:13:31 [DEBUG] Tx packet dump:
>   02 00 00 02 00 00 00 05  7b 7d|{}|
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   06 09 |..|
> 2017/01/25 17:13:31 [DEBUG] Writing [6 9] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   41 41 77 43 41 41 41 43  41 41 41 41 42 58 74 39  |AAwCAAACBXt9|
> 0010  4c 67 41 3d   |LgA=|
> 2017/01/25 17:13:31 [DEBUG] Writing [65 65 119 67 65 65 65 67 65 65 65 65 66 
> 88 116 57 76 103 65 61] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   0a|.|
> 2017/01/25 17:13:31 [DEBUG] Writing [10] to data channel
> 2017/01/25 17:13:44 [INFO] Incoming:
>   06 09 41 41 77 43 41 41  41 43 41 41 41 41 42 58  |..AAwCAAACBX|
> 0010  74 39 4c 67 41 3d 31 3a   |t9LgA=1:|
> 2017/01/25 17:13:44 [DEBUG] Reading [6 9 65 65 119 67 65 65 65 67 65 65 65 65 
> 66 88 116 57 76 103 65 61 49 58] from data channel
> 2017/01/25 17:13:44 [INFO] Message: base64 decode error
> 2017/01/25 17:13:44 [DEBUG] goroutine 1 [running]:
> mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util.NewNewtError(0xc420160380,
>  0xdd, 0xc42004bb50)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util/util.go:75
>  +0x111
> mynewt.apache.org/newt/newtmgr/transport.(*ConnSerial).ReadPacket(0xc420140870,
>  0xc420146c00, 0x4080a8a, 0xc420140870)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/transport/connserial.go:149
>  +0x7b2
> mynewt.apache.org/newt/newtmgr/protocol.(*CmdRunner).ReadResp(0xc42015f210, 
> 0xc4201468c0, 0x0, 0x0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/protocol/cmdrunner.go:42
>  +0x9c
> mynewt.apache.org/newt/newtmgr/cli.resetRunCmd(0xc42016c240, 0xc420140630, 
> 0x0, 0x3)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/cli/reset.go:50
>  +0x1ab
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).execute(0xc42016c240,
>  0xc420140480, 0x3, 0x3, 0xc42016c240, 0xc420140480)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:636
>  +0x443
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420166000,
>  0xc420166b40, 0xc420166240, 0xc42015eec0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:722
>  +0x367
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420166000,
>  0x40d65bc, 0xc421a0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:681
>  +0x2b
> main.main()
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/newtmgr.go:25 
> +0x2f
> goroutine 17 [syscall, locked to thread]:
> runtime.goexit()
>   /usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/asm_amd64.s:2086 +0x1
> goroutine 5 [syscall]:
> os/signal.signal_recv(0x0)
>   /usr/local/Cellar/go/1.7.4_1/libexec/src/runtime/sigqueue.go:116 +0x157
> os/signal.loop()
>   /usr/local/Cellar/go/1.7.4_1/libexec/src/os/signal/signal_unix.go:22 
> +0x22
> created by os/signal.init.1
>   /usr/local/Cellar/

[jira] [Commented] (MYNEWT-572) newtmgr reset command succeeds under the hood, yet fails to recover

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-572:


Hi Jacob,

Are you possibly using the virtual COM port (UART via USB) with a Nordic 
device?  In its default config, a Nordic device can only receive 64 bytes at a 
time through this port.  You can lift this restriction with a one time command 
entered in JLinkExe.  The command is: {{MSDDisable}}.

There is some more information here: 
https://wiki.segger.com/index.php?title=J-Link-OB_SAM3U


> newtmgr reset command succeeds under the hood, yet fails to recover
> ---
>
> Key: MYNEWT-572
> URL: https://issues.apache.org/jira/browse/MYNEWT-572
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newtmgr
> Environment: develop branch
> macos
> nrf51-16kbram target
>Reporter: Jacob
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The reset after image confirm is successful, but newtmgr is having trouble 
> recovering from the command:
> Ive seen it error like this:
> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$ newtmgr reset -cserial1 
> -t -ldebug
> 2017/01/25 17:13:31 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:2 
> Group:0 Seq:0 Id:5 Data:[123 125]}
> 2017/01/25 17:13:31 [DEBUG] Serializing request &{Op:2 Flags:0 Len:2 Group:0 
> Seq:0 Id:5 Data:[123 125]} into buffer [2 0 0 2 0 0 0 5 123 125]
> 2017/01/25 17:13:31 [DEBUG] Tx packet dump:
>   02 00 00 02 00 00 00 05  7b 7d|{}|
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   06 09 |..|
> 2017/01/25 17:13:31 [DEBUG] Writing [6 9] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   41 41 77 43 41 41 41 43  41 41 41 41 42 58 74 39  |AAwCAAACBXt9|
> 0010  4c 67 41 3d   |LgA=|
> 2017/01/25 17:13:31 [DEBUG] Writing [65 65 119 67 65 65 65 67 65 65 65 65 66 
> 88 116 57 76 103 65 61] to data channel
> 2017/01/25 17:13:31 [INFO] Outgoing:
>   0a|.|
> 2017/01/25 17:13:31 [DEBUG] Writing [10] to data channel
> 2017/01/25 17:13:44 [INFO] Incoming:
>   06 09 41 41 77 43 41 41  41 43 41 41 41 41 42 58  |..AAwCAAACBX|
> 0010  74 39 4c 67 41 3d 31 3a   |t9LgA=1:|
> 2017/01/25 17:13:44 [DEBUG] Reading [6 9 65 65 119 67 65 65 65 67 65 65 65 65 
> 66 88 116 57 76 103 65 61 49 58] from data channel
> 2017/01/25 17:13:44 [INFO] Message: base64 decode error
> 2017/01/25 17:13:44 [DEBUG] goroutine 1 [running]:
> mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util.NewNewtError(0xc420160380,
>  0xdd, 0xc42004bb50)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util/util.go:75
>  +0x111
> mynewt.apache.org/newt/newtmgr/transport.(*ConnSerial).ReadPacket(0xc420140870,
>  0xc420146c00, 0x4080a8a, 0xc420140870)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/transport/connserial.go:149
>  +0x7b2
> mynewt.apache.org/newt/newtmgr/protocol.(*CmdRunner).ReadResp(0xc42015f210, 
> 0xc4201468c0, 0x0, 0x0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/protocol/cmdrunner.go:42
>  +0x9c
> mynewt.apache.org/newt/newtmgr/cli.resetRunCmd(0xc42016c240, 0xc420140630, 
> 0x0, 0x3)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/cli/reset.go:50
>  +0x1ab
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).execute(0xc42016c240,
>  0xc420140480, 0x3, 0x3, 0xc42016c240, 0xc420140480)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:636
>  +0x443
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420166000,
>  0xc420166b40, 0xc420166240, 0xc42015eec0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:722
>  +0x367
> mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420166000,
>  0x40d65bc, 0xc421a0)
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/vendor/github.com/spf13/cobra/command.go:681
>  +0x2b
> main.main()
>   
> /Users/jacobrosenthal/dev/go/src/mynewt.apache.org/newt/newtmgr/newtmgr.go:25 
> +0x2f
> goroutine 17 [syscall, locked to thread]:
> runtime.goexit()
&g

[jira] [Resolved] (MYNEWT-645) Blinky - Point to latest compatible apache-mynewt-core

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-645.

Resolution: Fixed

> Blinky - Point to latest compatible apache-mynewt-core
> --
>
> Key: MYNEWT-645
> URL: https://issues.apache.org/jira/browse/MYNEWT-645
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> Currently, blinky points to 0-latest.  This means "newt install" downloads 
> the latest core release.  This could cause problems if newt or core changes 
> in an incompatible way.  Instead, blinky should point to 1-latest (latest 
> 1.x.x).



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

[jira] [Created] (MYNEWT-645) Blinky - Point to latest compatible apache-mynewt-core

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-645:
--

 Summary: Blinky - Point to latest compatible apache-mynewt-core
 Key: MYNEWT-645
 URL: https://issues.apache.org/jira/browse/MYNEWT-645
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins


Currently, blinky points to 0-latest.  This means "newt install" downloads the 
latest core release.  This could cause problems if newt or core changes in an 
incompatible way.  Instead, blinky should point to 1-latest (latest 1.x.x).



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

Re: issue with FCB reboot logs

[Christopher Collins]

Hi Szymon,

On Tue, Feb 28, 2017 at 03:51:51PM +0100, Szymon Janc wrote:
> Hi,
> 
> I noticed that some applications (eg bleprhp) enable FCB logging in
> syscfg.yml by default.
> When flashing such sample on nRF52DK I get assertion [1] before even
> main() is reached.
> And if I reset a board I get loop of assert and unhandled interrupt
> exception [2].
> 
> Disabling FCB makes sample works fine. Do I need to do any magic to
> get it working
> with FCB enabled?

My guess is that there is something else written to the reboot log area.
I believe the reboot log package asserts that it initializes
successfully.  Do you know what code is at the indicated address
(0x1a393)?

This would be the case if it has been a long time since you erased your
device's flash.  The flash map changed in an non-backwards-compatible
way between 0.9.0 and 1.0.0-b1.

> Also, should those be enabled by default in samples in first place?

Yes, that is probably a good idea IMO.

Chris

> 
> [1]
> 1:Assert @ 0x1a393
> 
> [2]
> 1:Assert @ 0x1a38b
> 1:Unhandled interrupt (2), exception sp 0x2ba0
> 1: r0:0x  r1:0x  r2:0x8000  r3:0xe000ed00
> 1: r4:0x0001a38b  r5:0x  r6:0x  r7:0x
> 1: r8:0x  r9:0x r10:0x r11:0x
> 1:r12:0x  lr:0x8875  pc:0x8884 psr:0x61000200
> 1:ICSR:0x00421802 HFSR:0x CFSR:0x
> 1:BFAR:0xe000ed38 MMFAR:0xe000ed34
> 1:Assert @ 0x1a38b
> 1:Unhandled interrupt (2), exception sp 0x2ba0
> 1: r0:0x  r1:0x  r2:0x8000  r3:0xe000ed00
> 1: r4:0x0001a38b  r5:0x  r6:0x  r7:0x
> 1: r8:0x  r9:0x r10:0x r11:0x
> 1:r12:0x  lr:0x8875  pc:0x8884 psr:0x61000200
> 1:ICSR:0x00421802 HFSR:0x CFSR:0x
> 1:BFAR:0xe000ed38 MMFAR:0xe000ed34
> 
> 
> -- 
> pozdrawiam
> Szymon K. Janc

[jira] [Resolved] (MYNEWT-642) Eddystone UID format is incorrect

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-642.

Resolution: Fixed

> Eddystone UID format is incorrect
> -
>
> Key: MYNEWT-642
> URL: https://issues.apache.org/jira/browse/MYNEWT-642
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>Affects Versions: v1_0_0_beta2
>Reporter: Simon Ratner
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The format of the eddystone beacon, as generated by 
> `ble_eddystone_set_adv_data_uid`, is incorrect.
> According to https://github.com/google/eddystone/tree/master/eddystone-uid, 
> the UID frame starts with 0x00, followed by calibrated rssi at 0m, followed 
> by the 16 byte uid, and finally 2 zero bytes to pad to the full 31 bytes.
> By comparison, `ble_eddystone_set_adv_data_url` seems to be doing the right 
> thing.



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

[jira] [Updated] (MYNEWT-642) Eddystone UID format is incorrect

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-642:
---
Affects Version/s: (was: v1_0_0_rel)
   v1_0_0_beta2
Fix Version/s: v1_0_0_rel

> Eddystone UID format is incorrect
> -
>
> Key: MYNEWT-642
> URL: https://issues.apache.org/jira/browse/MYNEWT-642
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>Affects Versions: v1_0_0_beta2
>Reporter: Simon Ratner
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The format of the eddystone beacon, as generated by 
> `ble_eddystone_set_adv_data_uid`, is incorrect.
> According to https://github.com/google/eddystone/tree/master/eddystone-uid, 
> the UID frame starts with 0x00, followed by calibrated rssi at 0m, followed 
> by the 16 byte uid, and finally 2 zero bytes to pad to the full 31 bytes.
> By comparison, `ble_eddystone_set_adv_data_url` seems to be doing the right 
> thing.



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

[jira] [Resolved] (MYNEWT-579) Nimble - Mbuf leak

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-579.

Resolution: Fixed

It appears the commit applied against this ticket fixes the problem.  We will 
reopen this if the mbuf leak returns.

> Nimble - Mbuf leak
> --
>
> Key: MYNEWT-579
> URL: https://issues.apache.org/jira/browse/MYNEWT-579
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
> Attachments: msys_1_2017-02-27.png
>
>
> This leak is possibly caused by (simultaneous) advertising and scanning.  See 
> attached graph captured by Simon.



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

Re: Package custom build steps

[Christopher Collins]

Hi Simon,

On Sun, Feb 26, 2017 at 01:31:39PM -0800, Simon Ratner wrote:
> Hi devs,
> 
> I have a package that requires a custom build step (generating intermediate
> files). Any recommendations on how to best handle this?
> 
> Currently I am doing the custom step from my top-level makefile, before
> invoking `newt build`, but that doesn't seem ideal.

I don't think there is currently any better way than what you are
currently doing (generating the files via make).  This is definitely
something that is missing from newt.

It might take some thought to get something like this right.  For now
I'll just throw an idea out there:

Two new settings in the target.yml file:
o target.pre_run
o target.post_run

Each specifies a sequence of executable pathnames.  The pre_run commands
get executed before newt builds anything; the post_run commands are
exected after everything gets built.  If any executable fails, the build
fails.

Chris

[jira] [Commented] (MYNEWT-293) Newt should make it easier to make custom packages

[Christopher Collins (JIRA)]

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

Christopher Collins commented on MYNEWT-293:


Should `pkg clone` be renamed to `pkg copy`?  This would be consistent with the 
`target copy` command.

> Newt should make it easier to make custom packages
> --
>
> Key: MYNEWT-293
> URL: https://issues.apache.org/jira/browse/MYNEWT-293
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Newt
>Affects Versions: v1_0_0_beta1
>Reporter: Sterling Hughes
>Assignee: Fabio Utzig
> Fix For: v1_0_0_rel
>
>
> There are a few issues with current newt package creation: 
> - It's opaque as to how to create a local package in a project.  
> - Need to add two options: 
> - newt pkg new : create a new package in the current directory, 
> with a basic template
> - newt pkg clone  : Clone an existing package 
> into the currnet directory.
> - Currently, there must be an exact match on repository descriptor, or the 
> newt tool will barf.  This should be smarter -- 
>   - If it can't resolve a dependency in the local project, it should look at 
> the current project/workspace, and try to resolve the package
>   - It should issue a warning if it can't find the package.
> - Currently pkg.name and the name of the package directory can not match, and 
> the pkg.name will be taken over the pkg directory.  There should be a warning 
> issued if the package directory does not match the package name.



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

Re: BLE HCI support on NRF52DK

[Christopher Collins]

Hi Alan,

On Sat, Feb 25, 2017 at 12:21:15AM +, Alan Graves wrote:
> Well my conclusion is that the HCI mode is frustrating at best to use on the 
> BlueZ stack!  
> 
> In my initial attempts to talk to the controller I use this command:
> $ sudo btmgmt --index 1
> [sudo] password for alan: 
> [hci1]#
> 
> First thing I noticed is that the MyNewt HCI mode tutorial says to set the 
> static address:
> [hci1]# static-addr cc:00:00:00:00:00
> Set static address failed with status 0x0b (Rejected)

I believe you can only configure an address while the controller is
"powered off" (scare quotes because the board doesn't actually have to
be powered off, BlueZ just has to consider it to be in the powered off
state).  Try the following from btmgmt:

power off
static-addr cc:00:00:00:00:00
power on

> This doesn't work on my system. I'm not sure what the problem is, but
> perhaps the initial BT addr 00:00:00:00:00:00 is a clue?

The all-zero address indicates that your controller is not configured
with a public address.  With no public address and no random address
you are pretty restricted in what you can do.

Hopefully this resolves some of the issues you're seeing.  I'm afraid my
knowledge of BlueZ is pretty poor, so I can't say if there is any issue
with the C program

Chris

Re: image upload error 2

[Christopher Collins]

On Fri, Feb 24, 2017 at 09:39:37AM +0800, then yon wrote:
> Dear Chris,
> 
> i've double enter on each line but it still mix up into 1 line, most 
> probably is my email sw problem.
> 
> Below is all the step i did:
> 
> 1. By using slinky app(no changes); build a split_slinky target.

Stop right there :).  What are you using for a loader and what are you
using for an app?

Chris

Re: image upload error 2

[Christopher Collins]

On Thu, Feb 23, 2017 at 06:05:44PM +0800, then yon wrote:
> Dear Chris,
> 
> Yes, i've followed the step you given; but after step 2 it gave me 
> "Error: Timeout reading from serial connection".
> 
> It only recover after i reset nrf52dk power and it show the result i 
> sent to you previously.
> 
> And when i tried to do step 1 again, it gave me "Error:  rc=6"

Is there anything you can do to preserve the newtmgr output in your
emails?  For some reason, the entire newtmgr response gets joined into a
single line, making it difficult to read.  I have reformatted the
responses below.

$ newtmgr -c mynewt_serial image list
Images:
  slot=0
version: 1.0.0
bootable: true
flags: active confirmed
hash: 6d1b9bb73f9cf223145a28e4e0d7702a1b2aaf60a7a6d66497e02a841cd72c8c
  slot=1
version: 1.0.0
bootable: false
flags:
hash: 0fd6f020a3ff70d4cd150e6233185c6e9b8b93f60af97fb67bc728daa6573f0b
Split status: matching

The empty flags field in slot 1 indicates that the device is in
loader-only mode (i.e., only slot 0 is running).  It appears you have
completed step 3.  With slot 1 unused, you can overwrite it with a new
app.

$ newtmgr -c mynewt_serial image test 
0fd6f020a3ff70d4cd150e6233185c6e9b8b93f60af97fb67bc728daa6573f0b
Images:
  slot=0
version: 1.0.0
bootable: true
flags: active confirmed
hash: 6d1b9bb73f9cf223145a28e4e0d7702a1b2aaf60a7a6d66497e02a841cd72c8c
  slot=1
version: 1.0.0
bootable: false
flags: pending
hash: 0fd6f020a3ff70d4cd150e6233185c6e9b8b93f60af97fb67bc728daa6573f0b
Split status: matching

The "test" command does not come until step 5.  What about step 4,
uploading the new loader?  By testing the original app image, you will
just put the device back into its original state.

$ newtmgr -c mynewt_serial reset
Done

$ newtmgr -c mynewt_serial image list  ^C (cause it hang here indefinitely 
so i cancel it)

It seems like your app (slot 1) doesn't support newtmgr or lacks a
newtmgr transport.

$ newtmgr -c mynewt_serial image upload splitty.img
Error: Timeout reading from serial connection
[...]

Which procedure are you following?  In the split upgrade procedure (the
one I pasted in my previous email), you only upload after issuing the
"image confirm" command.

Can you please do the following:

1. Tell me something about the target you are upgrading.  What loader
and app combo are you using?  From the above, it appears your app may
not support newtmgr.

2. Start from step 1 in the procedure I quoted, please indicate which
step you are currently on, and don't skip any steps :).

Thanks,
Chris

> 
> $ newtmgr -c mynewt_serial image list Images:  slot=0  version: 1.0.0 
> <http://1.0.0.0/> bootable: true  flags: active confirmed  hash: 
> 6d1b9bb73f9cf223145a28e4e0d7702a1b2aaf60a7a6d66497e02a841cd72c8c  slot=1 
>   version: 1.0.0 <http://1.0.0.0/> bootable: false  flags: hash: 
> 0fd6f020a3ff70d4cd150e6233185c6e9b8b93f60af97fb67bc728daa6573f0b  Split 
> status: matching $ newtmgr -c mynewt_serial image test 0fd 
> 6f020a3ff70d4cd150e6233185c6e9b8b93f60af97fb67bc728daa6573f0b  Images: 
>   slot=0  version: 1.0.0 <http://1.0.0.0/> bootable: true  flags: active 
> confirmed  hash: 
> 6d1b9bb73f9cf223145a28e4e0d7702a1b2aaf60a7a6d66497e02a841cd72c8c  slot=1 
>   version: 1.0.0 <http://1.0.0.0/> bootable: false  flags: pending 
>   hash: 0fd6f020a3ff70d4cd150e6233185c6e9b8b93f60af97fb67bc728daa6573f0b 
>   Split status: matching $ newtmgr -c mynewt_serial reset  Done $ 
> newtmgr -c mynewt_serial image list  ^C (cause it hang here indefinitely 
> so i cancel it) $ newtmgr -c mynewt_serial image upload splitty.img 
> <http://plitty.img/>Error: Timeout reading from serial connection 
>   upload - Upload image to target  Usage:  newtmgr image upload [flags] 
>   Examples:  newtmgr -c olimex image upload  olimex image upload bin/slinky_zero/apps/slinky.img 
> <http://slinky.img/> Global Flags:  -c, --conn string connection profile 
> to use.  -l, --loglevel string log level to use (default INFO.) 
> <http://info.%29/>(default "info")  -t, --trace print all bytes 
> transmitted and received
> 
> 
> Thank you.
> 
> Regards,
> 
> Then Yoong Ze
> 
> 
> On 23/2/2017 12:44 AM, Christopher Collins wrote:
> > Hi Then,
> >
> > On Wed, Feb 22, 2017 at 02:11:36PM +0800, then yon wrote:
> >> Dear Support,
> >>
> >> I'm followed the tutorial below:
> >> https://mynewt.apache.org/latest/os/modules/split/split/
> >>
> >> But i'm stuck at image upload step; it gave me the following error:
> > [...]
> >> Error: Target error: 2
> > Error 2 i

Re: newtmgr over serial hanging

[Christopher Collins]

Hi Jacob,

On Tue, Feb 21, 2017 at 09:10:08PM -0700, Jacob Rosenthal wrote:
[...]
> I get two distinct hangs to make things more weird.
> 
> Jacobs-MacBook-Air:~ jacobrosenthal$ newtmgr image list -cserial1 -t -ldebug
> 2017/02/21 20:36:03 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:0
> Group:1 Seq:0 Id:0 Data:[]}
> 2017/02/21 20:36:03 [DEBUG] Serializing request &{Op:0 Flags:0 Len:0
> Group:1 Seq:0 Id:0 Data:[]} into buffer [0 0 0 0 0 1 0 0]
> 2017/02/21 20:36:03 [DEBUG] Tx packet dump:
>   00 00 00 00 00 01 00 00   ||
> 
> 2017/02/21 20:36:03 [INFO] Outgoing:
>   06 09 |..|
> 
> 2017/02/21 20:36:03 [DEBUG] Writing [6 9] to data channel
> 2017/02/21 20:36:03 [INFO] Outgoing:
>   41 41 6f 41 41 41 41 41  41 41 45 41 41 44 63 77
>  |AAoAAAEAADcw|
> 
> 2017/02/21 20:36:03 [DEBUG] Writing [65 65 111 65 65 65 65 65 65 65 69 65
> 65 68 99 119] to data channel
> 2017/02/21 20:36:03 [INFO] Outgoing:
>   0a|.|
> 
> 2017/02/21 20:36:03 [DEBUG] Writing [10] to data channel

It looks like the board isn't responding at all.  There are a few things
I would check:

* UART is properly configured in your app with the expected settings
(115200, no flow control).

* The mgmt/newtmgr package gets included in your target.

* An appropriate newtmgr transport gets included in your target (either
mgmt/newtmgr/transport/nmgr_shell or mgmr/newtmgr/transport/nmgr_uart)

The following newtmgr commands would be useful for verifying the above:
newt target dep 
newt target revdep 
newt target config show 

My suspicion is that your target doesn't include a newtmgr transport.

> Jacobs-MacBook-Air:~ jacobrosenthal$ newtmgr image list -cserial1 -t -ldebug
> 2017/02/21 21:07:18 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:0
> Group:1 Seq:0 Id:0 Data:[]}
> 2017/02/21 21:07:18 [DEBUG] Serializing request &{Op:0 Flags:0 Len:0
> Group:1 Seq:0 Id:0 Data:[]} into buffer [0 0 0 0 0 1 0 0]
> 2017/02/21 21:07:18 [DEBUG] Tx packet dump:
>   00 00 00 00 00 01 00 00   ||
> 
> 2017/02/21 21:07:18 [INFO] Outgoing:
>   06 09 |..|
> 
> 2017/02/21 21:07:18 [DEBUG] Writing [6 9] to data channel
> 2017/02/21 21:07:18 [INFO] Outgoing:
>   41 41 6f 41 41 41 41 41  41 41 45 41 41 44 63 77
>  |AAoAAAEAADcw|
> 
> 2017/02/21 21:07:18 [DEBUG] Writing [65 65 111 65 65 65 65 65 65 65 69 65
> 65 68 99 119] to data channel
> 2017/02/21 21:07:18 [INFO] Outgoing:
>   0a|.|
> 
> 2017/02/21 21:07:18 [DEBUG] Writing [10] to data channel
> 2017/02/21 21:07:18 [INFO] Incoming:
>   31 3a 5b 74 73 3d 37 38  31 32 73 73 62 2c 20 6d  |1:[ts=7812ssb,
> m|
> 0010  6f 64 3d 34 20 6c 65 76  65 6c 3d 31 5d 20 47 41  |od=4 level=1]
> GA|
> 0020  50 20 70 72 6f 63 65 64  75 72 65 20 69 6e 69 74  |P procedure
> init|
> 0030  69 61 74 65 64 3a 20 61  64 76 65 72 74 69 73 65  |iated:
> advertise|
> 0040  3b 20 64 69 73 63 5f 6d  6f 64 65 3d 30 20 61 64  |; disc_mode=0
> ad|
> 0050  76 5f 63 68 61 6e 6e 65  6c 5f 6d 61 70 3d 30 20
>  |v_channel_map=0 |
> 0060  6f 77 6e 5f 61 64 64 72  5f 74 79 70 65 3d 30 20
>  |own_addr_type=0 |
> 0070  61 64 76 5f 66 69 6c 74  65 72 5f 70 6f 6c 69 63
>  |adv_filter_polic|
> 0080  79 3d 30 20 61 64 76 5f  69 74 76 6c 5f 6d 69 6e  |y=0
> adv_itvl_min|
> 0090  3d 30 20 61 64 76 5f 69  74 76 6c 5f 6d 61 78 3d  |=0
> adv_itvl_max=|
> 00a0  30 20 61 64 76 5f 64 61  74 61 5f 6c 65 6e 3d 30  |0
> adv_data_len=0|

It appears the log output is being sent over the newtmgr transport.  In
other words, text is getting logged to the console, and the newtmgr and
the cnosole are using the same uart (or a newtmgr transport isn't
enabled at all).  To solve this one, I would disable logging entirely
for the moment - Add the following to your target's syscfg.yml file:

syscfg.vals:
LOG_LEVEL: 255

And then send the above three newt commands.

Thanks,
Chris

Re: image upload error 2

[Christopher Collins]

Hi Then,

On Wed, Feb 22, 2017 at 02:11:36PM +0800, then yon wrote:
> Dear Support,
> 
> I'm followed the tutorial below:
> https://mynewt.apache.org/latest/os/modules/split/split/
> 
> But i'm stuck at image upload step; it gave me the following error:
[...]
> Error: Target error: 2

Error 2 indicates that there is no free slot for the new image.  In your
email, the "image list" output is a bit touch to read because it got
collapsed into a single line.  Here is my attempt to unravel it:

> $ newtmgr -c mynewt_serial image list
> Images:
> slot=0
> version: 1.0.0 
> bootable: true
> flags: active confirmed
> hash: 493c5e78e76a9c1b9e574ab38b7bbf0d342d928ffd0111400dbe8c2c952da68e
> 
> slot=1 
> version: 1.0.0
> bootable: false
> flags: active confirmed 
> hash: 
> 4d26a0d1596e12dab9059df3a13b4ffd54f96836cd9080d579c6afc167d58e81 
> 
> Split status: matching

Notice that both slots have the "active" and "confirmed" flags set.
This indicates that both slots are currently running.  You need to run
the image in loader-only mode in order to replace the app in slot 1.
This is described in the "Image Upgrade - Split" section of the page you
linked to (https://mynewt.apache.org/latest/os/modules/split/split/).
Specifically:


1. Disable split functionality; we need to deactivate the application
   image in slot 1 (newtmgr image test ).
2. Reboot device (newtmgr reset).
3. Make above change permanent (newtmgr image confirm).
4. Upload new loader to slot 1 (newtmgr image upload ).
5. Tell device to "test out" the new loader on next boot (newtmgr image
   test ).
6. Reboot device (newtmgr reset).
7. Make above change of loader permanent (newtmgr image confirm).
8. Upload new application to slot 1 (newtmgr image upload ).
9. Tell device to "test out" the new application on next boot (newtmgr
   image test ).
10. Reboot device (newtmgr reset).
11. Make above change of application permanent (newtmgr image confirm).

Steps 1 and 2 will leave the device in a state such that the app in slot
1 can be replaced.

Chris

Re: Config id package

[Christopher Collins]

Hi Jacob,

On Tue, Feb 21, 2017 at 10:34:53AM -0700, Jacob Rosenthal wrote:
> Im trying to build a DIS service with identification strings like bsp and
> app name from config/id package with conf_get_value
> 
> I think Im using the api correctly?
> 
> char *val;
> int rc;
> uint16_t uuid16;
> char tmp_buf[32 + 1]; ///hwid is only one that needs some tmp buffer
> 
> if(ctxt->op != BLE_GATT_ACCESS_OP_READ_CHR)
> {
> return BLE_ATT_ERR_UNLIKELY;
> }
> uuid16 = ble_uuid_u16(ctxt->chr->uuid);
> assert(uuid16 != 0);
> 
> switch (uuid16) {
> case BLE_SVC_DIS_CHR_SYS_ID_UUID16:
> val = conf_get_value("id/hwid", tmp_buf, sizeof(tmp_buf));
> console_printf("hwid %s\n", val);
> rc = os_mbuf_append(ctxt->om, val, strlen(val));
> return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
> 
> But I cant seem to get anything other than a empty string at runtime...
[...]

This is indeed a bummer.  The problem is that the conf_get_value()
function expects the setting name to be a mutable string.  String
literals (e.g., "id/hwid") are constant, and cause the setting lookup to
fail.  The reason the name needs to be mutable is that the lookup
routine calls strtok_r on the string, which replaces instances of '/'
with \0.

Anyway, the immediate fix is to put the setting name in a char array,
rather than pass a string literal to conf_get_value().  For example:

char conf_name[] = "id/hwid";

val = conf_get_value(conf_name, tmp_buf, sizeof(tmp_buf));

In my view, this aspect of the conf API isn't particularly obvious.  We
should either change the API such that it works with constant strings or
clearly document this requirement.

Chris

Re: os_msys_get_pkthdr always return null

[Christopher Collins]

Hi Then,

On Wed, Feb 15, 2017 at 10:58:57AM +0800, then yon wrote:
> After i tried on 3 NRF52_DK board, 1 of it worked!
> 
> This is really weird as the other 2 units only work if i disabled the 
> filesystem.
> 
> Do you have any clue on this?

I wonder if the flash is corrupt somehow.  There were some
backwards-compatibility-breaking changes to the boot loader and flash
maps between 0.9.0 and 1.0.0-b2.  I would try erasing the flash entirely
on one of the boards, then upload the boot loader and image again.

I wouldn't expect these symptoms from flash corruption, though...

Chris

[jira] [Resolved] (MYNEWT-627) BLE Host - Collapse incoming L2CAP fragments into single mbuf

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-627.

Resolution: Fixed

> BLE Host - Collapse incoming L2CAP fragments into single mbuf
> -
>
> Key: MYNEWT-627
> URL: https://issues.apache.org/jira/browse/MYNEWT-627
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> Currently, when the host receives an L2CAP fragment, it chains the fragment 
> to the end of the packet in progress.  This is fast, but wasteful.  It would 
> be better to allow the host to be configured to copy the mbuf data and free 
> the empty mbuf.



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

[jira] [Created] (MYNEWT-627) BLE Host - Collapse incoming L2CAP fragments into single mbuf

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-627:
--

 Summary: BLE Host - Collapse incoming L2CAP fragments into single 
mbuf
 Key: MYNEWT-627
 URL: https://issues.apache.org/jira/browse/MYNEWT-627
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_rel


Currently, when the host receives an L2CAP fragment, it chains the fragment to 
the end of the packet in progress.  This is fast, but wasteful.  It would be 
better to allow the host to be configured to copy the mbuf data and free the 
empty mbuf.



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

[jira] [Resolved] (MYNEWT-626) testbench - tasks added to kernel more than once

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-626.

Resolution: Fixed

> testbench - tasks added to kernel more than once
> 
>
> Key: MYNEWT-626
> URL: https://issues.apache.org/jira/browse/MYNEWT-626
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The test bench app suspends test tasks when it is done with them.  When the 
> next test runs, it re-adds the tasks.  This triggers a failed assert due to 
> duplicate priorities.



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

Re: Can't build blinky app on macOS Sierra

[Christopher Collins]

Hi Denis,

On Wed, Feb 08, 2017 at 09:39:10PM -0800, Denis Magda wrote:
> Hello Mynewt community,
> 
> I tried to play with your product strictly following the getting started 
> guide [1] but can’t compile the default blinky app
> 
> Deniss-MBP:test dmagda$ newt build my_blinky_sim
> Building target targets/my_blinky_sim
> Assembling os_arch_stack_frame.s
> Error: os_arch_stack_frame.s:34:17: error: unexpected token in directive
> .globl CNAME(os_arch_frame_init)
> ^
> os_arch_stack_frame.s:39:26: error: unexpected token in argument list
> CNAME(os_arch_frame_init):
>  ^
> os_arch_stack_frame.s:84:19: error: unexpected token in memory operand
> callCNAME(sigsetjmp)/* sigsetjmp(sf->sf_jb, 0) */
>   ^
> os_arch_stack_frame.s:98:19: error: unexpected token in memory operand
> callCNAME(os_arch_task_start) /* os_arch_task_start(sf, rc) */

Hmm, that's odd.  I don't have any theories, but I'll look into it.
Could you please post the following:

* Contents of compiler/sim/compiler.yml
* Output of "gcc-6 -v" (or whatever your gcc binary is called)

Another option that could be helpful is to try building with the
"-ldebug" command line switch.  This will enable a lot of debug output,
including the actual command used to assemble that .s file.

Thanks,
Chris


> 
> 
> The dev environment is the following:
> * macOS Sierra
> * newt, gcc and gdb are natively installed
>   - newt version: Apache Newt (incubating) version: 1.0.0-dev
>  - gcc version: gcc version 6.3.0 (Homebrew GCC 6.3.0_1)
> * gcc-5 replaced with gcc-6 in compiler.yml according to this doc [2].  
>
> 
> Am I missing something or doing something wrong?
> 
> [1] https://mynewt.incubator.apache.org/os/get_started/project_create/
> [2] https://mynewt.incubator.apache.org/os/get_started/native_tools/
> 
> —
> Denis
> 

[jira] [Resolved] (MYNEWT-576) Update apps that use newtmgr framework to explicitly set the event queue with mgmt

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-576.

Resolution: Won't Fix

The fix for the linked issue (MYNEWT-534) obviates the need for this change.  
Now, packages automatically use the default event queue.

> Update apps that use newtmgr framework to explicitly set the event queue with 
> mgmt 
> ---
>
> Key: MYNEWT-576
> URL: https://issues.apache.org/jira/browse/MYNEWT-576
> Project: Mynewt
>  Issue Type: Bug
>  Components: Misc
>Affects Versions: v1_0_0_beta1
>Reporter: Wanda Chiu
>Assignee: Wanda Chiu
>Priority: Trivial
> Fix For: v1_0_0_rel
>
>
> The tutorial to enable Newt Manager in Any App indicates that the app must 
> call the mgmt_evq_set to specify the event queue that mgmt uses to receive 
> newtmgr request events. We need to update the apps that use the newtmgr 
> framework to make this call. 



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

[jira] [Resolved] (MYNEWT-534) A cooperative package's "start event" might not get executed when OS started

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-534.

Resolution: Fixed

> A cooperative package's "start event" might not get executed when OS started
> 
>
> Key: MYNEWT-534
> URL: https://issues.apache.org/jira/browse/MYNEWT-534
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> *Vocabulary for this ticket:*
> +Cooperative package:+ A package which uses an eventq to do work, but which 
> doesn't have its own task.  Such a package is told which eventq / task to use 
> at runtime, or it just uses the eventq designated as the default.
> +Start event:+ An OS event that a package needs to execute as soon as the OS 
> starts.  Such an event generally "kicks off" the package.  Example: the BLE 
> host's start event initiates communication with the controller.
> --
> *Problem Description:*
> The problem concerns cooperative packages which aren't explicitly told which 
> event queue to use, i.e., a package which uses the default event queue.  This 
> type of package only enqueues its start event when it tries to enqueue a 
> second event.  For some packages, this is not noticible, because the 
> application calls into the package's API on start up, kicking off the start 
> event.  In other cases, the package is meant to do things on its own with no 
> interaction from the app (example: mgmt/newtmgr).  These packages are broken 
> unless the app explicitly specifies an eventq for them to use.
> The reason for the odd behavior is that a package doesn't know which eventq 
> it will be used when it first gets initialized.  If the app explicitly 
> assigns an eventq to a package, the package is able to enqueue its start 
> event at that time, evading this problem.  Packages which use the default 
> event queue never get an opportunity to enqueue their start event because the 
> default queue may not be designated when the package is initialized.  
> Furthermore, enqueueing to the default event queue would be premature, as the 
> app may set the pacakge's event queue shortly afterwards.
> --
> *Possible solutions:*
> 1. Require the app to designate the default event queue before calling 
> sysinit().  When a cooperative package is initialized, it immediately 
> enqueues its start event onto the default event queue.  If a package's event 
> queue is then explicitly set, the start event is removed from the default 
> queue and placed on the specified queue.
> Problems with this approach are: it places some odd restrictions on how the 
> main() function should look.  Creating an event queue and designating it as 
> the default prior to calling sysinit() probably won't look right.  
> 2. Cooperative packages register themselves at init-time.  When the OS is 
> started, all registered packages enqueue their start event on the assigned 
> queue (or default if none assigned).
> The downside of this approach is that it requires extra ram to hold the 
> registration list, and a small amount of code to call the registration 
> function in each pacakge's init function.
> 3. Place all start events in a special linker section.  When the OS is 
> started, each event in the linker section is enqueued.  This approach doesn't 
> require any extra RAM.
> Problems with this approach: linker scripts must be modified to be made aware 
> of the new linker section.  Also, a package's event doesn't get included in 
> the final binary if none of the package's symbols are referenced by name.  An 
> example of such a package is newtmgr; this package starts itself, and is then 
> accessed indirectly through function pointers.



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

[jira] [Updated] (MYNEWT-534) A cooperative package's "start event" might not get executed when OS started

[Christopher Collins (JIRA)]

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

Christopher Collins updated MYNEWT-534:
---
Fix Version/s: v1_0_0_rel

> A cooperative package's "start event" might not get executed when OS started
> 
>
> Key: MYNEWT-534
> URL: https://issues.apache.org/jira/browse/MYNEWT-534
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> *Vocabulary for this ticket:*
> +Cooperative package:+ A package which uses an eventq to do work, but which 
> doesn't have its own task.  Such a package is told which eventq / task to use 
> at runtime, or it just uses the eventq designated as the default.
> +Start event:+ An OS event that a package needs to execute as soon as the OS 
> starts.  Such an event generally "kicks off" the package.  Example: the BLE 
> host's start event initiates communication with the controller.
> --
> *Problem Description:*
> The problem concerns cooperative packages which aren't explicitly told which 
> event queue to use, i.e., a package which uses the default event queue.  This 
> type of package only enqueues its start event when it tries to enqueue a 
> second event.  For some packages, this is not noticible, because the 
> application calls into the package's API on start up, kicking off the start 
> event.  In other cases, the package is meant to do things on its own with no 
> interaction from the app (example: mgmt/newtmgr).  These packages are broken 
> unless the app explicitly specifies an eventq for them to use.
> The reason for the odd behavior is that a package doesn't know which eventq 
> it will be used when it first gets initialized.  If the app explicitly 
> assigns an eventq to a package, the package is able to enqueue its start 
> event at that time, evading this problem.  Packages which use the default 
> event queue never get an opportunity to enqueue their start event because the 
> default queue may not be designated when the package is initialized.  
> Furthermore, enqueueing to the default event queue would be premature, as the 
> app may set the pacakge's event queue shortly afterwards.
> --
> *Possible solutions:*
> 1. Require the app to designate the default event queue before calling 
> sysinit().  When a cooperative package is initialized, it immediately 
> enqueues its start event onto the default event queue.  If a package's event 
> queue is then explicitly set, the start event is removed from the default 
> queue and placed on the specified queue.
> Problems with this approach are: it places some odd restrictions on how the 
> main() function should look.  Creating an event queue and designating it as 
> the default prior to calling sysinit() probably won't look right.  
> 2. Cooperative packages register themselves at init-time.  When the OS is 
> started, all registered packages enqueue their start event on the assigned 
> queue (or default if none assigned).
> The downside of this approach is that it requires extra ram to hold the 
> registration list, and a small amount of code to call the registration 
> function in each pacakge's init function.
> 3. Place all start events in a special linker section.  When the OS is 
> started, each event in the linker section is enqueued.  This approach doesn't 
> require any extra RAM.
> Problems with this approach: linker scripts must be modified to be made aware 
> of the new linker section.  Also, a package's event doesn't get included in 
> the final binary if none of the package's symbols are referenced by name.  An 
> example of such a package is newtmgr; this package starts itself, and is then 
> accessed indirectly through function pointers.



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

[jira] [Resolved] (MYNEWT-578) BLE Host - Use "address" type rather than addr_type+addr pair.

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-578.

Resolution: Fixed

> BLE Host - Use "address" type rather than addr_type+addr pair.
> --
>
> Key: MYNEWT-578
> URL: https://issues.apache.org/jira/browse/MYNEWT-578
> Project: Mynewt
>  Issue Type: Improvement
>    Reporter: Christopher Collins
> Fix For: v1_0_0_beta2
>
>
> This change affects much of the host API.  Any function which takes either:
> * own_addr_type+own_addr
> * peer_addr_type+peer_addr
> Should take a single parameter instead: own_addr or peer_addr.  The parameter 
> is of a new type which encapsulates address type and address bytes.



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

Re: [VOTE] Release Apache Mynewt 1.0.0-b2-incubating-rc1

[Christopher Collins]

Hi Szymon,

On Wed, Feb 08, 2017 at 03:55:44PM +0100, Szymon Janc wrote:
> blesplit application doesn't build on this tag:
> 
> Linking 
> /home/janc/devel/mynewt/bin/targets/blesplit/app/apps/blesplit/blesplit.elf
> Error: 
> /home/janc/devel/mynewt/bin/targets/blesplit/app/apps/blesplit/apps_blesplit.a(main.o):
> In function `main':
> /home/janc/devel/mynewt/repos/apache-mynewt-core/apps/blesplit/src/main.c:284:
> undefined reference to `g_dev_addr'
> collect2: error: ld returned 1 exit status

The blesplit app is only meant to be used as the second app in a split
image (yes, we should document this!).  The expectation is that bleprph
is used as the loader half.  For example, here is my blesplit-nrf52dk
target definition:

targets/blesplit-nrf52dk
app=apps/blesplit
bsp=hw/bsp/nrf52dk
build_profile=optimized
loader=apps/bleprph

I don't have any hardware available at the moment, but I will try
running this on a board in a little bit to see if I have the same issue.
This worked for me when I tried it a week or two ago, so yeah, plenty of
time for a bug to creep in :).

Personally, I don't think it is a worthwhile goal to ensure blesplit,
splitty, and other split apps can run as standalone applications.  They
are intended only for split images, and adding extra code to enable them
to run standalone seems counter to their purpose.

> 
> Enabling controller package makes it build fine but application
> asserts on start (probably due to controller and host initialization
> order).
> 
> So [-1] due to this.
> 
> -- 
> pozdrawiam
> Szymon K. Janc

Re: [VOTE] Release Apache Mynewt 1.0.0-b2-incubating-rc1

[Christopher Collins]

On Mon, Feb 06, 2017 at 05:32:55PM -0800, will sanfilippo wrote:
> [X] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because…

+1 (binding)

Chris

Re: sysint() fails

[Christopher Collins]

Hi David,

Could your version of the newt tool be out of date?  Some backwards
compatibility breaking changes were made about two weeks ago.  If that
isn't the problem, could you grab a backtrace in gdb at the point of the
crash ("bt" or "where" in gdb)?

Thanks,
Chris


On Tue, Feb 07, 2017 at 09:43:19AM -0500, David G. Simmons wrote:
> Having some trouble this morning with the nrf52dk board.
> 
> 389   sysinit();
> (gdb) n
> 
> 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 
> repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:125
> 125  asm("bkpt");
> 
> I've updated both mynewt_nordic and apache-mynewt-core to the latest develop 
> branches, and
> 
> int
> main(int argc, char **argv)
> {
> int rc;
> 
> /* Initialize OS */
> sysinit();
> 
> ...
> 
> Fails at sysinit()
> 
> I've built a new bootloader (just in case). I thought maybe it was something 
> I was doing in my app, so I built and loaded core/apps/bleprph and
> 
> 259   sysinit();
> (gdb) n
> 
> 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 
> repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:125
> 125  asm("bkpt");
> 
> So it appears that something is broken for at least the nrf52dk dev board ...
> 
> cd repos/apache-mynewt-core/
> DSimmons-Pro:apache-mynewt-core dsimmons$ git status -v
> On branch develop
> Your branch is up-to-date with 'origin/develop'.
> cd ../mynewt_nordic/
> DSimmons-Pro:mynewt_nordic dsimmons$ git status -v
> On branch develop
> Your branch is up-to-date with 'origin/develop'.
> nothing to commit, working tree clean
> 
> dg
> --
> David G. Simmons
> (919) 534-5099
> Web  • Blog  • 
> Linkedin  • Twitter 
>  • GitHub 
> /** Message digitally signed for security and authenticity.
> * If you cannot read the PGP.sig attachment, please go to
>  * http://www.gnupg.com/  Secure your email!!!
>  * Public key available at keyserver.pgp.com 
> **/
> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
> 
> There are only 2 hard things in computer science: Cache invalidation, naming 
> things, and off-by-one errors.
> 
> 

[jira] [Resolved] (MYNEWT-619) Splitty - Console does not output

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-619.

Resolution: Fixed

> Splitty - Console does not output
> -
>
> Key: MYNEWT-619
> URL: https://issues.apache.org/jira/browse/MYNEWT-619
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_beta2
>
>
> In splitty, data sent to the console never gets transmitted to the uart.



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

[jira] [Created] (MYNEWT-619) Splitty - Console does not output

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-619:
--

 Summary: Splitty - Console does not output
 Key: MYNEWT-619
 URL: https://issues.apache.org/jira/browse/MYNEWT-619
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_beta2


In splitty, data sent to the console never gets transmitted to the uart.



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

[jira] [Resolved] (MYNEWT-558) newt - depgraph should indicate soft vs. hard dependency

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-558.

Resolution: Fixed

> newt - depgraph should indicate soft vs. hard dependency
> 
>
> Key: MYNEWT-558
> URL: https://issues.apache.org/jira/browse/MYNEWT-558
> Project: Mynewt
>  Issue Type: Bug
>    Reporter: Christopher Collins
>    Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The `target dep` and `target revdep` commands only indicate package names in 
> the dependency graph.  It would be helpful to see what created the dependency 
> in the first place.  Specifically, it would be good to know if the dependency 
> is "hard" (package explicitly depends on another) or "soft" (package requires 
> an API; other package happens to implement that API).  This is useful when 
> trying to completely remove a package from a build.
> Unfortunately, this information is lost at the time dependency graphs are 
> generated.  Rather than use a builder's package map, dependency generation 
> should operate on an intermediate form produced by the `resolve` package. 



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

[jira] [Resolved] (MYNEWT-617) BLE Host - UUID-to-string conversion missing hyphen.

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-617.

Resolution: Fixed

> BLE Host - UUID-to-string conversion missing hyphen.
> 
>
> Key: MYNEWT-617
> URL: https://issues.apache.org/jira/browse/MYNEWT-617
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> The final hyphen is missing:
> *good:*
> {{8D53DC1D-1DB7-4CD3-868B-8A527460AA84}}
> *bad:*
> {{8D53DC1D-1DB7-4CD3-868B8A527460AA84}}



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

[jira] [Created] (MYNEWT-617) BLE Host - UUID-to-string conversion missing hyphen.

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-617:
--

 Summary: BLE Host - UUID-to-string conversion missing hyphen.
 Key: MYNEWT-617
 URL: https://issues.apache.org/jira/browse/MYNEWT-617
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_rel


The final hyphen is missing:

*good:*
{{8D53DC1D-1DB7-4CD3-868B-8A527460AA84}}

*bad:*
{{8D53DC1D-1DB7-4CD3-868B8A527460AA84}}




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

Re: BLE HCI support on NRF52DK

[Christopher Collins]

Hi Alan,

On Thu, Feb 02, 2017 at 06:16:42PM +, Alan Graves wrote:
> Thanks for rechecking. I know I'm not setup with RTS/CTS handshaking on the 
> custom board so that is probably going to be a problem. When I get a chance 
> I'll repeat my tests with a complete serial signal set on the nRF52832 DK 
> board. 
> 
> BTW Do you know if Linux assumes hardware flow control by default and if it 
> is possible to override that configuration somewhere? I've been caught before 
> with hardware flow defaults on PPP over serial on Linux... 

Yes, the btattach program assumes flow control and baud rate of 100
(recent versions allow you specify baud on the command line).

Flow control can be disabled with a simple code change to
tools/btattach.c:

*** btattach.c  2017-02-02 12:15:05.030918824 -0800
--- /home/admin/tmp/btattach.c  2017-02-02 12:14:59.951029001 -0800
***
*** 76,85 
--- 76,86 
cfmakeraw();
  
ti.c_cflag |= (speed | CLOCAL | CREAD);
  
/* Set flow control */
-   ti.c_cflag |= CRTSCTS;
+   ti.c_cflag &= ~CRTSCTS;
  
if (tcsetattr(fd, TCSANOW, ) < 0) {
perror("Failed to set serial port settings");
close(fd);

Then run make from the bluez source directory.  The new btattach binary
will be named tools/btattach.

You also need to disable flow control in your Mynewt target:

newt target set nina_hci 
syscfg=BLE_HCI_UART_FLOW_CTRL=HAL_UART_FLOW_CTL_NONE

And rebuild / reload the firmware onto your board.

Chris

[jira] (MYNEWT-577) newt - Windows paths broken again

[Christopher Collins (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Collins resolved as Fixed 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Mynewt /  MYNEWT-577 
 
 
 
  newt - Windows paths broken again  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Collins 
 
 
 

Resolution:
 
 Fixed 
 
 
 

Status:
 
 Open Resolved 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

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

Re: NimBLE host advertising data API

[Christopher Collins]

Thanks Andrzej.  That makes sense.

Chris

On Fri, Jan 27, 2017 at 04:57:48PM +0100, Andrzej Kaczmarek wrote:
> Hi Chris,
> 
> I created a pull request which also updates API to raw data for the
> opposite direction, i.e. from host to app. Application can still parse this
> to ble_hs_adv_fields since helper is now public, but has to do this
> explicitly. The advantage is that if application prefers to work on raw
> data (I added simple iterator to make this easier) some extra code and
> static variables are removed saving some flash.
> 
> There are also some extra fixes includes for advertising API I had pending
> in my tree.
> 
> Link: https://github.com/apache/incubator-mynewt-core/pull/169
> 
> BR,
> Andrzej
> 
> 
> 
> On Thu, Jan 26, 2017 at 4:16 AM, Christopher Collins <ccoll...@apache.org>
> wrote:
> 
> > Heads up: I have pushed this API change.
> >
> > The new functions are:
> > int ble_gap_adv_set_data(const uint8_t *data, int data_len);
> > int ble_gap_adv_rsp_set_data(const uint8_t *data, int data_len);
> >
> > /* Converts a high-level set of fields to a byte buffer. */
> > int ble_hs_adv_set_fields(const struct ble_hs_adv_fields *adv_fields,
> >   uint8_t *dst, uint8_t *dst_len,
> >   uint8_t max_len):
> >
> > The old functions are still around because they are convenient
> > (ble_gap_adv_set_data() and ble_gap_adv_rsp_set_data()); they won't get
> > included in the build if your app does not call them.
> >
> > If you use ble_hs_adv_set_fields() or the old functions, please be aware
> > of one more API change: you need to explicitly specify the flags value
> > that you want to include in advertisements.  Before this change, you
> > could specify a value of 0, and the flags field would get
> > auto-calculated by the host.
> >
> > E.g.,
> >
> > OLD API:
> >
> > fields.flags_is_present = 1;
> > fields.flags = 0;
> >
> > NEW API:
> >
> > fields.flags = BLE_HS_ADV_F_DISC_GEN |
> >BLE_HS_ADV_F_BREDR_UNSUP;
> >
> > Thanks,
> > Chris
> >
> > On Tue, Jan 24, 2017 at 11:45:33AM -0800, Christopher Collins wrote:
> > > Hello all,
> > >
> > > I've mentioned this before - I really don't care for the advertising
> > > data API that we ended up with:
> > > http://mynewt.apache.org/latest/network/ble/ble_hs/ble_
> > gap/functions/ble_gap_adv_set_fields/
> > >
> > > I think we should change this API now before the 1.0 release.  I was
> > > wondering what others think.
> > >
> > > The current API is high-level and is relatively easy to use, but
> > > requires a lot of code space and RAM.  I think a function which just
> > > takes a raw byte buffer (or mbuf) would be much better.  Then, there
> > > could be a helper function which converts an instance of `struct
> > > ble_hs_adv_fields` to a raw byte buffer.
> > >
> > > A simple peripheral that always advertises the same data shouldn't be
> > > burdened with the ble_hs_adv_fields API.
> > >
> > > There is actually a rationale as to why the API is the way it is today.
> > > There are a few fields in the advertisement data that the host can be
> > > configured to fill in automatically:
> > > * Flags (contains advertising type).
> > > * TX Power Level
> > >
> > > I figured it would be safer if these values got calculated when
> > > advertising is initiated.  This is impractical if the host were handed a
> > > byte buffer rather than a series of fields.
> > >
> > > Under the new proposal, the application would need to specify the
> > > correct advertising type when building the byte buffer, and the tx power
> > > level would be queried before the advertising procedure is actually
> > > started.  I don't think this will be a problem in practice, and I think
> > > the benefits in code size and RAM usage outweigh the API burden.
> > >
> > > All thoughts welcome.
> > >
> > > Thanks,
> > > Chris
> >

[jira] [Resolved] (MYNEWT-569) Move file upload and file download out of image management newtmgr group and into a new group: fs

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-569.

Resolution: Fixed

> Move file upload and file download out of image management newtmgr group and 
> into a new group: fs
> -
>
> Key: MYNEWT-569
> URL: https://issues.apache.org/jira/browse/MYNEWT-569
> Project: Mynewt
>  Issue Type: Improvement
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_0_0_beta2
>
>
> Move file upload and file download out of image management newtmgr group and 
> into a new group: fs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-573) nmgr reset causes two reboot log entries to get written

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-573:
--

 Summary: nmgr reset causes two reboot log entries to get written
 Key: MYNEWT-573
 URL: https://issues.apache.org/jira/browse/MYNEWT-573
 Project: Mynewt
  Issue Type: Bug
  Components: Misc
Reporter: Christopher Collins
Assignee: Sterling Hughes
 Fix For: v1_0_0_rel


The first log entry gets written during processing of the incoming reset 
command.

The second entry gets written at init time during the subsequent reboot.

The problem appears to be that the reboot log code doesn't check if the most 
recent reboot was "soft".  There is a config var for this 
("reboot/soft_reboot"), but it never gets read.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-569) Move file upload and file download out of image management newtmgr group and into a new group: fs

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-569:
--

 Summary: Move file upload and file download out of image 
management newtmgr group and into a new group: fs
 Key: MYNEWT-569
 URL: https://issues.apache.org/jira/browse/MYNEWT-569
 Project: Mynewt
  Issue Type: Improvement
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_beta2


Move file upload and file download out of image management newtmgr group and 
into a new group: fs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-568) logs - Increase idx to 32 bits

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-568:
--

 Summary: logs - Increase idx to 32 bits
 Key: MYNEWT-568
 URL: https://issues.apache.org/jira/browse/MYNEWT-568
 Project: Mynewt
  Issue Type: Improvement
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_beta2


* Increase log entry's index field to 32 bits.
* In newtmgr read log command, the index is the only criterion for selecting 
the start point of the read (don't use timestamp anymore).
* On startup, read the last entry from each flash log to determine the index of 
the next entry.  This is to ensure the next entry written has the correct 
sequence number.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: newNewt

[Christopher Collins]

Sorry, there's something else I forgot to mention.  You'll need to put
the boot loader on your board as well.  You can do this before or after
uploading blinky.

newt target create boot-frdm-k64f &&
newt target set boot-frdm-k64f app=@apache-mynewt-core/apps/boot\
   bsp=@apache-mynewt-core/hw/bsp/frdm-k64f \
   build_profile=optimized

Then build and upload the boot loader to your board:

newt build boot-frdm-k64f
newt load boot-frdm-k64f

Chris


On Thu, Jan 26, 2017 at 09:14:02AM -0800, Christopher Collins wrote:
> To start with, I would create a blinky-frdm-k64f target:
> 
> newt target copy my_blinky_sim blinky-frdm-k64f
> 
> Then configure your new target to use the frdm-k64f BSP:
> 
> newt target set blinky-frdm-k64f bsp=@apache-mynewt-core/hw/bsp/frdm-k64f
> 
> Plug your board in and attach a debugger if necessary, and try running
> blinky on your board:
> 
> newt run blinky-frdm-k64f
> 
> If everything works, a gdb window will come up.  Type c , and
> check if your board's LED is blinking.
> 
> After you have blinky working on your board, you might want to try one
> of these other sample apps:
> slinky: Includes shell over UART and newtmgr over shell.
> bleprph: Includes BLE stack and newtmgr over BLE.
> 
> Thanks,
> Chris
> 
> > 
> > Alternatively, I could familiarize myself work through the Olimex-E407
> > 
> > My  environment so far has been IDE Freescale Kinetis Design
> > Studio/Eclipse building nuttx OS, and with integration to Multilink JTAG
> > for blowing the flash.
> > 
> > There was a new feature request for an Eclipse plugin for myNewt, but it 
> > was marked as dup, and I haven't seen any other mention of Eclipse IDE so
> > far.
> > 
> > Any recommendation on getting started with FRDM-K64F?   or should I
> > start with Olimex
> > 
> > thanks
> > 
> > 
> > -- 
> > Neil Hancock
> > 
> > 
> > 

Re: newNewt

[Christopher Collins]

On Thu, Jan 26, 2017 at 09:14:02AM -0800, Christopher Collins wrote:
> Plug your board in and attach a debugger if necessary, and try running
> blinky on your board:
> 
> newt run blinky-frdm-k64f

That should be:

newt run blinky-frdm-k64f 0

(append a zero!)

Chris

[jira] [Resolved] (MYNEWT-564) BLE Host - Allow byte buf for adv / rsp data

[Christopher Collins (JIRA)]

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

Christopher Collins resolved MYNEWT-564.

Resolution: Fixed

> BLE Host - Allow byte buf for adv / rsp data
> 
>
> Key: MYNEWT-564
> URL: https://issues.apache.org/jira/browse/MYNEWT-564
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v1_0_0_beta2
>
>
> The current API is high-level and is relatively easy to use, but
> requires a lot of code space and RAM.  I think a function which just
> takes a raw byte buffer (or mbuf) would be much better.  Then, there
> could be a helper function which converts an instance of `struct
> ble_hs_adv_fields` to a raw byte buffer.
> A simple peripheral that always advertises the same data shouldn't be
> burdened with the ble_hs_adv_fields API.
> There is actually a rationale as to why the API is the way it is today.
> There are a few fields in the advertisement data that the host can be
> configured to fill in automatically:
> * Flags (contains advertising type).
> * TX Power Level
> I figured it would be safer if these values got calculated when
> advertising is initiated.  This is impractical if the host were handed a 
> byte buffer rather than a series of fields.
> Under the new proposal, the application would need to specify the
> correct advertising type when building the byte buffer, and the tx power  
> level would be queried before the advertising procedure is actually   
> started.  I don't think this will be a problem in practice, and I think
> the benefits in code size and RAM usage outweigh the API burden.
> New functions:
> {noformat}
> int ble_gap_adv_set_data(const uint8_t *data, int data_len);
> int ble_gap_adv_rsp_set_data(const uint8_t *data, int data_len);
> {noformat}
> Additional API change:
> The flags field is no longer auto-calculated.  Instead, the application has 
> to specify the exact value to send over the air.  For example:
> *OLD API*
> {noformat}
> fields.flags_is_present = 1;
> fields.flags = 0;
> {noformat}
> *NEW API*
> {noformat}
> fields.flags = BLE_HS_ADV_F_DISC_GEN |
>BLE_HS_ADV_F_BREDR_UNSUP;
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-564) BLE Host - Allow byte buf for adv / rsp data

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-564:
--

 Summary: BLE Host - Allow byte buf for adv / rsp data
 Key: MYNEWT-564
 URL: https://issues.apache.org/jira/browse/MYNEWT-564
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins


The current API requires the user to fill in a struct of advertising fields, 
then pass that struct to the host. This requires a lot of code and RAM.  If the 
application knows the exact bytes to advertise, it shouldn't need to go through 
this heavy weight API.

New functions:
{{noformat}}
int ble_gap_adv_set_data(const uint8_t *data, int data_len);
int ble_gap_adv_rsp_set_data(const uint8_t *data, int data_len);
{{noformat}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Newtmgr over BLE

[Christopher Collins]

Hi Kevin,

On Wed, Jan 25, 2017 at 02:18:01AM +0100, Kevin Townsend wrote:
> I'm not sure what the implications would be here on the iOS app we wrote 
> that is based on the newtmgr protocol and makes use of the current BLE 
> service and characteristics, although we could rewrite it if necessary. 
> We use the currently defined newtmgr protocol and GATT services/chars to 
> get task info and statistic and stream them live onto the mobile device, 
> which I think provides a unique window into your device in a 
> non-invasive way.

The newtmgr protocol wouldn't be affected.  This would just be a way to
get the newtmgr tool to speak BLE.

> I'm certainly OK with BLE being removed from the newtmgr tool and having 
> that supported by a dedicated tool or service based on UART/HCI, but 
> just to be sure are there any implications here for the newtmgr protocol 
> running on a mynewt app?  It sounds like we should still be OK with the 
> app, though, and this is limited to the newtmgr tool itself not the 
> newtmgr protocol implementation or the BLE transport in the Mynewt app.
> 
> One advantage of taking the HCI approach talking to a Mynewt target over 
> UART is that you can add support to any OS, not just systems that 
> support BLE, and not having to depend on a specific OS or BlueZ version. 
> You need to do some work up front and it would require another nRF5x 
> board, but it solves more problems than it creates in my opinion.
> 
> Alternatively, you could use the simulator and try to add some hooks 
> into CoreBluetooth and BlueZ (so no additional HW required), but that's 
> ultimately frustrating and a significant maintenance burden. UART/HCI 
> seems like less work both short and long term, and the requirements for 
> an additional nRF5x board seems relatively trivial.

All good points.  I really think BLE on Linux vs. MacOS is so different
that it would be less of a headache to make our own.

> Removing the dependency on the current GO lib and moving to HCI/UART and 
> a dedicated Mynewt app is a +1 for me and worth doing before 1.0, even 
> if it's a major change ... with the caveat that I hope this won't break 
> anything with the newtmgr protocol that will cause us to have to rewrite 
> the newtmgr tool we wrote and want to release around the same time as 
> 1.0.0 final. :)

Thanks,
Chris

> On 24/01/17 23:49, Christopher Collins wrote:
> > Hello all,
> >
> > Recently, I have mentioned some planned BLE-related changes to the
> > newtmgr tool.  I wanted to share some of what I was thinking.  Please
> > feel free to comment and criticize as needed.
> >
> > * All BLE code gets removed from the newtmgr tool.  The gatt library is
> >also removed.
> >
> > * A separate tool, blehostd, runs in its own process.  This tool:
> >  * Is a Mynewt app running in the Mynewt simulator.
> >  * Contains the NimBLE host and UART BLE transport.
> >  * Caches information about connected peers (who is connected and how
> >their services, characteristics, and descriptors map to attribute
> >handles).
> >  * Communicates with other processes via JSON over a streaming UNIX 
> > domain
> >socket.
> >  * Exposes the host API via JSON-encoded requests, responses, and
> >events.
> >
> > * Controller is accessed via UART device (/dev/cu.<...>).  This could be
> >a Mynewt device running the blehci app, or any other controller.
> >
> > The blehostd app solves a few problems for us:
> >  * Fixes the bugginess and lack of cross platform support in
> >newtmgr (caused by the gatt library).
> >  * Exposes a generic interface into the NimBLE host for software
> >other than newtmgr.
> >
> > Here is how I envision newtmgr using BLE:
> >
> > 1. If an instance of blehostd isn't already running for this
> > controller [*]:
> >  a. Open and bind to a socket.
> >  b. Start an instance of blehostd, passing it the socket filename
> > and the controller's /dev filename.
> >
> > 2. Newtmgr tells blehostd to connect to the destination device.
> >  If the device is already connected: blehostd immediately responds,
> >  indicating the connection handle of the device.
> >  Else: The response indicates that the connection attempt is in
> >  progress.  Eventually, blehostd sends an event indicating
> >  success and a connection handle, or failure.
> >
> > 3. Newtmgr asks blehostd if the peer's newtmgr characteristic has been
> > discovered yet.
> >  Yes: blehostd's response indicates the characteristic's
>

Re: NimBLE host advertising data API

[Christopher Collins]

On Tue, Jan 24, 2017 at 12:40:04PM -0800, will sanfilippo wrote:
> I am not sure I have any intelligent comments on this, but that has never 
> stopped me from commenting in the past, so…

No worries.  Thanks for the feedback!

> 
> I think a byte buffer interface is fine as long as you have helper functions 
> to create that buffer. Having folks have to figure out how to create an 
> advertisement without any helper functions would be a bad idea (imho).
> 
> I am not sure I completely understand your example re:Tx Power Level. Would 
> this field still get added by the host or would there be a helper function 
> that a developer could call to add the Tx Power Level field to the 
> advertisement?

The host wouldn't modify the advertising data at all.  If the
application wants to advertise the tx power level, it would need to
arrange for it to be written to the byte buffer.  If using the helper
function, the application would write the correct value to the
tx_pwr_lvl field in the ble_hs_adv_fields struct before converting the
struct to a byte array.  The application would either "just know" the
correct value, or it would query the host prior to building the
advertising data buffer.

Chris

Newtmgr over BLE

[Christopher Collins]

Hello all,

Recently, I have mentioned some planned BLE-related changes to the
newtmgr tool.  I wanted to share some of what I was thinking.  Please
feel free to comment and criticize as needed.

* All BLE code gets removed from the newtmgr tool.  The gatt library is
  also removed.

* A separate tool, blehostd, runs in its own process.  This tool:
* Is a Mynewt app running in the Mynewt simulator.
* Contains the NimBLE host and UART BLE transport. 
* Caches information about connected peers (who is connected and how
  their services, characteristics, and descriptors map to attribute
  handles).
* Communicates with other processes via JSON over a streaming UNIX domain
  socket.
* Exposes the host API via JSON-encoded requests, responses, and
  events.

* Controller is accessed via UART device (/dev/cu.<...>).  This could be
  a Mynewt device running the blehci app, or any other controller.

The blehostd app solves a few problems for us:
* Fixes the bugginess and lack of cross platform support in
  newtmgr (caused by the gatt library).
* Exposes a generic interface into the NimBLE host for software
  other than newtmgr.

Here is how I envision newtmgr using BLE:

1. If an instance of blehostd isn't already running for this
   controller [*]:
a. Open and bind to a socket.
b. Start an instance of blehostd, passing it the socket filename
   and the controller's /dev filename.

2. Newtmgr tells blehostd to connect to the destination device.
If the device is already connected: blehostd immediately responds,
indicating the connection handle of the device.
Else: The response indicates that the connection attempt is in
progress.  Eventually, blehostd sends an event indicating
success and a connection handle, or failure.

3. Newtmgr asks blehostd if the peer's newtmgr characteristic has been
   discovered yet.
Yes: blehostd's response indicates the characteristic's
attribute handle.
No: newtmgr tells blehostd to discover the newtmgr
characteristic.  After discovery completes, newtmgr repeats
this step so that it knows the characteristic's value handle.

4. Newtmgr builds the CBOR newtmgr request, as always.

5. Newtmgr encodes the CBOR newtmgr request as a bluetooth ATT write
   command, and tells blehostd to write it to the peer's newtmgr
   characteristic.

6. blehostd immediately responds, indicating success or failure.

7. If successful, blehostd sends an event containing to the peer's
   notification (corresponding to its newtmgr response).

[*] This might be a bit tricky to get right.  The goal is to not have to
connect and perform service discovery for each newtmgr command.
Ideally, blehostd would stick around until some idle timeout is
exceeded.  Then, newtmgr could just reuse the existing socket and
blehostd instance to immediately send a follow-up command.  This is more
of an optimization, so it can probably come later.

All comments welcome.

Thanks,
Chris

Re: push more often (was: [01/50] incubator-mynewt-core git commit: ...)

[Christopher Collins]

Those commits were made to a different branch:

> >>> Repository: incubator-mynewt-core
> >>> Updated Branches:
> >>>  refs/heads/sensors_branch 6247b5afa -> 2681044e8

That mass of commits was just a big merge from develop to
sensors_branch.  Sterling was just bringing sensors_branch up to date
with develop.

I've also been confused by git commit emails sometimes.  You have to
double check the branch name!

Chris

On Tue, Jan 24, 2017 at 04:02:40PM +, Wayne Keenan wrote:
> 
> 
> > On 24 Jan 2017, at 15:56, Peter Saint-Andre - Filament  
> > wrote:
> > 
> > Things seem pretty transparent around here to me!
> > 
> 
> I'd say so, and I'd trust Sterling's commits, but,  'Review Harder', if you 
> like :)
> 
> >> On 1/24/17 12:41 AM, Greg Stein wrote:
> >> commit 1 of 50 ??
> >> 
> >> This says to me: push more often. How can the mynewt community review your
> >> work, if you never push it?
> >> 
> >>> On Mon, Jan 23, 2017 at 9:02 PM,  wrote:
> >>> 
> >>> Repository: incubator-mynewt-core
> >>> Updated Branches:
> >>>  refs/heads/sensors_branch 6247b5afa -> 2681044e8
> >>> 
> >>> 
> >>> nimble/sm: Use TinyCrypt for AES
> >>> 
> >>> TinyCrypt is smaller than mbedTLS and is already used for ECDH.
> >>> Using TC for all crypto in SM results in following code size reductions
> >>> for bletiny application:
> >>> 
> >>> Legacy Pairing only from
> 250 277 *fill*
>   11160   0 crypto_mbedtls.a
>   485813410 net_nimble_host.a
>  1449922784   15788  163564   27eec apps/bletiny/bletiny.elf
> >>> 
> >>> to
> >>> < 252 277 *fill*
> >>> <1112   0 crypto_tinycrypt.a
> >>> <   485633130 net_nimble_host.a
> >>> <  1349282784   15508  153220   25684 app/apps/bletiny/bletiny.elf
> >>> 
> >>> Legacy + LE SC from
> 264 276 *fill*
>   11160   0 crypto_mbedtls.a
>   518813627 net_nimble_host.a
>  1522722980   16004  171256   29cf8 app/apps/bletiny/bletiny.elf
> >>> 
> >>> to
> >>> < 254 276 *fill*
> >>> <   518633347 net_nimble_host.a
> >>> <  1410842980   15724  159788   2702c app/apps/bletiny/bletiny.elf
> >>> 
> >>> 
> >>> Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-core/repo
> >>> Commit: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-
> >>> core/commit/2785cad5
> >>> Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-
> >>> core/tree/2785cad5
> >>> Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-
> >>> core/diff/2785cad5
> >>> 
> >>> Branch: refs/heads/sensors_branch
> >>> Commit: 2785cad50147160d21bef9aef143199f294ed093
> >>> Parents: a46fdfe
> >>> Author: Szymon Janc 
> >>> Authored: Wed Jan 18 14:24:44 2017 +0100
> >>> Committer: Szymon Janc 
> >>> Committed: Wed Jan 18 14:54:44 2017 +0100
> >>> 
> >>> --
> >>> net/nimble/host/pkg.yml  |  2 +-
> >>> net/nimble/host/src/ble_sm_alg.c | 21 +++--
> >>> 2 files changed, 8 insertions(+), 15 deletions(-)
> >>> --
> >>> 
> >>> 
> >>> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-
> >>> core/blob/2785cad5/net/nimble/host/pkg.yml
> >>> --
> >>> diff --git a/net/nimble/host/pkg.yml b/net/nimble/host/pkg.yml
> >>> index f7539a4..d025934 100644
> >>> --- a/net/nimble/host/pkg.yml
> >>> +++ b/net/nimble/host/pkg.yml
> >>> @@ -31,7 +31,7 @@ pkg.deps:
> >>> - util/mem
> >>> 
> >>> pkg.deps.BLE_SM_LEGACY:
> >>> -- crypto/mbedtls
> >>> +- crypto/tinycrypt
> >>> 
> >>> pkg.deps.BLE_SM_SC:
> >>> - crypto/tinycrypt
> >>> 
> >>> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-
> >>> core/blob/2785cad5/net/nimble/host/src/ble_sm_alg.c
> >>> --
> >>> diff --git a/net/nimble/host/src/ble_sm_alg.c
> >>> b/net/nimble/host/src/ble_sm_alg.c
> >>> index 8a5365d..f8208b4 100644
> >>> --- a/net/nimble/host/src/ble_sm_alg.c
> >>> +++ b/net/nimble/host/src/ble_sm_alg.c
> >>> @@ -28,20 +28,15 @@
> >>> #include "nimble/ble.h"
> >>> #include "nimble/nimble_opt.h"
> >>> #include "ble_hs_priv.h"
> >>> -#include "mbedtls/aes.h"
> >>> -
> >>> -#if MYNEWT_VAL(BLE_SM_SC)
> >>> -
> >>> #include "tinycrypt/aes.h"
> >>> #include "tinycrypt/constants.h"
> >>> #include "tinycrypt/utils.h"
> >>> +
> >>> +#if MYNEWT_VAL(BLE_SM_SC)
> >>> #include "tinycrypt/cmac_mode.h"
> >>> #include "tinycrypt/ecc_dh.h"
> >>> -
> >>> #endif
> >>> 
> >>> -static mbedtls_aes_context ble_sm_alg_ctxt;
> >>> -
> >>> static void
> >>> ble_sm_alg_xor_128(uint8_t *p, uint8_t *q, uint8_t *r)
> >>> {
> >>> @@ -55,22 +50,20 @@ ble_sm_alg_xor_128(uint8_t *p, uint8_t *q, uint8_t *r)
> >>> static int
> >>> ble_sm_alg_encrypt(uint8_t *key, uint8_t *plaintext, uint8_t 

Re: bleuart example causes crash

[Christopher Collins]

Hi Chew,

It looks like the problem is a broken task handler.  In bleuart's
main.c, the bleuart_task_handler() function should call os_eventq_run()
in an infinite loop, but it only calls it once.

Marko just fixed this bug in develop with his default task changes.

Chris

On Fri, Jan 20, 2017 at 06:00:45PM +, Lm Chew wrote:
> [https://tr.cloudmagic.com/h/v6/emailtag/tag/1484935225/e07327a00ce48c6feaf5c6318fd5666d/98148963e301c00d168ac75868cda51d/89bf195313601b8fc94e962f71ed9d07/7d73f5719844943a877cfefbca240ecc/newton.gif]
> 
> Hi Chris,
> 
> Thanks.
> 
> Yeah, it is good to have for sending debug messages and receiving command 
> wirelessly for device that doesn't have physical UART interface built into 
> the design.
> 
> Best Regards,
> Chew
> 
> 
> On Sat, Jan 21, 2017 at 12:34am, Christopher Collins 
> <ccoll...@apache.org<mailto:ccoll...@apache.org>> wrote:
> 
> On Fri, Jan 20, 2017 at 09:41:24AM +, Lm Chew wrote:
> > Hi,
> >
> >
> > Does any one have problem running the bleuart example?
> >
> > When I run it, it crashes in the end with Unhandled interrupt error. (I am 
> > using bmd300eval)
> > I got the following debug output:
> 
> It has been quite a while since I have run bleuart.  I'll take a look at
> it today.  In the meantime, are you sure you need the bleuart
> functionality?  Just to be cler, this app implements a somewhat scaled
> down version of the Nordic BLE serial port emulation service.
> 
> Chris

Re: Program board without J-Link/OpenOCD.

[Christopher Collins]

Hi Marcos,

I don't know if I can solve this problem, but I can at least answer a
few of your questions.  Hopefully someone more knowledgeable can fill in
the gaps.

On Mon, Jan 23, 2017 at 02:34:11PM -0200, Marcos Scheeren wrote:
[...]
> To my understanding, the newt create-image command outputs an .img with the
> bootloader sector, the sectors headers, and the two application sectors,
> needed for the bootloader to properly locate, identify and load the
> applications.

The .img file only contains:
* image header
* image binary

The contents of a .img file occupy a single image slot.  The boot loader
slot and the second image slot are untouched when you upload an image.

A .img file, as opposed to a .bin file, is only useful if you are using
the boot loader.  The boot loader knows how to read the image header and
determine where the image executable actually begins.  If you aren't
using a boot loader, then you need to upload a .bin file to address 0 so
that the hardware jumps straight into the image on boot.  This process
is minimally described here:
https://mynewt.apache.org/latest/os/modules/split/split/

> And my "low-level bootloader knowledge" ends here :( So the questions are:
> 
> - Are there any ways to output a single .elf or .bin file already with the
> sectors headers (maybe convert the .img file) so I can load it using the
> GDB extended-remote mode? Or that would require further work, like changing
> the newt golang sources?

That sounds like a manufacturing image.  A manufacturing image contains
the entire contents of a device's flash; it is intended to be built into
every unit during the early stages of manufacturing.  In particular, a
manufacturing image contains:
* boot loader
* image in slot 0
* (optional) image in slot 1 or split image
* (optional) user data

There is some basic documentation for creating mfg images here:
http://mynewt.apache.org/latest/newt/command_list/newt_mfg/

This process should definitely work, as we use it frequently.  However,
the documentation may be lacking, so please don't hestitate to follow up
with questions.

> Thanks.
> Other than that, really appreciate the architecture of the OS!

Chris

Re: MBUF sizing for the bluetooth stack

[Christopher Collins]

On Sun, Jan 22, 2017 at 09:16:59AM -0800, Christopher Collins wrote:
> There are some optimizations that could be done here.  In most cases,
> the host is interested in the full attribute value.  The host should
> probably allocate GATT read mbufs using ble_hs_mbuf_att_pkt() in these
> cases so that it can just send the mbuf after the application has filled
> it.

Btw, I went ahead and implemented / pushed this optimization.

Chris

[jira] [Created] (MYNEWT-555) BLE Host - Avoid mbuf copy on chr read

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-555:
--

 Summary: BLE Host - Avoid mbuf copy on chr read
 Key: MYNEWT-555
 URL: https://issues.apache.org/jira/browse/MYNEWT-555
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins
 Fix For: v1_0_0_rel


When the host receives any form of characteristic read request, an extraneous 
mbuf gets allocated.  The sequence is:

* Allocate new mbuf.
* Pass new mbuf to application code so app can fill in characteristic value.
* Copy characteristic value out of new mbuf into response mbuf
* Free new mbuf

The reason for the extra allocation is to simplify reads that specify non-zero 
offsets. In the case of a GATT read, the peer may read from different offsets 
of the characteristic. In an effort to simplify the API, I decided the 
requested offset should be hidden from the application.  Instead, the 
application always provides the full characteristic value, and the host copies 
the requested portion out of the user-filled mbuf and into the ACL data packet.

The fix is to try to reuse the response to hold the characteristic data.  This 
can be done if the read request specifies an offset of 0.  For non-zero 
offsets, the old behavior remains: allocate an extra mbuf and copy the data.

Additional context: 
https://lists.apache.org/thread.html/78358745716cac9512b3c659dfe9b9b7bbb1354ee4c38d6da137bcc0@%3Cdev.mynewt.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: MBUF sizing for the bluetooth stack

[Christopher Collins]

On Fri, Jan 20, 2017 at 02:27:41PM -0800, Simon Ratner wrote:
> I am talking about GATT reads, where the mbuf is pre-allocated for the app
> to fill in:
> 
> - static int
> - gatt_svr_chr_access_gap(
> -   uint16_t conn_handle,
> -   uint16_t attr_handle,
> -   struct ble_gatt_access_ctxt *ctxt, void *arg)
> - {
> -   ...
> -   os_mbuf_append(ctxt->om, data, len);
> -   ...
> - }
> -
> - Similarly, GATT read ops triggered by ble_gatt_chr_updated for sending
> out notifications.

These mbufs never actually get sent to the controller, so they don't
need the extra leading space.  After the application fills one of these
mbufs with a characteristic's value, the host copies the relevant data
into a properly allocated mbuf and sends the copy.

This may seem wasteful (in fact, that's what I'm thinking as I write
this!), but there is at least some logic here.  In the case of a GATT
read, the peer may read from different offsets of the characteristic.
In an effort to simplify the API, I decided the requested offset should
be hidden from the application.  Instead, the application always
provides the full characteristic value, and the host copies the
requested portion out of the user-filled mbuf and into the ACL data
packet.

There are some optimizations that could be done here.  In most cases,
the host is interested in the full attribute value.  The host should
probably allocate GATT read mbufs using ble_hs_mbuf_att_pkt() in these
cases so that it can just send the mbuf after the application has filled
it.

Alternatively, the host could specify the offset and length being read,
and require the application to provide only the requested range of
bytes.  This would be a little messier, but would be the most mbuf
efficient.

I'm thinking we should do the first optimization immediately.  I don't
believe it would be much work, and I don't see any downsides.  I'll take
a closer look at it today.

Chris

Re: Firmware update with MyNewt

[Christopher Collins]

Hi Then,

On Sun, Jan 22, 2017 at 08:39:45AM +0800, then yon wrote:
> Dear Jacob,
> 
> Thanks for your verification, so that means i need to use newtmgr for 
> ota update.
> 
> I tried on newtmgr but i stuck when i tried to do something with the 
> remote endpoint.
> 
> Here what i did:
> 
> 
> Then it stuck there, it same for any other command that required 
> interaction with remote endpoint.
> 
> My remote endpoint is nrf52dk board with bootloader and a working app 
> loaded.
> 
> Another noob question here, how do i add a newtmge ota update conn? Is 
> that add a ble conn?

I recommend trying the "slinky" app.  This app is configured to support
newtmgr and image management, so you can use it to verify that your
serial setup is correct.

To support newtmgr in your app, you will need to:

1. Make sure the following packages get pulled in to the build:

- mgmt/imgmgr
- mgmt/newtmgr
- mgmt/newtmgr/transport/nmgr_shell
- sys/console/full
- sys/shell

The easiest way to do this is to add these entries to your app's or
target's pkg.yml file, in the "pkg.deps" section.

2. Enable the SHELL_TASK syscfg setting.  You can do this by adding the
following lines to your app's or target's syscfg.yml file:

syscfg.vals:
# Enable the shell task.
SHELL_TASK: 1

If "syscfg.vals" is already present in the file, then you just need to
add the "SHELL_TASK: 1" line under it.

Chris

Re: MBUF sizing for the bluetooth stack

[Christopher Collins]

On Fri, Jan 20, 2017 at 01:21:20PM -0800, Simon Ratner wrote:
> On Fri, Jan 20, 2017 at 9:01 AM, Christopher Collins <ccoll...@apache.org>
> wrote:
> > On Thu, Jan 19, 2017 at 11:57:01PM -0800, Simon Ratner wrote:
> > > When allocating mbufs for the payload, is there something I should do to
> > > reserve enough leading space for the ACL header to make sure host doesn't
> > > need to re-allocate it?
> >
> > Yes - you should use ble_hs_mbuf_att_pkt() to allocate all your mbufs.
> > This function ensures the resulting mbuf has sufficient leading space
> > for:
> > * ACL data header
> > * Basic L2CAP header
> > * Four bytes for an ATT command
> >
> 
> And I assume the mbuf passed into gatt read handlers (ctxt->om) has been
> allocated that way? I only need to worry about the mbufs I allocate myself,
> such as for notify payload.

The mbufs handed up from the host are typically allocated by something
else (e.g., for the combined host-controller, it is the controller which
allocates them).  If you pass these mbufs back to the host, there is a
chance the host will need to allocate an additional buffer while
prepending to the chain.  The host stripped the headers from the front
of the mbuf before handing it to the application, so there will be
sufficient leading space to add them back.  However, the problem is the
variable length ATT command.  Your outgoing command may require more
"ATT bytes" than the one you received.

Do you often pass these mbufs back to the host?  I thought that would be
an uncommon use case.

Chris

Re: [RFC] Reducing size of BLE Security Manager

[Christopher Collins]

On Fri, Jan 20, 2017 at 09:45:07AM -0800, will sanfilippo wrote:
> I was referring to C code that accesses a packed structure, not necessarily 
> the construction part of it. For example: (and in this example I am assuming 
> the processor can access bytes anywhere, 16-bit values on 16-bit boundaries 
> and 32-bit values on 32-bit boundaries).
> 
> struct my_struct
> {
>   uint8_t e8;
>   uint16_t e16;
>   uint32_t e32;
> } __packed__  /* I know this syntax is wrong, just an example */
> struct my_struct my_data
> 
> In your C code when you do this: my_data.e32 = 50, what is the
> compiler going to do? If the structure is not packed, it knows it can
> use an instruction that accesses words. If the structure is packed,
> well, I guess it is up to the compiler what to do. In the past, I have
> seen compilers that add code or call functions that will check the
> alignment of e32. If e32 happens to reside on a 4-byte boundary it
> will use a word instruction; if it happens to reside on a byte
> boundary it needs to access the bytes individually to put them in a
> register for use.

I'm not really adding anything here, but here is something I realized
recently.  When you tell gcc to pack a struct, it has two effects:

1. Eliminates padding.
2. Assumes instances of the struct are not properly aligned.

For MCUs which don't support unaligned accesses, the second effect may
carry some hidden costs.  Even if the struct is defined such that it
wouldn't contain any padding, and even if all instances of the struct
are properly aligned, adding the __packed__ attribute will result in an
increase in code size.  The increase occurs because gcc can no longer
assume that the struct or any of its members are aligned.

Chris

Re: MBUF sizing for the bluetooth stack

[Christopher Collins]

On Thu, Jan 19, 2017 at 11:57:01PM -0800, Simon Ratner wrote:
> Thanks Chris,
> 
> It appears to me that there is questionable benefit to having mbufs sized
> larger than the largest L2CAP fragment size (plus overhead), i.e. the 80
> bytes that Will mentioned. Is that a reasonable statement, or am I missing
> something?
> 
> For incoming data, you always waste memory with larger mbufs, and for
> outgoing data host will take longer to free the memory (since you can't
> free the payload mbuf until the last fragment, as opposed to freeing
> smaller mbufs as you go), and you don't save on the number of copies in the
> host. You will save something on mbuf allocations and mbuf header overhead
> in the app as you are generating the payload, though.

I agree with your analysis.  This is just for BLE data, of course.  If
you use msys for other things (e.g., an alternative to malloc for
internal use), that obviously has an affect on the optimum msys buffer
size.

> When allocating mbufs for the payload, is there something I should do to
> reserve enough leading space for the ACL header to make sure host doesn't
> need to re-allocate it?

Yes - you should use ble_hs_mbuf_att_pkt() to allocate all your mbufs.
This function ensures the resulting mbuf has sufficient leading space
for:
* ACL data header
* Basic L2CAP header
* Four bytes for an ATT command

The last item (four bytes) is imprecise because different ATT commands
have different payload sizes, and this function doesn't know which
command you'll be sending.  Four bytes is the most the host would never
need to prepend to application attribute data.

We should expose some more functions from
net/nimble/host/src/ble_hs_mbuf.c that give the user more control over
the amount of leading space.  This would be useful for when the
application wants to send an ATT command that doesn't need the full four
bytes.

Just to be clear - if you allocate an mbuf that lacks sufficient leading
space (e.g., via os_msys_get_pkthdr()) and pass it to the host, the host
won't reallocate and copy the entire chain; it will just allocate a
single buffer and prepend it to the chain.  This is still wasteful, but
it can be completely avoided by using the ble_hs_mbuf_att_pkt()
function.

> Also, at least in theory, it sounds like you could size mbufs to match the
> fragment exactly -- or pre-fragment the mbuf chain as you are generating
> the payload -- and have zero copies in the host. Could be useful in a
> low-memory situation, if the host was smart enough to take advantage of
> that?

The host isn't smart enough :).  The complication arises from the
"os_mbuf_pkthdr" that the leading buffer contains.  The presence of this
header causes the first buffer to have less capacity than subsequent
buffers.  The fragmentation procedure never frees the chain's leading
buffer.  The assumption is that the data is packed in the mbuf chain,
and that the second buffer doesn't have sufficient leading space to
contain the pkthdr.

A smarter procedure might check how much unused space the second buffer
contains.  If there is sufficient room for the pkthdr, the procedure
would move the data to make room for the pkthdr at the front of the
buffer, then copy the pkthdr into the buffer.  After this, the leading
buffer could be freed.  This might be worth looking into.

Thanks,
Chris