Re: Newtmgr over BLE not Working

[Szymon Janc]

Hi,

On Sunday, 26 March 2017 18:23:52 CEST will sanfilippo wrote:
> Not sure what is going on there, but the command that you show is a BR/EDR
> command and not a LE command, which is why you get a unknownn HCI command.
> The controller does not support that command.

This is simply due to GATT library used by newtmgmr assumes that controller is 
dual mode. See snipped below:

func (h *HCI) resetDevice() error {
seq := []cmd.CmdParam{
cmd.Reset{},
cmd.SetEventMask{EventMask: 0x3dbff807fffb},
cmd.LESetEventMask{LEEventMask: 0x001F},
cmd.WriteSimplePairingMode{SimplePairingMode: 1},
cmd.WriteLEHostSupported{LESupportedHost: 1, 
SimultaneousLEHost: 0},
cmd.WriteInquiryMode{InquiryMode: 2},
cmd.WritePageScanType{PageScanType: 1},
cmd.WriteInquiryScanType{ScanType: 1},
cmd.WriteClassOfDevice{ClassOfDevice: [3]byte{0x40, 0x02, 
0x04}},
cmd.WritePageTimeout{PageTimeout: 0x2000},
cmd.WriteDefaultLinkPolicy{DefaultLinkPolicySettings: 0x5},
cmd.HostBufferSize{
HostACLDataPacketLength:0x1000,
HostSynchronousDataPacketLength:0xff,
HostTotalNumACLDataPackets: 0x0014,
HostTotalNumSynchronousDataPackets: 0x000a},
cmd.LESetScanParameters{
LEScanType:   0x01,   // [0x00]: passive, 0x01: 
active
LEScanInterval:   0x0010, // [0x10]: 0.625ms * 16
LEScanWindow: 0x0010, // [0x10]: 0.625ms * 16
OwnAddressType:   0x00,   // [0x00]: public, 0x01: 
random
ScanningFilterPolicy: 0x00,   // [0x00]: accept all, 
0x01: ignore 
non-white-listed.
},
}
for _, s := range seq {
if err := h.c.SendAndCheckResp(s, []byte{0x00}); err != nil {
return err
}
}
return nil


For now I suggest using dualmode dongle (ie one from laptop or any stock USB 
BT dongle).


> > On Mar 26, 2017, at 12:45 AM, Lm Chew  wrote:
> > 
> > Hi Vipul,
> > 
> > Thanks, for the suggestion.
> > 
> > 1. changed to using:
> > sudo $(which newtmgr) -c ble image upload slinky.img -ldebug
> > 
> > 2. double checked, i have pulled the latest from develop branch and build
> > it. I have also updated blueZ to the latest 5.44 just in case.
> > 
> > 3. I have physically removed the bluetooth module installed in my laptop
> > to eliminate the complication, so now I got only hci0 available.
> > 
> > For some odd reason I was able to make 2 successful upload, but not
> > sequentially. Since then i can't get it to work again, could this be
> > something to do with USB bluetooth adapter could not get the timing
> > right?
> > 
> > Could you tell me what USB bluetooth adapter are you using?
> > 
> > I also tried setting up a nrf52 DK with blehci app + BlueZ as explained in
> > this tutorial(with a few changes). -
> > http://mynewt.apache.org/latest/os/tutorials/blehci_project/
> > - Use this to connect with btattach instead: sudo btattach -B /dev/ttyACM0
> > -S 100 -P h4 - Skip the btmgmt step since in BlueZ 5.44 we no longer
> > need to set the static-address manually and newtmgr will handle the rest.
> > - Used the nrf52 DK onboard USB to UART bridge, did not use a FTDI USB
> > TTL Serial Cable.
> > 
> > But unfortunately I can't get it to work either, in fact it is one step
> > backward.
> > 
> > When i tried sending:
> > sudo $(which newtmgr) -c ble image list -ldebug
> > 
> > I get stuck at:
> > 2017/03/26 15:22:57 [DEBUG] BLE Connection devaddr:[]
> > 2017/03/26 15:22:57 dev: hci0 up
> > 2017/03/26 15:22:57 dev: hci0 down
> > 2017/03/26 15:22:57 dev: hci0 opened
> > 2017/03/26 15:22:57 [DEBUG] State:PoweredOn
> > 2017/03/26 15:22:57 [DEBUG] scanning...
> > 
> > I have also attached the btmon response
> > 
> > I noticed this line in the btmon log that was highlighted in red in the 
terminal:
> > > HCI Event: Command Complete (0x0e) plen 4   [hci0]
> > > 4309.724132> > 
> >   Write Simple Pairing Mode (0x03|0x0056) ncmd 1
> >   
> > Status: Unknown HCI Command (0x01)
> > 

-- 
pozdrawiam
Szymon Janc

Re: Newtmgr over BLE not Working

[Lm Chew]

Hi Vipul,


Thanks for the info on the bluetooth chipset.

I like to purchase the same BLE Adapter as yours to do some more testing, can 
you send me a link for it?


So far I have tried 2 chipset one from Intel and one from Cambridge Silicon 
Radio, both of this got stuck in the same area(Disconnected).


The only broadcom chipset I have on hand is the Raspberry Pi 3's own BCM43438 
radio chip which have BLE 4.1 support.

So I set up go 1.8 for ARMv6 on the RPI3 then build and run the same 2 newtmgr 
to get the image info & to upload the image via ble.

sudo $(which newtmgr) -c myble image list
sudo $(which newtmgr) -c myble image upload slinky.img


And this time it worked like a charm on the RPI3.

It just work out of the box with the following image:sudo ls /dev
- "Raspbian Jessie With Pixel Release date:2017-03-02"


So now i am curious to see if the USB BLE Adapter that didn't work on Ubuntu 
before will work if I used the RPI3 instead.

First I disable the RPI3 bluetooth by adding this line to the 
"dtoverlay=pi3-disable-bt" to the "/boot.config.txt" file and then reboot.


Then I plug it in and run the same 2 newtmgr command, and the result is that it 
got stuck in the same area(Disconnected).


>From this result, does this mean the ble update will only work with certain 
>ble chipset?

Have anyone tried it with different ble chipset?


Hi Chris,


I have tried running MSDDisable in JLinkExe and added that value to blechi 
syscfg.yml.

But I still cant get it to work.


Attached is the btmon log.


Best Regards,

Chew


From: Christopher Collins <ch...@runtime.io>
Sent: Tuesday, 28 March, 2017 5:32:52 AM
To: dev@mynewt.incubator.apache.org
Cc: Yz Then; Meili Yeo
Subject: Re: Newtmgr over BLE not Working

Hi Lm,

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

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

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

MSDDisable

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

syscfg.vals:
BLE_ACL_BUF_SIZE: 128

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

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

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

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

Thanks,
Chris

Re: Newtmgr over BLE not Working

[Christopher Collins]

Hi Lm,

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

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

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

MSDDisable

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

syscfg.vals:
BLE_ACL_BUF_SIZE: 128

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

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

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

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

Thanks,
Chris

Re: Newtmgr over BLE not Working

[Vipul Rahane]

Hello,

Please find the answers below:

> On Mar 26, 2017, at 12:45 AM, Lm Chew <lm.c...@free2move.se> wrote:
> 
> Hi Vipul,
> 
> Thanks, for the suggestion.
> 
> 1. changed to using:
> sudo $(which newtmgr) -c ble image upload slinky.img -ldebug
> 
> 2. double checked, i have pulled the latest from develop branch and build it. 
> I have also updated blueZ to the latest 5.44 just in case.
> 
> 3. I have physically removed the bluetooth module installed in my laptop to 
> eliminate the complication, so now I got only hci0 available.
> 
> For some odd reason I was able to make 2 successful upload, but not 
> sequentially. Since then i can't get it to work again, could this be 
> something to do with USB bluetooth adapter could not get the timing right?
> 

I did try uploading images sequentially on Friday itself since I was making 
sure everything was working fine. It seemed ok that day. Are you doing reboots 
between upgrades or you just uploading the same image repeatedly with doing a 
complete upgrade ?

> Could you tell me what USB bluetooth adapter are you using?

I am using Broadcom Corp. BCM20702A0 Bluetooth 4.0.

> 
> I also tried setting up a nrf52 DK with blehci app + BlueZ as explained in 
> this tutorial(with a few changes).
> - http://mynewt.apache.org/latest/os/tutorials/blehci_project/ 
> <http://mynewt.apache.org/latest/os/tutorials/blehci_project/>
> - Use this to connect with btattach instead: sudo btattach -B /dev/ttyACM0 -S 
> 100 -P h4
> - Skip the btmgmt step since in BlueZ 5.44 we no longer need to set the 
> static-address manually and newtmgr will handle the rest.
> - Used the nrf52 DK onboard USB to UART bridge, did not use a FTDI USB TTL 
> Serial Cable.
> 

I haven’t tried it with blehci. So not sure. Someone more experienced with 
blehci might be of more help than I am. I will let Chris/Will answer that. 

> But unfortunately I can't get it to work either, in fact it is one step 
> backward.
> 
> When i tried sending:
> sudo $(which newtmgr) -c ble image list -ldebug
> 
> I get stuck at:
> 2017/03/26 15:22:57 [DEBUG] BLE Connection devaddr:[]
> 2017/03/26 15:22:57 dev: hci0 up
> 2017/03/26 15:22:57 dev: hci0 down
> 2017/03/26 15:22:57 dev: hci0 opened
> 2017/03/26 15:22:57 [DEBUG] State:PoweredOn
> 2017/03/26 15:22:57 [DEBUG] scanning...
> 
> I have also attached the btmon response 
> 
> I noticed this line in the btmon log that was highlighted in red in the 
> terminal:
> > HCI Event: Command Complete (0x0e) plen 4   [hci0] 
> > 4309.724132
>   Write Simple Pairing Mode (0x03|0x0056) ncmd 1
> Status: Unknown HCI Command (0x01)
> 
> Best Regards,
> Chew
> From: Vipul Rahane <vi...@runtime.io>
> Sent: Saturday, 25 March, 2017 9:05:19 AM
> To: dev@mynewt.incubator.apache.org
> Cc: Yz Then; Meili Yeo
> Subject: Re: Newtmgr over BLE not Working
>  
> Hello,
> 
> I think there could be a couple of things causing this. 
> 
> 1. sudo "$(which newtmgr)" -c ble image upload '/slinky/slinky.img’ . Please 
> try removing single quotes and try again. I tried with/without single quotes. 
> It works fine without them and doesn’t work with them.
> 
> 2. newt repo is not updated and so you have an old version of newtmgr. Please 
> try to update newtmgr and rebuild it. 
> 
> 3. newtmgr uses paypal/GATT library in the background. We have observed that 
> this library has issues when there are more than one bluetooth radios 
> connected to the linux box. Please disconnect one and try again or you might 
> have to disable/blacklist one of them. you can do so by using the following 
> command:
> “sudo hciconfig hci0 down”. I am not sure which radio you would want to use 
> exactly. If you want to use the other radio just issue the command with hci1 
> instead.
> 
> 3 above might be the most probable reason for your failure to upload because 
> in the output you pasted below I see two hci interfaces:
> 
> >>> 2017/03/24 15:16:04 dev: hci0 up
> >>> 2017/03/24 15:16:04 dev: hci1 up
> >>> 2017/03/24 15:16:04 dev: hci1 reset
> >>> 2017/03/24 15:16:04 dev: hci1 down
> >>> 2017/03/24 15:16:04 dev: hci1 opened
> 
> 
> 
> Regards,
> Vipul Rahane
> 
> > On Mar 24, 2017, at 4:54 PM, Lm Chew <lm.c...@free2move.se> wrote:
> > 
> > Hi Vipul,
> > 
> > 
> > I tried changing LOG_LEVEL: 255, but it is still not working.
> > 
> > 
> > Best Regards,
> > 
> > Chew
> > 
> > 
> > From: Vipul Rahane <vi...@runtime.io>
> > Sent: Saturday, 25 March, 2017 5:42:04 AM
> > To: dev@mynewt.incub

Re: Newtmgr over BLE not Working

[Lm Chew]

Hi Vipul,


Thanks, for the suggestion.


1. changed to using:

sudo $(which newtmgr) -c ble image upload slinky.img -ldebug

2. double checked, i have pulled the latest from develop branch and build it. I 
have also updated blueZ to the latest 5.44 just in case.


3. I have physically removed the bluetooth module installed in my laptop to 
eliminate the complication, so now I got only hci0 available.


For some odd reason I was able to make 2 successful upload, but not 
sequentially. Since then i can't get it to work again, could this be something 
to do with USB bluetooth adapter could not get the timing right?


Could you tell me what USB bluetooth adapter are you using?


I also tried setting up a nrf52 DK with blehci app + BlueZ as explained in this 
tutorial(with a few changes).

- http://mynewt.apache.org/latest/os/tutorials/blehci_project/

- Use this to connect with btattach instead: sudo btattach -B /dev/ttyACM0 -S 
100 -P h4

- Skip the btmgmt step since in BlueZ 5.44 we no longer need to set the 
static-address manually and newtmgr will handle the rest.

- Used the nrf52 DK onboard USB to UART bridge, did not use a FTDI USB TTL 
Serial Cable.


But unfortunately I can't get it to work either, in fact it is one step 
backward.


When i tried sending:

sudo $(which newtmgr) -c ble image list -ldebug

I get stuck at:
2017/03/26 15:22:57 [DEBUG] BLE Connection devaddr:[]
2017/03/26 15:22:57 dev: hci0 up
2017/03/26 15:22:57 dev: hci0 down
2017/03/26 15:22:57 dev: hci0 opened
2017/03/26 15:22:57 [DEBUG] State:PoweredOn
2017/03/26 15:22:57 [DEBUG] scanning...

I have also attached the btmon response


I noticed this line in the btmon log that was highlighted in red in the 
terminal:

> HCI Event: Command Complete (0x0e) plen 4   [hci0] 4309.724132
  Write Simple Pairing Mode (0x03|0x0056) ncmd 1
Status: Unknown HCI Command (0x01)


Best Regards,

Chew


From: Vipul Rahane <vi...@runtime.io>
Sent: Saturday, 25 March, 2017 9:05:19 AM
To: dev@mynewt.incubator.apache.org
Cc: Yz Then; Meili Yeo
Subject: Re: Newtmgr over BLE not Working

Hello,

I think there could be a couple of things causing this.

1. sudo "$(which newtmgr)" -c ble image upload '/slinky/slinky.img’ . Please 
try removing single quotes and try again. I tried with/without single quotes. 
It works fine without them and doesn’t work with them.

2. newt repo is not updated and so you have an old version of newtmgr. Please 
try to update newtmgr and rebuild it.

3. newtmgr uses paypal/GATT library in the background. We have observed that 
this library has issues when there are more than one bluetooth radios connected 
to the linux box. Please disconnect one and try again or you might have to 
disable/blacklist one of them. you can do so by using the following command:
“sudo hciconfig hci0 down”. I am not sure which radio you would want to use 
exactly. If you want to use the other radio just issue the command with hci1 
instead.

3 above might be the most probable reason for your failure to upload because in 
the output you pasted below I see two hci interfaces:

>>> 2017/03/24 15:16:04 dev: hci0 up
>>> 2017/03/24 15:16:04 dev: hci1 up
>>> 2017/03/24 15:16:04 dev: hci1 reset
>>> 2017/03/24 15:16:04 dev: hci1 down
>>> 2017/03/24 15:16:04 dev: hci1 opened



Regards,
Vipul Rahane

> On Mar 24, 2017, at 4:54 PM, Lm Chew <lm.c...@free2move.se> wrote:
>
> Hi Vipul,
>
>
> I tried changing LOG_LEVEL: 255, but it is still not working.
>
>
> Best Regards,
>
> Chew
>
> 
> From: Vipul Rahane <vi...@runtime.io>
> Sent: Saturday, 25 March, 2017 5:42:04 AM
> To: dev@mynewt.incubator.apache.org
> Cc: Yz Then; Meili Yeo
> Subject: Re: Newtmgr over BLE not Working
>
> Thank you. Can you please try to disable logging and try again. You can do 
> this by setting LOG_LEVEL to 255.
>
> Regards,
> Vipul Rahane
>
>
>> On Mar 24, 2017, at 2:39 PM, Lm Chew <lm.c...@free2move.se> wrote:
>>
>> Hi Vipul,
>>
>>
>> Here is the syscfg file:
>>
>>
>> # Package: apps/bleprph
>>
>> syscfg.vals:
>>   # Use INFO log level to reduce code size.  DEBUG is too large for nRF51.
>>   LOG_LEVEL: 1
>>
>>   # Disable central and observer roles.
>>   BLE_ROLE_BROADCASTER: 1
>>   BLE_ROLE_CENTRAL: 0
>>   BLE_ROLE_OBSERVER: 0
>>   BLE_ROLE_PERIPHERAL: 1
>>
>>   # Disable unused eddystone feature.
>>   BLE_EDDYSTONE: 0
>>
>>   # Log reboot messages to a flash circular buffer.
>>   REBOOT_LOG_FCB: 1
>>   LOG_FCB: 1
>>   CONFIG_FCB: 1
>>
>>   # Enable newtmgr commands.
>>   STATS_NEWTMGR: 1
>>   LOG_NEWTMGR: 1
>>
>>   # Enable Config.
>&

Re: Newtmgr over BLE not Working

[Vipul Rahane]

Hello,

I think there could be a couple of things causing this. 

1. sudo "$(which newtmgr)" -c ble image upload '/slinky/slinky.img’ . Please 
try removing single quotes and try again. I tried with/without single quotes. 
It works fine without them and doesn’t work with them.

2. newt repo is not updated and so you have an old version of newtmgr. Please 
try to update newtmgr and rebuild it. 

3. newtmgr uses paypal/GATT library in the background. We have observed that 
this library has issues when there are more than one bluetooth radios connected 
to the linux box. Please disconnect one and try again or you might have to 
disable/blacklist one of them. you can do so by using the following command:
“sudo hciconfig hci0 down”. I am not sure which radio you would want to use 
exactly. If you want to use the other radio just issue the command with hci1 
instead.

3 above might be the most probable reason for your failure to upload because in 
the output you pasted below I see two hci interfaces:

>>> 2017/03/24 15:16:04 dev: hci0 up
>>> 2017/03/24 15:16:04 dev: hci1 up
>>> 2017/03/24 15:16:04 dev: hci1 reset
>>> 2017/03/24 15:16:04 dev: hci1 down
>>> 2017/03/24 15:16:04 dev: hci1 opened



Regards,
Vipul Rahane

> On Mar 24, 2017, at 4:54 PM, Lm Chew <lm.c...@free2move.se> wrote:
> 
> Hi Vipul,
> 
> 
> I tried changing LOG_LEVEL: 255, but it is still not working.
> 
> 
> Best Regards,
> 
> Chew
> 
> 
> From: Vipul Rahane <vi...@runtime.io>
> Sent: Saturday, 25 March, 2017 5:42:04 AM
> To: dev@mynewt.incubator.apache.org
> Cc: Yz Then; Meili Yeo
> Subject: Re: Newtmgr over BLE not Working
> 
> Thank you. Can you please try to disable logging and try again. You can do 
> this by setting LOG_LEVEL to 255.
> 
> Regards,
> Vipul Rahane
> 
> 
>> On Mar 24, 2017, at 2:39 PM, Lm Chew <lm.c...@free2move.se> wrote:
>> 
>> Hi Vipul,
>> 
>> 
>> Here is the syscfg file:
>> 
>> 
>> # Package: apps/bleprph
>> 
>> syscfg.vals:
>>   # Use INFO log level to reduce code size.  DEBUG is too large for nRF51.
>>   LOG_LEVEL: 1
>> 
>>   # Disable central and observer roles.
>>   BLE_ROLE_BROADCASTER: 1
>>   BLE_ROLE_CENTRAL: 0
>>   BLE_ROLE_OBSERVER: 0
>>   BLE_ROLE_PERIPHERAL: 1
>> 
>>   # Disable unused eddystone feature.
>>   BLE_EDDYSTONE: 0
>> 
>>   # Log reboot messages to a flash circular buffer.
>>   REBOOT_LOG_FCB: 1
>>   LOG_FCB: 1
>>   CONFIG_FCB: 1
>> 
>>   # Enable newtmgr commands.
>>   STATS_NEWTMGR: 1
>>   LOG_NEWTMGR: 1
>> 
>>   # Enable Config.
>>   CONFIG_NEWTMGR: 1
>> 
>>   # OS main/default task
>>   OS_MAIN_STACK_SIZE: 428
>> 
>> 
>> Best Regards,
>> 
>> Chew
>> 
>> 
>> From: Vipul Rahane <vi...@runtime.io>
>> Sent: Saturday, 25 March, 2017 1:38:09 AM
>> To: dev@mynewt.incubator.apache.org
>> Cc: Yz Then; Meili Yeo
>> Subject: Re: Newtmgr over BLE not Working
>> 
>> Hello,
>> 
>> Can you please send me your syscfg settings for the bleprph target ? Thank 
>> you.
>> 
>> Regards,
>> Vipul Rahane
>> 
>>> On Mar 24, 2017, at 2:05 AM, Lm Chew <lm.c...@free2move.se> wrote:
>>> 
>>> Here is the output with -ldebug:
>>> 
>>> 2017/03/24 17:01:28 [DEBUG] BLE Connection devaddr:[]
>>> 2017/03/24 17:01:28 dev: hci0 up
>>> 2017/03/24 17:01:28 dev: hci1 up
>>> 2017/03/24 17:01:28 dev: hci1 reset
>>> 2017/03/24 17:01:28 dev: hci1 down
>>> 2017/03/24 17:01:28 dev: hci1 opened
>>> 2017/03/24 17:01:28 [DEBUG] State:PoweredOn
>>> 2017/03/24 17:01:28 [DEBUG] scanning...
>>> 2017/03/24 17:01:28 [DEBUG] Peripheral Discovered: nimble-bleprph, 
>>> Address:[10 10 10 10 10 10] Address Type:0
>>> 2017/03/24 17:01:28 [DEBUG] Peripheral Connected
>>> 2017/03/24 17:01:28 [DEBUG] Newtmgr Service Found
>>> 2017/03/24 17:01:28 [DEBUG] Newtmgr Characteristic Found
>>> 2017/03/24 17:01:28 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:99 
>>> Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 
>>> 0 32 0 0 0 60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 
>>> 81 129 0 0 83 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
>>> 0 143 159 0 99 108 101 110 25 179 128 99 111 102 102 0]}
>>> 2017/03/24 17:01:28 [DEBUG] Serializing request &{Op:2 Flags:0 Len:99 
>>> Group:1 Seq:0 Id:1 Data:[163 100 100 97 

Re: Newtmgr over BLE not Working

[Lm Chew]

Hi Vipul,


I tried changing LOG_LEVEL: 255, but it is still not working.


Best Regards,

Chew


From: Vipul Rahane <vi...@runtime.io>
Sent: Saturday, 25 March, 2017 5:42:04 AM
To: dev@mynewt.incubator.apache.org
Cc: Yz Then; Meili Yeo
Subject: Re: Newtmgr over BLE not Working

Thank you. Can you please try to disable logging and try again. You can do this 
by setting LOG_LEVEL to 255.

Regards,
Vipul Rahane


> On Mar 24, 2017, at 2:39 PM, Lm Chew <lm.c...@free2move.se> wrote:
>
> Hi Vipul,
>
>
> Here is the syscfg file:
>
>
> # Package: apps/bleprph
>
> syscfg.vals:
># Use INFO log level to reduce code size.  DEBUG is too large for nRF51.
>LOG_LEVEL: 1
>
># Disable central and observer roles.
>BLE_ROLE_BROADCASTER: 1
>BLE_ROLE_CENTRAL: 0
>BLE_ROLE_OBSERVER: 0
>BLE_ROLE_PERIPHERAL: 1
>
># Disable unused eddystone feature.
>BLE_EDDYSTONE: 0
>
># Log reboot messages to a flash circular buffer.
>REBOOT_LOG_FCB: 1
>LOG_FCB: 1
>CONFIG_FCB: 1
>
># Enable newtmgr commands.
>STATS_NEWTMGR: 1
>LOG_NEWTMGR: 1
>
># Enable Config.
>CONFIG_NEWTMGR: 1
>
># OS main/default task
>OS_MAIN_STACK_SIZE: 428
>
>
> Best Regards,
>
> Chew
>
> 
> From: Vipul Rahane <vi...@runtime.io>
> Sent: Saturday, 25 March, 2017 1:38:09 AM
> To: dev@mynewt.incubator.apache.org
> Cc: Yz Then; Meili Yeo
> Subject: Re: Newtmgr over BLE not Working
>
> Hello,
>
> Can you please send me your syscfg settings for the bleprph target ? Thank 
> you.
>
> Regards,
> Vipul Rahane
>
>> On Mar 24, 2017, at 2:05 AM, Lm Chew <lm.c...@free2move.se> wrote:
>>
>> Here is the output with -ldebug:
>>
>> 2017/03/24 17:01:28 [DEBUG] BLE Connection devaddr:[]
>> 2017/03/24 17:01:28 dev: hci0 up
>> 2017/03/24 17:01:28 dev: hci1 up
>> 2017/03/24 17:01:28 dev: hci1 reset
>> 2017/03/24 17:01:28 dev: hci1 down
>> 2017/03/24 17:01:28 dev: hci1 opened
>> 2017/03/24 17:01:28 [DEBUG] State:PoweredOn
>> 2017/03/24 17:01:28 [DEBUG] scanning...
>> 2017/03/24 17:01:28 [DEBUG] Peripheral Discovered: nimble-bleprph, 
>> Address:[10 10 10 10 10 10] Address Type:0
>> 2017/03/24 17:01:28 [DEBUG] Peripheral Connected
>> 2017/03/24 17:01:28 [DEBUG] Newtmgr Service Found
>> 2017/03/24 17:01:28 [DEBUG] Newtmgr Characteristic Found
>> 2017/03/24 17:01:28 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:99 
>> Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 
>> 32 0 0 0 60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 
>> 129 0 0 83 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
>> 143 159 0 99 108 101 110 25 179 128 99 111 102 102 0]}
>> 2017/03/24 17:01:28 [DEBUG] Serializing request &{Op:2 Flags:0 Len:99 
>> Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 
>> 32 0 0 0 60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 
>> 129 0 0 83 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
>> 143 159 0 99 108 101 110 25 179 128 99 111 102 102 0]} into buffer [2 0 0 99 
>> 0 1 0 1 163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 60 179 
>> 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 129 0 0 83 129 0 
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 143 159 0 99 108 
>> 101 110 25 179 128 99 111 102 102 0]
>> 2017/03/24 17:01:28 [DEBUG] Tx packet dump:
>>   02 00 00 63 00 01 00 01  a3 64 64 61 74 61 58 4f  
>> |...c.ddataXO|
>> 0010  3c b8 f3 96 24 00 00 00  20 00 00 00 3c b3 00 00  |<...$... 
>> ...<...|
>> 0020  02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
>> ||
>> 0030  00 00 01 20 f9 80 00 00  51 81 00 00 53 81 00 00  |... 
>> Q...S...|
>> 0040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
>> ||
>> 0050  00 00 00 00 00 00 00 00  00 00 00 00 8f 9f 00 63  
>> |...c|
>> 00000060  6c 65 6e 19 b3 80 63 6f  66 66 00 |len...coff.|
>>
>> 2017/03/24 17:01:28 [DEBUG] Write BLE Packet:buf::c

�ddataXO<���$ <�
 
>> ��Q�S���clen��coff len::107
>> 2017/03/24 17:01:31 [DEBUG] Disconnected%!(EXTRA )
>>
>> Seem like it get Disconnected?
>> 
>> From: Lm Chew <lm.c...@free2move.se>
>> Sent: Friday, 24 March, 2017 3:23:39 PM
>> To: dev@mynewt.incubator.apache.org
>> Cc: Yz Then; Meili Yeo
>> Subject: Newt

Re: Newtmgr over BLE not Working

[Vipul Rahane]

Thank you. Can you please try to disable logging and try again. You can do this 
by setting LOG_LEVEL to 255. 

Regards,
Vipul Rahane


> On Mar 24, 2017, at 2:39 PM, Lm Chew <lm.c...@free2move.se> wrote:
> 
> Hi Vipul,
> 
> 
> Here is the syscfg file:
> 
> 
> # Package: apps/bleprph
> 
> syscfg.vals:
># Use INFO log level to reduce code size.  DEBUG is too large for nRF51.
>LOG_LEVEL: 1
> 
># Disable central and observer roles.
>BLE_ROLE_BROADCASTER: 1
>BLE_ROLE_CENTRAL: 0
>BLE_ROLE_OBSERVER: 0
>BLE_ROLE_PERIPHERAL: 1
> 
># Disable unused eddystone feature.
>BLE_EDDYSTONE: 0
> 
># Log reboot messages to a flash circular buffer.
>REBOOT_LOG_FCB: 1
>LOG_FCB: 1
>CONFIG_FCB: 1
> 
># Enable newtmgr commands.
>STATS_NEWTMGR: 1
>LOG_NEWTMGR: 1
> 
># Enable Config.
>CONFIG_NEWTMGR: 1
> 
># OS main/default task
>OS_MAIN_STACK_SIZE: 428
> 
> 
> Best Regards,
> 
> Chew
> 
> 
> From: Vipul Rahane <vi...@runtime.io>
> Sent: Saturday, 25 March, 2017 1:38:09 AM
> To: dev@mynewt.incubator.apache.org
> Cc: Yz Then; Meili Yeo
> Subject: Re: Newtmgr over BLE not Working
> 
> Hello,
> 
> Can you please send me your syscfg settings for the bleprph target ? Thank 
> you.
> 
> Regards,
> Vipul Rahane
> 
>> On Mar 24, 2017, at 2:05 AM, Lm Chew <lm.c...@free2move.se> wrote:
>> 
>> Here is the output with -ldebug:
>> 
>> 2017/03/24 17:01:28 [DEBUG] BLE Connection devaddr:[]
>> 2017/03/24 17:01:28 dev: hci0 up
>> 2017/03/24 17:01:28 dev: hci1 up
>> 2017/03/24 17:01:28 dev: hci1 reset
>> 2017/03/24 17:01:28 dev: hci1 down
>> 2017/03/24 17:01:28 dev: hci1 opened
>> 2017/03/24 17:01:28 [DEBUG] State:PoweredOn
>> 2017/03/24 17:01:28 [DEBUG] scanning...
>> 2017/03/24 17:01:28 [DEBUG] Peripheral Discovered: nimble-bleprph, 
>> Address:[10 10 10 10 10 10] Address Type:0
>> 2017/03/24 17:01:28 [DEBUG] Peripheral Connected
>> 2017/03/24 17:01:28 [DEBUG] Newtmgr Service Found
>> 2017/03/24 17:01:28 [DEBUG] Newtmgr Characteristic Found
>> 2017/03/24 17:01:28 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:99 
>> Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 
>> 32 0 0 0 60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 
>> 129 0 0 83 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
>> 143 159 0 99 108 101 110 25 179 128 99 111 102 102 0]}
>> 2017/03/24 17:01:28 [DEBUG] Serializing request &{Op:2 Flags:0 Len:99 
>> Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 
>> 32 0 0 0 60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 
>> 129 0 0 83 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
>> 143 159 0 99 108 101 110 25 179 128 99 111 102 102 0]} into buffer [2 0 0 99 
>> 0 1 0 1 163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 60 179 
>> 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 129 0 0 83 129 0 
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 143 159 0 99 108 
>> 101 110 25 179 128 99 111 102 102 0]
>> 2017/03/24 17:01:28 [DEBUG] Tx packet dump:
>>   02 00 00 63 00 01 00 01  a3 64 64 61 74 61 58 4f  
>> |...c.ddataXO|
>> 0010  3c b8 f3 96 24 00 00 00  20 00 00 00 3c b3 00 00  |<...$... 
>> ...<...|
>> 0020  02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
>> ||
>> 0030  00 00 01 20 f9 80 00 00  51 81 00 00 53 81 00 00  |... 
>> Q...S...|
>> 0040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
>> ||
>> 0050  00 00 00 00 00 00 00 00  00 00 00 00 8f 9f 00 63  
>> |...c|
>> 0060  6c 65 6e 19 b3 80 63 6f  66 66 00 |len...coff.|
>> 
>> 2017/03/24 17:01:28 [DEBUG] Write BLE Packet:buf::c

�ddataXO<���$ <�
 
>> ��Q�S���clen��coff len::107
>> 2017/03/24 17:01:31 [DEBUG] Disconnected%!(EXTRA )
>> 
>> Seem like it get Disconnected?
>> 
>> From: Lm Chew <lm.c...@free2move.se>
>> Sent: Friday, 24 March, 2017 3:23:39 PM
>> To: dev@mynewt.incubator.apache.org
>> Cc: Yz Then; Meili Yeo
>> Subject: Newtmgr over BLE not Working
>> 
>> Hi Everyone,
>> 
>> 
>> I need some help figuring out why the Newtmgr Image Upload over BLE is not 
>> working.
>> 
>> 
>> The Image setup I am going for is the "Unified" setup.
>> 
>> 
&g

Re: Newtmgr over BLE not Working

[Lm Chew]

Hi Vipul,


Here is the syscfg file:


# Package: apps/bleprph

syscfg.vals:
# Use INFO log level to reduce code size.  DEBUG is too large for nRF51.
LOG_LEVEL: 1

# Disable central and observer roles.
BLE_ROLE_BROADCASTER: 1
BLE_ROLE_CENTRAL: 0
BLE_ROLE_OBSERVER: 0
BLE_ROLE_PERIPHERAL: 1

# Disable unused eddystone feature.
BLE_EDDYSTONE: 0

# Log reboot messages to a flash circular buffer.
REBOOT_LOG_FCB: 1
LOG_FCB: 1
CONFIG_FCB: 1

# Enable newtmgr commands.
STATS_NEWTMGR: 1
LOG_NEWTMGR: 1

# Enable Config.
CONFIG_NEWTMGR: 1

# OS main/default task
OS_MAIN_STACK_SIZE: 428


Best Regards,

Chew


From: Vipul Rahane <vi...@runtime.io>
Sent: Saturday, 25 March, 2017 1:38:09 AM
To: dev@mynewt.incubator.apache.org
Cc: Yz Then; Meili Yeo
Subject: Re: Newtmgr over BLE not Working

Hello,

Can you please send me your syscfg settings for the bleprph target ? Thank you.

Regards,
Vipul Rahane

> On Mar 24, 2017, at 2:05 AM, Lm Chew <lm.c...@free2move.se> wrote:
>
> Here is the output with -ldebug:
>
> 2017/03/24 17:01:28 [DEBUG] BLE Connection devaddr:[]
> 2017/03/24 17:01:28 dev: hci0 up
> 2017/03/24 17:01:28 dev: hci1 up
> 2017/03/24 17:01:28 dev: hci1 reset
> 2017/03/24 17:01:28 dev: hci1 down
> 2017/03/24 17:01:28 dev: hci1 opened
> 2017/03/24 17:01:28 [DEBUG] State:PoweredOn
> 2017/03/24 17:01:28 [DEBUG] scanning...
> 2017/03/24 17:01:28 [DEBUG] Peripheral Discovered: nimble-bleprph, 
> Address:[10 10 10 10 10 10] Address Type:0
> 2017/03/24 17:01:28 [DEBUG] Peripheral Connected
> 2017/03/24 17:01:28 [DEBUG] Newtmgr Service Found
> 2017/03/24 17:01:28 [DEBUG] Newtmgr Characteristic Found
> 2017/03/24 17:01:28 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:99 
> Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 
> 32 0 0 0 60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 
> 129 0 0 83 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
> 143 159 0 99 108 101 110 25 179 128 99 111 102 102 0]}
> 2017/03/24 17:01:28 [DEBUG] Serializing request &{Op:2 Flags:0 Len:99 Group:1 
> Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 
> 60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 129 0 0 83 
> 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 143 159 0 99 
> 108 101 110 25 179 128 99 111 102 102 0]} into buffer [2 0 0 99 0 1 0 1 163 
> 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 60 179 0 0 2 0 0 0 0 
> 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 129 0 0 83 129 0 0 0 0 0 0 0 0 
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 143 159 0 99 108 101 110 25 179 
> 128 99 111 102 102 0]
> 2017/03/24 17:01:28 [DEBUG] Tx packet dump:
>   02 00 00 63 00 01 00 01  a3 64 64 61 74 61 58 4f  |...c.ddataXO|
> 0010  3c b8 f3 96 24 00 00 00  20 00 00 00 3c b3 00 00  |<...$... ...<...|
> 0020  02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> 0030  00 00 01 20 f9 80 00 00  51 81 00 00 53 81 00 00  |... Q...S...|
> 0040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> 0050  00 00 00 00 00 00 00 00  00 00 00 00 8f 9f 00 63  |...c|
> 0060  6c 65 6e 19 b3 80 63 6f  66 66 00 |len...coff.|
>
> 2017/03/24 17:01:28 [DEBUG] Write BLE Packet:buf::c

�ddataXO<���$ <�
 
> ��Q�S���clen��coff len::107
> 2017/03/24 17:01:31 [DEBUG] Disconnected%!(EXTRA )
>
> Seem like it get Disconnected?
> ________
> From: Lm Chew <lm.c...@free2move.se>
> Sent: Friday, 24 March, 2017 3:23:39 PM
> To: dev@mynewt.incubator.apache.org
> Cc: Yz Then; Meili Yeo
> Subject: Newtmgr over BLE not Working
>
> Hi Everyone,
>
>
> I need some help figuring out why the Newtmgr Image Upload over BLE is not 
> working.
>
>
> The Image setup I am going for is the "Unified" setup.
>
>
> So now I will describe the procedure that I have done up till the issue arise.
>
>
> Firstly I pulled all the latest source for the Newt Tool & the Mynewt OS from 
> the Developer branch and build them.
>
>
> Then I build & created image for 3 Targets with the following setting:
>
>
> targets/nrf52_boot
>app=@apache-mynewt-core/apps/boot
>bsp=@apache-mynewt-core/hw/bsp/bmd300eval
>build_profile=optimized
>
> targets/unified-bmd300eval
>app=@apache-mynewt-core/apps/bleprph
>bsp=@apache-mynewt-core/hw/bsp/bmd300eval
>build_profile=optimized
>
> targets/unified2-bmd300eval
>app=@apache-mynewt-core/apps/slinky
>bsp=@apache-mynewt-core/hw/bsp/bmd300eval
>build_profile=optimiz

Re: Newtmgr over BLE not Working

[Vipul Rahane]

Hello,

Can you please send me your syscfg settings for the bleprph target ? Thank you.

Regards,
Vipul Rahane

> On Mar 24, 2017, at 2:05 AM, Lm Chew <lm.c...@free2move.se> wrote:
> 
> Here is the output with -ldebug:
> 
> 2017/03/24 17:01:28 [DEBUG] BLE Connection devaddr:[]
> 2017/03/24 17:01:28 dev: hci0 up
> 2017/03/24 17:01:28 dev: hci1 up
> 2017/03/24 17:01:28 dev: hci1 reset
> 2017/03/24 17:01:28 dev: hci1 down
> 2017/03/24 17:01:28 dev: hci1 opened
> 2017/03/24 17:01:28 [DEBUG] State:PoweredOn
> 2017/03/24 17:01:28 [DEBUG] scanning...
> 2017/03/24 17:01:28 [DEBUG] Peripheral Discovered: nimble-bleprph, 
> Address:[10 10 10 10 10 10] Address Type:0
> 2017/03/24 17:01:28 [DEBUG] Peripheral Connected
> 2017/03/24 17:01:28 [DEBUG] Newtmgr Service Found
> 2017/03/24 17:01:28 [DEBUG] Newtmgr Characteristic Found
> 2017/03/24 17:01:28 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:99 
> Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 
> 32 0 0 0 60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 
> 129 0 0 83 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
> 143 159 0 99 108 101 110 25 179 128 99 111 102 102 0]}
> 2017/03/24 17:01:28 [DEBUG] Serializing request &{Op:2 Flags:0 Len:99 Group:1 
> Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 
> 60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 129 0 0 83 
> 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 143 159 0 99 
> 108 101 110 25 179 128 99 111 102 102 0]} into buffer [2 0 0 99 0 1 0 1 163 
> 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 60 179 0 0 2 0 0 0 0 
> 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 129 0 0 83 129 0 0 0 0 0 0 0 0 
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 143 159 0 99 108 101 110 25 179 
> 128 99 111 102 102 0]
> 2017/03/24 17:01:28 [DEBUG] Tx packet dump:
>   02 00 00 63 00 01 00 01  a3 64 64 61 74 61 58 4f  |...c.ddataXO|
> 0010  3c b8 f3 96 24 00 00 00  20 00 00 00 3c b3 00 00  |<...$... ...<...|
> 0020  02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> 0030  00 00 01 20 f9 80 00 00  51 81 00 00 53 81 00 00  |... Q...S...|
> 0040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> 0050  00 00 00 00 00 00 00 00  00 00 00 00 8f 9f 00 63  |...c|
> 0060  6c 65 6e 19 b3 80 63 6f  66 66 00 |len...coff.|
> 
> 2017/03/24 17:01:28 [DEBUG] Write BLE Packet:buf::c

�ddataXO<���$ <�
 
> ��Q�S���clen��coff len::107
> 2017/03/24 17:01:31 [DEBUG] Disconnected%!(EXTRA )
> 
> Seem like it get Disconnected?
> ____
> From: Lm Chew <lm.c...@free2move.se>
> Sent: Friday, 24 March, 2017 3:23:39 PM
> To: dev@mynewt.incubator.apache.org
> Cc: Yz Then; Meili Yeo
> Subject: Newtmgr over BLE not Working
> 
> Hi Everyone,
> 
> 
> I need some help figuring out why the Newtmgr Image Upload over BLE is not 
> working.
> 
> 
> The Image setup I am going for is the "Unified" setup.
> 
> 
> So now I will describe the procedure that I have done up till the issue arise.
> 
> 
> Firstly I pulled all the latest source for the Newt Tool & the Mynewt OS from 
> the Developer branch and build them.
> 
> 
> Then I build & created image for 3 Targets with the following setting:
> 
> 
> targets/nrf52_boot
>app=@apache-mynewt-core/apps/boot
>bsp=@apache-mynewt-core/hw/bsp/bmd300eval
>build_profile=optimized
> 
> targets/unified-bmd300eval
>app=@apache-mynewt-core/apps/bleprph
>bsp=@apache-mynewt-core/hw/bsp/bmd300eval
>build_profile=optimized
> 
> targets/unified2-bmd300eval
>app=@apache-mynewt-core/apps/slinky
>bsp=@apache-mynewt-core/hw/bsp/bmd300eval
>build_profile=optimized
> 
> 
> 
> After that I load the bootloader:
> 
> newt load nrf52_boot
> 
> 
> and then the bleprph app:
> 
> newt load unified-bmd300eval
> 
> 
> So by now, I am be able to detect the ble advertisement by using the hcitool 
> (I am using a USB BLE 4.0 dongle, while disabled the build-in Bluetooth on 
> hci0):
> 
> sudo hcitool -i hci1 lescan
> 
> 
> Output is as follow:
> 
> LE Scan ...
> 0A:0A:0A:0A:0A:0A nimble-g4-node
> 0A:0A:0A:0A:0A:0A (unknown)
> 0A:0A:0A:0A:0A:0A nimble-g4-node
> 0A:0A:0A:0A:0A:0A (unknown)
> ^C
> 
> Next thing to do is set the connection profile for the newtmgr:
> 
> newtmgr conn add ble type=ble connstring=nimble-bleprph
> 
> 
> Then i try to list the image available in the device:
> 
> sudo "$(which newtmgr)" -c ble image list
&g

Re: Newtmgr over BLE not Working

[Lm Chew]

Here is the output with -ldebug:

2017/03/24 17:01:28 [DEBUG] BLE Connection devaddr:[]
2017/03/24 17:01:28 dev: hci0 up
2017/03/24 17:01:28 dev: hci1 up
2017/03/24 17:01:28 dev: hci1 reset
2017/03/24 17:01:28 dev: hci1 down
2017/03/24 17:01:28 dev: hci1 opened
2017/03/24 17:01:28 [DEBUG] State:PoweredOn
2017/03/24 17:01:28 [DEBUG] scanning...
2017/03/24 17:01:28 [DEBUG] Peripheral Discovered: nimble-bleprph, Address:[10 
10 10 10 10 10] Address Type:0
2017/03/24 17:01:28 [DEBUG] Peripheral Connected
2017/03/24 17:01:28 [DEBUG] Newtmgr Service Found
2017/03/24 17:01:28 [DEBUG] Newtmgr Characteristic Found
2017/03/24 17:01:28 [DEBUG] Writing newtmgr request &{Op:2 Flags:0 Len:99 
Group:1 Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 
0 0 0 60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 129 0 
0 83 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 143 159 0 
99 108 101 110 25 179 128 99 111 102 102 0]}
2017/03/24 17:01:28 [DEBUG] Serializing request &{Op:2 Flags:0 Len:99 Group:1 
Seq:0 Id:1 Data:[163 100 100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 
60 179 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 129 0 0 83 
129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 143 159 0 99 
108 101 110 25 179 128 99 111 102 102 0]} into buffer [2 0 0 99 0 1 0 1 163 100 
100 97 116 97 88 79 60 184 243 150 36 0 0 0 32 0 0 0 60 179 0 0 2 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 1 32 249 128 0 0 81 129 0 0 83 129 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 143 159 0 99 108 101 110 25 179 128 99 111 
102 102 0]
2017/03/24 17:01:28 [DEBUG] Tx packet dump:
  02 00 00 63 00 01 00 01  a3 64 64 61 74 61 58 4f  |...c.ddataXO|
0010  3c b8 f3 96 24 00 00 00  20 00 00 00 3c b3 00 00  |<...$... ...<...|
0020  02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0030  00 00 01 20 f9 80 00 00  51 81 00 00 53 81 00 00  |... Q...S...|
0040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0050  00 00 00 00 00 00 00 00  00 00 00 00 8f 9f 00 63  |...c|
0060  6c 65 6e 19 b3 80 63 6f  66 66 00 |len...coff.|

2017/03/24 17:01:28 [DEBUG] Write BLE Packet:buf::c

�ddataXO<���$ <�
 
��Q�S���clen��coff len::107
2017/03/24 17:01:31 [DEBUG] Disconnected%!(EXTRA )

Seem like it get Disconnected?

From: Lm Chew <lm.c...@free2move.se>
Sent: Friday, 24 March, 2017 3:23:39 PM
To: dev@mynewt.incubator.apache.org
Cc: Yz Then; Meili Yeo
Subject: Newtmgr over BLE not Working

Hi Everyone,


I need some help figuring out why the Newtmgr Image Upload over BLE is not 
working.


The Image setup I am going for is the "Unified" setup.


So now I will describe the procedure that I have done up till the issue arise.


Firstly I pulled all the latest source for the Newt Tool & the Mynewt OS from 
the Developer branch and build them.


Then I build & created image for 3 Targets with the following setting:


targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
bsp=@apache-mynewt-core/hw/bsp/bmd300eval
build_profile=optimized

targets/unified-bmd300eval
app=@apache-mynewt-core/apps/bleprph
bsp=@apache-mynewt-core/hw/bsp/bmd300eval
build_profile=optimized

targets/unified2-bmd300eval
app=@apache-mynewt-core/apps/slinky
bsp=@apache-mynewt-core/hw/bsp/bmd300eval
build_profile=optimized



After that I load the bootloader:

newt load nrf52_boot


and then the bleprph app:

newt load unified-bmd300eval


So by now, I am be able to detect the ble advertisement by using the hcitool (I 
am using a USB BLE 4.0 dongle, while disabled the build-in Bluetooth on hci0):

sudo hcitool -i hci1 lescan


Output is as follow:

LE Scan ...
0A:0A:0A:0A:0A:0A nimble-g4-node
0A:0A:0A:0A:0A:0A (unknown)
0A:0A:0A:0A:0A:0A nimble-g4-node
0A:0A:0A:0A:0A:0A (unknown)
^C

Next thing to do is set the connection profile for the newtmgr:

newtmgr conn add ble type=ble connstring=nimble-bleprph


Then i try to list the image available in the device:

sudo "$(which newtmgr)" -c ble image list


Here is the Output:

2017/03/24 15:11:35 dev: hci0 up
2017/03/24 15:11:35 dev: hci1 up
2017/03/24 15:11:35 dev: hci1 reset
2017/03/24 15:11:35 dev: hci1 down
2017/03/24 15:11:35 dev: hci1 opened
Images:
 slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: b9b1b2a2f1923e181d83c47f6092c3f1779451cf6bed48c863625fb5642c8cbd
Split status: N/A

Now I want to try to upload slinky image to slot=1:
sudo "$(which newtmgr)" -c ble image upload '/slinky/slinky.img'

And the output just stop here no matter how long I waited.
2017/03/24 15:16:04 dev: hci0 up
2017/03/24 15:16:04 dev: hci1 up
2017/03/24 15:16:04 dev: hci1 reset
2017/03/24 15:16:04 dev: hci1 down
2017/03/24 15:16:04 dev: hci1 opened

Any Idea why it just stopped here?


Best Regards,

Chew

Newtmgr over BLE not Working

[Lm Chew]

Hi Everyone,


I need some help figuring out why the Newtmgr Image Upload over BLE is not 
working.


The Image setup I am going for is the "Unified" setup.


So now I will describe the procedure that I have done up till the issue arise.


Firstly I pulled all the latest source for the Newt Tool & the Mynewt OS from 
the Developer branch and build them.


Then I build & created image for 3 Targets with the following setting:


targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
bsp=@apache-mynewt-core/hw/bsp/bmd300eval
build_profile=optimized

targets/unified-bmd300eval
app=@apache-mynewt-core/apps/bleprph
bsp=@apache-mynewt-core/hw/bsp/bmd300eval
build_profile=optimized

targets/unified2-bmd300eval
app=@apache-mynewt-core/apps/slinky
bsp=@apache-mynewt-core/hw/bsp/bmd300eval
build_profile=optimized



After that I load the bootloader:

newt load nrf52_boot


and then the bleprph app:

newt load unified-bmd300eval


So by now, I am be able to detect the ble advertisement by using the hcitool (I 
am using a USB BLE 4.0 dongle, while disabled the build-in Bluetooth on hci0):

sudo hcitool -i hci1 lescan


Output is as follow:

LE Scan ...
0A:0A:0A:0A:0A:0A nimble-g4-node
0A:0A:0A:0A:0A:0A (unknown)
0A:0A:0A:0A:0A:0A nimble-g4-node
0A:0A:0A:0A:0A:0A (unknown)
^C

Next thing to do is set the connection profile for the newtmgr:

newtmgr conn add ble type=ble connstring=nimble-bleprph


Then i try to list the image available in the device:

sudo "$(which newtmgr)" -c ble image list


Here is the Output:

2017/03/24 15:11:35 dev: hci0 up
2017/03/24 15:11:35 dev: hci1 up
2017/03/24 15:11:35 dev: hci1 reset
2017/03/24 15:11:35 dev: hci1 down
2017/03/24 15:11:35 dev: hci1 opened
Images:
 slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: b9b1b2a2f1923e181d83c47f6092c3f1779451cf6bed48c863625fb5642c8cbd
Split status: N/A

Now I want to try to upload slinky image to slot=1:
sudo "$(which newtmgr)" -c ble image upload '/slinky/slinky.img'

And the output just stop here no matter how long I waited.
2017/03/24 15:16:04 dev: hci0 up
2017/03/24 15:16:04 dev: hci1 up
2017/03/24 15:16:04 dev: hci1 reset
2017/03/24 15:16:04 dev: hci1 down
2017/03/24 15:16:04 dev: hci1 opened

Any Idea why it just stopped here?


Best Regards,

Chew

Re: Newtmgr over BLE

[Sterling Hughes]

Hi Jacob,

Chris has been working on getting the Mynewt stack working in a cross 
platform way.  You can see some of his progress here:


* 
https://github.com/ccollins476ad/incubator-mynewt-core/tree/nativehost/apps/blehostd/src


* 
https://github.com/ccollins476ad/incubator-mynewt-newt/tree/nmxact/newtmgr


The idea is to use Mynewt’s sim architecture to run in a *nix process, 
and then speak HCI to whatever controller is running on the device.  
Newtmgr forks mynewt, and then communicates over a unix domain socket 
using JSON, and then drives the bluetooth stack.  I actually pinged 
Sandeep about this, because it should now work portably across Linux and 
Mac with the same Bluetooth host, no wacky kernel stuff necessary.


The caveat on Mac is that you need a controller (NRF* dongle for 
example), on Linux you can either run against a Mynewt controller or use 
HCI itself.


I think Chris is a week or two off on getting this ready - and I think 
it’s still TBD as whether this belongs in core, or as a separate 
project.  My vote would be to start with core, and then as it grows, 
potentially move it out of core.  But it is very nice to have the Mynewt 
stack running as a linux process — and fairly easy to map into other 
languages, because the interface is all JSON.


Best,

Sterling

On 7 Mar 2017, at 14:47, Jacob Rosenthal wrote:

Whats the internal thinking on this? Is it being discussed elsewhere? 
Is
the aforementioned rewrite going on, or delayed so it make sense for 
me to

try to get work on the xpc calls?

On Wed, Jan 25, 2017 at 1:07 PM, Jacob Rosenthal 


wrote:

The gatt dependency actually uses the xpc's reverse engineered by 
Sandeep

for noble github.com/sandeepmistry/noble (which I have some code on)
which has three separate xpc bindings for mavericks

yosemite

 and legacy


Now that the native apis are fairly stable and cover most of what the 
xpcs
have access to, I think even sandeep doesnt love having to redo the 
xpcs on
new os releases..But it takes very little to piggyback on the work 
hes
already done and modernize gatt's xpc handling if thats the only 
issue...






On Wed, Jan 25, 2017 at 12:10 PM, Jacob Rosenthal 

wrote:


ook at this app ...

Re: Newtmgr over BLE

[Jacob Rosenthal]

Whats the internal thinking on this? Is it being discussed elsewhere? Is
the aforementioned rewrite going on, or delayed so it make sense for me to
try to get work on the xpc calls?

On Wed, Jan 25, 2017 at 1:07 PM, Jacob Rosenthal 
wrote:

> The gatt dependency actually uses the xpc's reverse engineered by Sandeep
> for noble github.com/sandeepmistry/noble (which I have some code on)
> which has three separate xpc bindings for mavericks
> 
> yosemite
> 
>  and legacy
> 
>
> Now that the native apis are fairly stable and cover most of what the xpcs
> have access to, I think even sandeep doesnt love having to redo the xpcs on
> new os releases..But it takes very little to piggyback on the work hes
> already done and modernize gatt's xpc handling if thats the only issue...
>
>
>
>
>
> On Wed, Jan 25, 2017 at 12:10 PM, Jacob Rosenthal  > wrote:
>
>> Or at least the newtmgr code as a dependency ;)
>>
>> On Wed, Jan 25, 2017 at 6:52 AM, David G. Simmons 
>> wrote:
>>
>>> ook at this app ...
>>>
>>
>>
>>
>

Re: Newtmgr over BLE

[Jacob Rosenthal]

Or at least the newtmgr code as a dependency ;)

On Wed, Jan 25, 2017 at 6:52 AM, David G. Simmons  wrote:

> ook at this app ...
>

Re: Newtmgr over BLE

[David G. Simmons]

I'd love to get a look at this app ...

dg

> On Jan 24, 2017, at 8:18 PM, 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.

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




signature.asc
Description: Message signed with OpenPGP

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

Re: Newtmgr over BLE

[Kevin Townsend]

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.


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.


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



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

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: Unsolicited Notify with newtmgr over BLE

[Vipul Rahane]

Hello Kevin,

Thank you for going through this.

I agree with what Chris mentioned. When I wrote the newtmgr protocol(NMP) in 
swift for Nordic’s Toolbox app, I had enabled this bit for the newtmgr 
characteristic. The port is still WIP and hence the incompleteness. I have 
spoken to Chris about this and will set the notify bit on the newtmgr 
characteristic. 

As for the UUIDs, I agree that making the first 16 bits sequential does sound 
intuitive but then the IDs would not be truely unique and there would be a 
higher probability of a collision. I have generated the currently assigned IDs 
using Guid generator <http://www.guidgenerator.com/> which generates the IDs 
based on an algorithm that is mentioned in RFC4122 
<http://www.ietf.org/rfc/rfc4122.txt> and it uses the timestamp and the MAC 
address of the computer they were generated on. 

Regards,
Vipul Rahane 

> On Oct 5, 2016, at 7:36 PM, Kevin Townsend <ke...@adafruit.com> wrote:
> 
> 
>> I think you're right about that - a CCCD should not be set to one unless
>> the peer writes to it.  What I'm not so sure about is whether it is
>> prohibited to send a notification to an unsubscribed peer.  I didn't see
>> any language in the spec indicating that this is illegal.  The ability
>> to send unsolicited notifications is useful, and I don't see a reason
>> why it shouldn't be allowed.
> I agree it's somewhat ambiguous or open to interpretation at present,
> but in the case of something as critical as newtmgr over ble (OTA DFU
> etc.), it probably makes sense to take the safe approach and add the
> CCCD to a characteristic and have the peer explicitly set the notify
> bit before the response data is sent???
> 
> Having the possibility to send unsolicited notifies has some merit, and
> personally I don't have any objections to it being included as an option
> in nimble, but I wouldn't rely on those assumptions for newtmgr over
> BLE.
> 
> Just my opinion though and curious to hear what other people think.

Re: Unsolicited Notify with newtmgr over BLE

[Kevin Townsend]

I think you're right about that - a CCCD should not be set to one unless
the peer writes to it.  What I'm not so sure about is whether it is
prohibited to send a notification to an unsubscribed peer.  I didn't see
any language in the spec indicating that this is illegal.  The ability
to send unsolicited notifications is useful, and I don't see a reason
why it shouldn't be allowed.

I agree it's somewhat ambiguous or open to interpretation at present,
but in the case of something as critical as newtmgr over ble (OTA DFU
etc.), it probably makes sense to take the safe approach and add the
CCCD to a characteristic and have the peer explicitly set the notify
bit before the response data is sent???

Having the possibility to send unsolicited notifies has some merit, and
personally I don't have any objections to it being included as an option
in nimble, but I wouldn't rely on those assumptions for newtmgr over
BLE.

Just my opinion though and curious to hear what other people think.

Re: Unsolicited Notify with newtmgr over BLE

[Christopher Collins]

On Wed, Oct 05, 2016 at 05:07:00PM -0700, Mike Ryan wrote:
> On Thu, Oct 06, 2016 at 02:00:25AM +0200, Kevin Townsend wrote:
> > I remember some discussions previously about unsolicited notifies
> > and whether this was or wasn't supported in the BLE spec
> 
> My reading of the spec suggests that it is not legal. Referring to
> Client Characteristic Configuration on PDF page 2228 of Core v4.2 (Vol.
> 3 Part G Sec 3.3.3.3):
> 
> > The Client Characteristic Configuration descriptor value shall be set
> > to the default value at each connection with non-bonded devices.
> 
> Later in the same section:
> 
> > The default value for the Client Characteristic Configuration
> > descriptor value shall be 0x.
> 
> This suggests that the value for notifications will be 0. A value of 1
> signifies "the Characteristic Value shall be notified". It's safe to
> assume that a value of 0 therefore means that the value shall not be
> notified.

I think you're right about that - a CCCD should not be set to one unless
the peer writes to it.  What I'm not so sure about is whether it is
prohibited to send a notification to an unsubscribed peer.  I didn't see
any language in the spec indicating that this is illegal.  The ability
to send unsolicited notifications is useful, and I don't see a reason
why it shouldn't be allowed.

That said, I believe iOS will drop incoming notifications for a
characteristic that doesn't have a CCCD.  I don't believe android has
this limitation.  If iOS requires the characteristic to be subscribable,
then I think we need to comply.

Thanks,
Chris

Re: Unsolicited Notify with newtmgr over BLE

[Kevin Townsend]

Also, would it make sense to have more consistent UUIDs, such as:

- 8D530001-1DB7-4CD3-868B-8A527460AA84
- 8D530002-1DB7-4CD3-868B-8A527460AA84
- 8D530003-1DB7-4CD3-868B-8A527460AA84 (potentially?)

We could perhaps even settle on a single base 128-bit UUID throughout 
Mynewt, adjusting the 16 bit range at the start?


This is a minor detail and might be a nuisance to change, and more of a 
cosmetic issue, but I figured it was worth tossing out there.



On 06/10/16 02:00, Kevin Townsend wrote:
I'm working with newtmgr over BLE based on the newtmgr lib in the 
master branch of apache-mynewt-core, which currently has the following 
structure:


Service UUID: 8D53DC1D-1DB7-4CD3-868B-8A527460AA84
Characteristic UUID: DA2E7828-FBCE-4E01-AE9E-261174997C48

The source code has this explanatory comment on the service:

> The "newtmgr" service consists of one write no-rsp characteristic for
> newtmgr requests: a single-byte characteristic that can only accepts
> write-without-response commands. The contents of each write command
> contains an NMP request. NMP responses are sent back in the form of
> unsolicited notifications from the same characteristic.

I remember some discussions previously about unsolicited notifies and 
whether this was or wasn't supported in the BLE spec (I believe 
between Carles Cufi from Nordic and I believe Will and/or Chris at 
Runtime?), but given the uncertainty around this I wonder if it 
wouldn't be better to adjust the newtmgr service definition to have 
two characteristics similar to the way 'nus' (Nordic UART Service) works:


- One TXD or 'Request' characteristic to write commands to, which can 
reuse the existing characteristic as-is
- A new RXD or 'Response' characteristic with notify enabled, which 
would also allow you to send multiple data chunks since each packet 
will cause a new notify event on the Central, making it relatively 
easy to manage rebuilding packets.


I've been doing some initial tests with the netmgr service as is and 
many apps don't seem to like the unsolicited notifications even if 
they can be made to work.  Two separate characteristics would probably 
ensure everything is handled unambiguously on any platform, but I'm 
curious to hear other people's thoughts?


Kevin

Re: Unsolicited Notify with newtmgr over BLE

[Mike Ryan]

On Thu, Oct 06, 2016 at 02:00:25AM +0200, Kevin Townsend wrote:
> I remember some discussions previously about unsolicited notifies
> and whether this was or wasn't supported in the BLE spec

My reading of the spec suggests that it is not legal. Referring to
Client Characteristic Configuration on PDF page 2228 of Core v4.2 (Vol.
3 Part G Sec 3.3.3.3):

> The Client Characteristic Configuration descriptor value shall be set
> to the default value at each connection with non-bonded devices.

Later in the same section:

> The default value for the Client Characteristic Configuration
> descriptor value shall be 0x.

This suggests that the value for notifications will be 0. A value of 1
signifies "the Characteristic Value shall be notified". It's safe to
assume that a value of 0 therefore means that the value shall not be
notified.

Unsolicited Notify with newtmgr over BLE

[Kevin Townsend]

I'm working with newtmgr over BLE based on the newtmgr lib in the master 
branch of apache-mynewt-core, which currently has the following structure:


Service UUID: 8D53DC1D-1DB7-4CD3-868B-8A527460AA84
Characteristic UUID: DA2E7828-FBCE-4E01-AE9E-261174997C48

The source code has this explanatory comment on the service:

> The "newtmgr" service consists of one write no-rsp characteristic for
> newtmgr requests: a single-byte characteristic that can only accepts
> write-without-response commands. The contents of each write command
> contains an NMP request. NMP responses are sent back in the form of
> unsolicited notifications from the same characteristic.

I remember some discussions previously about unsolicited notifies and 
whether this was or wasn't supported in the BLE spec (I believe between 
Carles Cufi from Nordic and I believe Will and/or Chris at Runtime?), 
but given the uncertainty around this I wonder if it wouldn't be better 
to adjust the newtmgr service definition to have two characteristics 
similar to the way 'nus' (Nordic UART Service) works:


- One TXD or 'Request' characteristic to write commands to, which can 
reuse the existing characteristic as-is
- A new RXD or 'Response' characteristic with notify enabled, which 
would also allow you to send multiple data chunks since each packet will 
cause a new notify event on the Central, making it relatively easy to 
manage rebuilding packets.


I've been doing some initial tests with the netmgr service as is and 
many apps don't seem to like the unsolicited notifications even if they 
can be made to work.  Two separate characteristics would probably ensure 
everything is handled unambiguously on any platform, but I'm curious to 
hear other people's thoughts?


Kevin

Re: MYNEWT-266 Newtmgr over BLE

[Vipul Rahane]

Also, I should have mentioned that the current version of the gateway only 
works for linux.

I have committed code in bleprph example which instruments the library and can 
be used as a starting point for OTA image upgrades and other command request 
responses.

-Vipul

> On Jul 12, 2016, at 6:15 PM, Vipul Rahane <vi...@runtime.io> wrote:
> 
> Hello,
> 
> I have implemented and tested newtmgr over BLE as a separate library.
> 
> The current tests I have performed include image upload(OTA Firmware 
> upgrades), soft reset command, remote config and logs.
> 
> The pull request for mynewt core is at 
> https://github.com/apache/incubator-mynewt-core/pull/73 
> <https://goo.gl/0axujg>.
> 
> The pull request for newtmgr transport implementation that supports the on 
> the gateway side is at 
> https://github.com/apache/incubator-mynewt-newt/pull/15 
> <https://github.com/apache/incubator-mynewt-newt/pull/15>
> 
> The BLE library used for the gateway side is Runtime fork of Paypal/gatt 
> library which is at https://github.com/runtimeinc/gatt 
> <https://github.com/runtimeinc/gatt>
> There is a “type:ble" transport that is used to identify messages going over 
> BLE as opposed to “type:serial”.
> 
> An example of how to use newtmgr over BLE is as follows:
> 
> 1. Add a BLE connection profile:
> newtmgr conn add ble type=ble connstring='vipuls-slave’
> 
> where 'vipuls-slave’ is the name of the bluetooth device we are trying to 
> connect to.
>  
> 2. Issue command; Here I am uploading an image:
> newtmgr -c ble image upload ~/Downloads/bletiny.img
> 
> The output you should see is as follows:
> 
> 2016/07/12 12:12:25 dev: hci0 up
> 2016/07/12 12:12:25 dev: hci0 down
> 2016/07/12 12:12:25 dev: hci0 opened
> date
> Done
> admin@bleh:~/go/src/mynewt.apache.org/newt/newtmgr 
> <http://mynewt.apache.org/newt/newtmgr>$ date
> Tue Jul 12 12:13:07 PDT 2016
> 
> The above process connects to a bluetooth device, issues a command with 
> write-no-response commands, waits for a notification and then disconnects.  
> 
> Limitation:
> Chunking for stats isn’t currently implemented and BLE stats are currently 
> very big and do not fit in a single response. I would shortly open a ticket 
> for this.
> 
> This would improve further in due course of time based on usage and 
> requirements.
> 
> Thank you for all the help, suggestions and comments from everyone. Please 
> feel free to comment more on the pull requests or here if needed.
> 
> Regards,
> Vipul Rahane