You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Alan Graves <ag...@deltacontrols.com> on 2017/02/01 23:05:23 UTC
BLE HCI support on NRF52DK
Hi,
I've spent some time trying to get nRF52832 DK running the 'blehci' code communicating with Xubuntu 16.10 (under VMware) with not much luck.
I'm currently running the following development setup:
$ git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
$ go version
go version go1.6.3 linux/amd64
$ newt version
Apache Newt (incubating) version: 1.0.0-dev
$ newt target show
targets/blink_nordic
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/nrf52dk
build_profile=debug
targets/my_blinky_sim
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug
targets/nina_blinky
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/nina-b1
build_profile=optimized
targets/nina_hci
app=@apache-mynewt-core/apps/blehci
bsp=@apache-mynewt-core/hw/bsp/nina-b1
build_profile=optimized
targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
bsp=@apache-mynewt-core/hw/bsp/nrf52dk
build_profile=optimized
The 'hw/bsp/nina-b1' is a custom nRF52832 board port based on the ublox NINA-B112 module and has following pin usage:
Function Pin NINA-B1 Schematic Comment
========= ==== ======= ======== ==================
UART_RXD P0.05 GPIO_23 BT-RXD
UART_TXD P0.06 GPIO_22 BT-TXD
UART_RTS P0.31 GPIO_20 n/c Not connected!
UART_CTS P0.07 GPIO_21 GND Not recommended!
RED_STS P0.08 GPIO_1 TP2 bsp.h: LED_BLINK_PIN
GRN_STS P0.11 GPIO_2 TP3 bsp.h: LED_2
NOTE I've also done these test on the nRF52832 DK and get the same results.
When I run the target 'nina_hci' the board transmits a packet on reset power up as follows:
04 0E 03 01 00 00
According to the Core_V4.0 spec I think this decodes into HCI event code = 0x0E which is "Command Complete"
For debugging I have a Logic Pro 8 setup for capturing serial communications and have determined that the baud rate is at 1000000.
With the Linux host I get the following terminal results:
Terminal #1 shows that the BlueZ stack managed to decode the same HCI event (NOP) that I did manually:
$ sudo btmon
[sudo] password for alan:
Bluetooth monitor ver 5.41
= Note: Linux version 4.8.0-34-generic (x86_64) 0.977791
= Note: Bluetooth subsystem version 2.21 0.977792
= New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0] 121.060311
= Open Index: 00:00:00:00:00:00 [hci0] 121.066478
< HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 121.070996
= bluetoothd: Bluetooth daemon 5.41 121.092783
= bluetoothd: Starting SDP server 121.104354
= bluetoothd: Bluetooth management interface 1.13 initialized 121.112600
> HCI Event: Command Complete (0x0e) plen 3 [hci0] 126.168513
NOP (0x00|0x0000) ncmd 1
= Close Index: 00:00:00:00:00:00 [hci0] 131.246188
Terminal #2 shows that the ttyUSB0 device was attached and using the baud rate the LP8 decoded:
$ sudo btattach -B /dev/ttyUSB0 -S 1000000
[sudo] password for alan:
Attaching BR/EDR controller to /dev/ttyUSB0
Switched line discipline from 0 to 15
Device index 0 attached
Terminal #3 shows that the hci0 connection index gets closed too quickly for me to assign a static address:
$ sudo btmgmt --index 0
[sudo] password for alan:
[hci0]# static-addr cc:11:11:11:11:11
Set static address failed with status 0x11 (Invalid Index)
It seems like the timing between these user actions is very important, so has anyone been able to get this HCI example to operate manually like the tutorial indicates?
Any suggestions on how I can get this test to work?
ALan
RE: BLE HCI support on NRF52DK
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi Alan
On Mar 28, 2017 9:53 PM, "Alan Graves" <ag...@deltacontrols.com> wrote:
I also went to the extreme and disabled the flow control in the BlueZ stack
by commenting some lines out and rebuilding things. I believe that might
not have been strictly necessary as someone mentioned afterwards that flow
control could be turned off by a configuration option.
That is that -N option In btattach I mentioned above. It is available in
BlueZ 5.44
Lukasz
ALan
-----Original Message-----
From: Łukasz Rymanowski [mailto:lukasz.rymanowski@codecoup.pl]
Sent: Tuesday, March 28, 2017 6:38 AM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Hi,
On 28 March 2017 at 12:10, Łukasz Rymanowski <lu...@codecoup.pl>
wrote:
> Hi all,
>
> Just had a need to run my nrf52 dev board with blehci and faced same
> issues as Alan
>
> I think we need update documentation here:
> http://mynewt.apache.org/os/ tutorials/blehci_project/ so there is no
> need to grep mailinglist for that :)
>
> We have two issues in the line which says how to attach controller;
>
> sudo btattach -B /dev/ttyUSB0 -S 11520
>
> 1. Speed is incorrect. Default one which is set in
> net/nimble/transport/uart/syscfg.yml
>
> BLE_HCI_UART_BAUD:
> description: 'The baud rate of the HCI uart interface'
> value: 1000000
>
> BTW We could mention that this can be configured by setting
> BLE_HCI_UART_BAUD for example in apps/blehci/syscfg.yml
>
> 2. We should also mention that if there is no CTS/RTS lines present in
> the test environment, flow control should be turned off. It can be
> done with -N option for btattach. Note: -N option came with BlueZ ver
> 5.44
>
and of course BLE_HCI_UART_FLOW_CTRL shall be set to 0 then.
>
>
>
> On 27 February 2017 at 19:52, Alan Graves <ag...@deltacontrols.com>
> wrote:
>
>> Thanks, I did see that over the weekend. Someone must be looking over
>> my shoulder :)
>>
>> -----Original Message-----
>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>> Sent: Sunday, February 26, 2017 11:19 AM
>> To: dev@mynewt.incubator.apache.org
>> Subject: Re: BLE HCI support on NRF52DK
>>
>> Hi,
>>
>> On 25 February 2017 at 01:54, Christopher Collins <ch...@runtime.io>
>> wrote:
>> > Hi Alan,
>> >
>> > On Sat, Feb 25, 2017 at 12:21:15AM +0000, 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
>>
>>
>> Just released BlueZ 5.44 has added support for this :)
>>
>> From release notes:
>> "support for using single-mode (LE-only) controllers that lack a
>> public address (therefore necessitating the use of a static random
>> identity address). E.g. any nRF5x controller running a MyNewt or
>> Zephyr based firmware falls into this category."
>>
>> So there should be no need for setting this up manually with btmgmt
>> anymore.
>>
>> --
>> pozdrawiam
>> Szymon K. Janc
>>
>
>
RE: BLE HCI support on NRF52DK
Posted by Alan Graves <ag...@deltacontrols.com>.
I also went to the extreme and disabled the flow control in the BlueZ stack by commenting some lines out and rebuilding things. I believe that might not have been strictly necessary as someone mentioned afterwards that flow control could be turned off by a configuration option.
ALan
-----Original Message-----
From: Łukasz Rymanowski [mailto:lukasz.rymanowski@codecoup.pl]
Sent: Tuesday, March 28, 2017 6:38 AM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Hi,
On 28 March 2017 at 12:10, Łukasz Rymanowski <lu...@codecoup.pl>
wrote:
> Hi all,
>
> Just had a need to run my nrf52 dev board with blehci and faced same
> issues as Alan
>
> I think we need update documentation here:
> http://mynewt.apache.org/os/ tutorials/blehci_project/ so there is no
> need to grep mailinglist for that :)
>
> We have two issues in the line which says how to attach controller;
>
> sudo btattach -B /dev/ttyUSB0 -S 11520
>
> 1. Speed is incorrect. Default one which is set in
> net/nimble/transport/uart/syscfg.yml
>
> BLE_HCI_UART_BAUD:
> description: 'The baud rate of the HCI uart interface'
> value: 1000000
>
> BTW We could mention that this can be configured by setting
> BLE_HCI_UART_BAUD for example in apps/blehci/syscfg.yml
>
> 2. We should also mention that if there is no CTS/RTS lines present in
> the test environment, flow control should be turned off. It can be
> done with -N option for btattach. Note: -N option came with BlueZ ver
> 5.44
>
and of course BLE_HCI_UART_FLOW_CTRL shall be set to 0 then.
>
>
>
> On 27 February 2017 at 19:52, Alan Graves <ag...@deltacontrols.com>
> wrote:
>
>> Thanks, I did see that over the weekend. Someone must be looking over
>> my shoulder :)
>>
>> -----Original Message-----
>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>> Sent: Sunday, February 26, 2017 11:19 AM
>> To: dev@mynewt.incubator.apache.org
>> Subject: Re: BLE HCI support on NRF52DK
>>
>> Hi,
>>
>> On 25 February 2017 at 01:54, Christopher Collins <ch...@runtime.io>
>> wrote:
>> > Hi Alan,
>> >
>> > On Sat, Feb 25, 2017 at 12:21:15AM +0000, 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
>>
>>
>> Just released BlueZ 5.44 has added support for this :)
>>
>> From release notes:
>> "support for using single-mode (LE-only) controllers that lack a
>> public address (therefore necessitating the use of a static random
>> identity address). E.g. any nRF5x controller running a MyNewt or
>> Zephyr based firmware falls into this category."
>>
>> So there should be no need for setting this up manually with btmgmt
>> anymore.
>>
>> --
>> pozdrawiam
>> Szymon K. Janc
>>
>
>
Re: BLE HCI support on NRF52DK
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi,
On 28 March 2017 at 12:10, Łukasz Rymanowski <lu...@codecoup.pl>
wrote:
> Hi all,
>
> Just had a need to run my nrf52 dev board with blehci and faced same
> issues as Alan
>
> I think we need update documentation here: http://mynewt.apache.org/os/
> tutorials/blehci_project/ so there is no need to grep mailinglist for
> that :)
>
> We have two issues in the line which says how to attach controller;
>
> sudo btattach -B /dev/ttyUSB0 -S 11520
>
> 1. Speed is incorrect. Default one which is set in
> net/nimble/transport/uart/syscfg.yml
>
> BLE_HCI_UART_BAUD:
> description: 'The baud rate of the HCI uart interface'
> value: 1000000
>
> BTW We could mention that this can be configured by setting
> BLE_HCI_UART_BAUD for example in apps/blehci/syscfg.yml
>
> 2. We should also mention that if there is no CTS/RTS lines present in the
> test environment, flow control should be turned off. It can be done with
> -N option for btattach. Note: -N option came with BlueZ ver 5.44
>
and of course BLE_HCI_UART_FLOW_CTRL shall be set to 0 then.
>
>
>
> On 27 February 2017 at 19:52, Alan Graves <ag...@deltacontrols.com>
> wrote:
>
>> Thanks, I did see that over the weekend. Someone must be looking over my
>> shoulder :)
>>
>> -----Original Message-----
>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>> Sent: Sunday, February 26, 2017 11:19 AM
>> To: dev@mynewt.incubator.apache.org
>> Subject: Re: BLE HCI support on NRF52DK
>>
>> Hi,
>>
>> On 25 February 2017 at 01:54, Christopher Collins <ch...@runtime.io>
>> wrote:
>> > Hi Alan,
>> >
>> > On Sat, Feb 25, 2017 at 12:21:15AM +0000, 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
>>
>>
>> Just released BlueZ 5.44 has added support for this :)
>>
>> From release notes:
>> "support for using single-mode (LE-only) controllers that lack a public
>> address (therefore necessitating the use of a static random identity
>> address). E.g. any nRF5x controller running a MyNewt or Zephyr based
>> firmware falls into this category."
>>
>> So there should be no need for setting this up manually with btmgmt
>> anymore.
>>
>> --
>> pozdrawiam
>> Szymon K. Janc
>>
>
>
Re: BLE HCI support on NRF52DK
Posted by Łukasz Rymanowski <lu...@codecoup.pl>.
Hi all,
Just had a need to run my nrf52 dev board with blehci and faced same issues
as Alan
I think we need update documentation here:
http://mynewt.apache.org/os/tutorials/blehci_project/ so there is no need
to grep mailinglist for that :)
We have two issues in the line which says how to attach controller;
sudo btattach -B /dev/ttyUSB0 -S 11520
1. Speed is incorrect. Default one which is set in
net/nimble/transport/uart/syscfg.yml
BLE_HCI_UART_BAUD:
description: 'The baud rate of the HCI uart interface'
value: 1000000
BTW We could mention that this can be configured by setting
BLE_HCI_UART_BAUD for example in apps/blehci/syscfg.yml
2. We should also mention that if there is no CTS/RTS lines present in the
test environment, flow control should be turned off. It can be done with
-N option for btattach. Note: -N option came with BlueZ ver 5.44
On 27 February 2017 at 19:52, Alan Graves <ag...@deltacontrols.com> wrote:
> Thanks, I did see that over the weekend. Someone must be looking over my
> shoulder :)
>
> -----Original Message-----
> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
> Sent: Sunday, February 26, 2017 11:19 AM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: BLE HCI support on NRF52DK
>
> Hi,
>
> On 25 February 2017 at 01:54, Christopher Collins <ch...@runtime.io>
> wrote:
> > Hi Alan,
> >
> > On Sat, Feb 25, 2017 at 12:21:15AM +0000, 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
>
>
> Just released BlueZ 5.44 has added support for this :)
>
> From release notes:
> "support for using single-mode (LE-only) controllers that lack a public
> address (therefore necessitating the use of a static random identity
> address). E.g. any nRF5x controller running a MyNewt or Zephyr based
> firmware falls into this category."
>
> So there should be no need for setting this up manually with btmgmt
> anymore.
>
> --
> pozdrawiam
> Szymon K. Janc
>
RE: BLE HCI support on NRF52DK
Posted by Alan Graves <ag...@deltacontrols.com>.
Thanks, I did see that over the weekend. Someone must be looking over my shoulder :)
-----Original Message-----
From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
Sent: Sunday, February 26, 2017 11:19 AM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Hi,
On 25 February 2017 at 01:54, Christopher Collins <ch...@runtime.io> wrote:
> Hi Alan,
>
> On Sat, Feb 25, 2017 at 12:21:15AM +0000, 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
Just released BlueZ 5.44 has added support for this :)
From release notes:
"support for using single-mode (LE-only) controllers that lack a public address (therefore necessitating the use of a static random identity address). E.g. any nRF5x controller running a MyNewt or Zephyr based firmware falls into this category."
So there should be no need for setting this up manually with btmgmt anymore.
--
pozdrawiam
Szymon K. Janc
Re: BLE HCI support on NRF52DK
Posted by Szymon Janc <sz...@codecoup.pl>.
Hi,
On 25 February 2017 at 01:54, Christopher Collins <ch...@runtime.io> wrote:
> Hi Alan,
>
> On Sat, Feb 25, 2017 at 12:21:15AM +0000, 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
Just released BlueZ 5.44 has added support for this :)
From release notes:
"support for using single-mode (LE-only) controllers that lack a
public address (therefore necessitating the use of a static random
identity address). E.g. any nRF5x controller running a MyNewt or
Zephyr based firmware falls into this category."
So there should be no need for setting this up manually with btmgmt anymore.
--
pozdrawiam
Szymon K. Janc
RE: BLE HCI support on NRF52DK
Posted by Alan Graves <ag...@deltacontrols.com>.
Thanks Chris,
I guess 'power off' is really just a state change, but I never thought to turn the device off before setting an address... I'll have to do some more testing, but at least now the 'static-addr' command is accepted.
ALan
-----Original Message-----
From: Christopher Collins [mailto:chris@runtime.io]
Sent: Friday, February 24, 2017 4:54 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Hi Alan,
On Sat, Feb 25, 2017 at 12:21:15AM +0000, 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: BLE HCI support on NRF52DK
Posted by Christopher Collins <ch...@runtime.io>.
Hi Alan,
On Sat, Feb 25, 2017 at 12:21:15AM +0000, 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: BLE HCI support on NRF52DK
Posted by Alan Graves <ag...@deltacontrols.com>.
I have an update on my progress with the HCI testing. I did as Chris suggested and rebuilt the BlueZ from source to disable the hardware flow control and configured the target HCI mode to disable the UART RTS/CTS handshake lines. So far it appears that everything is operating correctly although I haven't done very extensive testing yet.
ALan
-----Original Message-----
From: Alan Graves [mailto:agraves@deltacontrols.com]
Sent: Friday, February 10, 2017 2:00 PM
To: dev@mynewt.incubator.apache.org
Subject: RE: BLE HCI support on NRF52DK
Yes thanks I also got that from the discussion. In retrospect, I think my difficulty arouse because I did not connect the RTS/CTS lines on my hardware as would be case for testing on the standard nRF52DK board. As well I assume I couldn't type fast enough to issue all the terminal commands necessary. As a result the Host closed the connection. Unfortunately I haven't been able to retest as I am away from work for at least another week. The Linux Host I was testing with is a VM version of Xubuntu 16.10 however eventually it will be an custom embedded board (similar to a Beagle Bone). The BLE hardware + Host must come up correctly every time or it will be a serious problem.
ALan
-----Original Message-----
From: will sanfilippo [mailto:wills@runtime.io]
Sent: Friday, February 10, 2017 1:23 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Hello Alan:
I may be reading this incorrectly or mistaken, but the host does not need to see the NOOP from the controller. The controller needs to be ready to receive the HCI Reset command from the host. At least, that is my understanding after the email exchange with Andrzej. I would have thought there would be a retry mechanism as well but that is not the case. So all you need to insure is that the controller is up and running before the host sends the HCI Reset.
Am I making sense? :-)
> On Feb 10, 2017, at 12:39 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>
> Hi Guys,
>
> The BLE hardware I have to work with does not provide hardware flow control with RTS/CTS. The CTS line is grounded and the RTS is left not connected. In any case the BLE module is on its own board that is internally connected to the Linux host processor. It is probably safe to assume that in this situation the Nordic chip will be powered up and expecting the Host to be ready to receive any messages sent via the BLE HCI before the Linux BlueZ stack is initialized. Obviously I could arbitrarily delay the NOOP message timing so that the two ends can be in sync, but to not have a timeout mechanism on the HCI protocol would seem to me to be a guarantee that a deadlock condition would occur. Another possibility is that perhaps I can find a way to keep the BLE hardware in a reset state until the Host is initialized by driving the RESET signal with a GPIO line.
>
> ALan
>
> -----Original Message-----
> From: will sanfilippo [mailto:wills@runtime.io]
> Sent: Monday, February 06, 2017 5:55 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: BLE HCI support on NRF52DK
>
> Ah ok; that is quite interesting. I did not realize that was the case and I was thinking of an external board that was powered off (and not quite trusting the state of the flow control lines).
>
> Then really the only thing we need to make sure on our end is that when UART is brought up and the flow control line is properly de-asserted the nimble stack sees any commands that were sent by the host (in the case where the UART comes up first, then the rest of the nimble stack).
>
> Will
>
>> On Feb 6, 2017, at 10:27 AM, Andrzej Kaczmarek <an...@codecoup.pl> wrote:
>>
>> Hi Will,
>>
>> I could not find any timeout defined for HCI commands so the problem
>> here would be when host should timeout and resend HCI Reset. I think
>> we should just assume that hw is designed properly and flow control
>> lines are either pulled or driven externally all the time so this is not overly complicated.
>> Actually, if you check Vol 4 Part A Section 1, it says that objective
>> of UART TL is to have both ends on the same PCB and communication is
>> free form errors, so there is no case that we suddenly have
>> controller disconnected - I'd say above assumption is reasonable :-)
>>
>> BR,
>> Andrzej
>>
>>
>>
>> On Sat, Feb 4, 2017 at 12:25 AM, will sanfilippo <wi...@runtime.io> wrote:
>>
>>> Hi Andrzej
>>>
>>> Thanks for pointing me to Vol 2 Part E, Section 4.4. I was recalling
>>> a section of the spec that talked about this but could not find it
>>> when I sent this email. Thus, I completely agree that the controller
>>> sending a NOOP does not in any way indicate that it reset. It is
>>> fine if the controller does send a NOOP, but the host cannot use
>>> that as an indication that the controller reset. That does make
>>> things a bit tricky though as you mention, but hopefully if
>>> something is really badly out of sync the host will figure it out and reset the controller.
>>>
>>> I was also thinking of the following scenario which I should have
>>> explained a bit better. If the controller is powered off, it is not
>>> driving the flow control line so I am not sure what would happen HW
>>> wise in this case. It could be that the flow control line is
>>> floating, and therefore the host could see it in various states.
>>> Therefore, I would suspect that when a host issues a HCI Reset and
>>> does not get a response for some amount of time, it just keeps issuing the HCI Reset until it gets a response.
>>>
>>> Given that a controller can send a NOOP on power up, I cant see how
>>> we can guarantee that the following will NOT happen:
>>>
>>> * Host sends HCI Reset
>>> * Controller sends NOOP
>>> * Controller sends Command Complete w/Reset opcode
>>>
>>> I can also see this happening:
>>>
>>> * Host sends HCI Reset
>>> * Controller sends NOOP
>>> * Nothing else happens
>>>
>>> I certainly agree that once the controller actively takes control of
>>> the flow control line it should honor the HCI Reset although I still
>>> see the possibility of the two scenarios described above happening.
>>>
>>> Regarding HW Error: that is something we can do in the controller as
>>> we can look at the reason why the device reset and send a HW error event.
>>>
>>>
>>>> On Feb 3, 2017, at 12:12 PM, Andrzej Kaczmarek <
>>> andrzej.kaczmarek@codecoup.pl> wrote:
>>>>
>>>> Hi Will,
>>>>
>>>> On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <wi...@runtime.io>
>>> wrote:
>>>>
>>>>> I might be getting a bit confused here so hopefully I am making
>>>>> some sense. I seem to recall some discussion around this in the
>>>>> past but I
>>> cant
>>>>> recall :-) Anyway...
>>>>>
>>>>> It is my understanding that the first thing a controller should do
>>>>> when
>>> it
>>>>> powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6
>>>>> Part D Section 2 you can see a message sequence chart that shows this.
>>>>> It
>>> sounds
>>>>> like folks think MyNewt is different than other controllers in
>>>>> this respect. If so, we can change that behavior, but it makes
>>>>> sense to me
>>> to do
>>>>> this, as it will inform the host that the controller has powered up.
>>>>>
>>>>
>>>> The section you quote is only informative (see section 1.1 of the
>>>> same
>>>> part) and the diagram is only one of possibilities. The actual
>>> requirement
>>>> is in Vol 2, Part E, Section 4.4 which states that after power up
>>>> host is allowed to send up to 1 outstanding command so 1 credit is assumed here.
>>>> Also controller does not need to send noop, but it is also not an
>>>> error
>>> to
>>>> do so.
>>>>
>>>> Of course, there is a chicken and egg problem here. If the
>>>> controller is
>>>>> not powered up and the host sends a HCI Reset, the host is
>>>>> obviously not going to get a response. I am also not sure one can
>>>>> trust the flow
>>> control
>>>>> lines if the board is not powered up but one would hope that
>>>>> RTS/CTS are pulled the proper way if the controller is not powered.
>>>>>
>>>>
>>>> I guess host can assume that CTS/RTS lines work properly, otherwise
>>>> there is no way to detect when controller is ready to receive something (i.e.
>>> is
>>>> attached).
>>>>
>>>>
>>>>> Certainly, an interesting issue with the MyNewt HCI firmware would
>>>>> be
>>> the
>>>>> order in which the UART gets initialized and when the LL is
>>> initialized. In
>>>>> the end, I dont think it should really matter, as the host should
>>>>> have
>>> to
>>>>> deal with the controller not being ready to receive the HCI Reset.
>>>>>
>>>>
>>>> My understanding of spec section I mentioned is that controller
>>>> should be always ready to receive HCI Reset after power up. If it
>>>> is not, then flow control on transport layer should not be enabled.
>>>>
>>>>
>>>>> Here are the basic scenarios and what I would expect:
>>>>>
>>>>> 1. Controller powers up first and host is not powered or not ready
>>>>> * Controller issues NOOP but host does not see it.
>>>>> * Host wakes up and sends HCI Reset.
>>>>> * Host gets Command Complete (with proper opcode) and all is well
>>>>>
>>>>
>>>> Agree.
>>>>
>>>> 2. Host powers up first and controller powers up some time later
>>>>> * Host sends HCI Reset but gets no response.
>>>>> * Host sits in a loop, sending HCI Resets periodically.
>>>>> * If Host gets a NOOP, it knows that the controller has powered up.
>>>>> In this case, the host should issue HCI Reset and should get a
>>>>> Command Complete.
>>>>> * If the Host gets a Command Complete with proper opcode, all is well.
>>>>>
>>>>
>>>> I think this is the case where host actually does not send HCI
>>>> Reset
>>> since
>>>> controller is not ready and RTS/CTS flow control is not enabled. If
>>>> controller enabled hardware flow control, it should receive and
>>>> process anything according to spec.
>>>>
>>>> 3. Host and Controller were communicating fine and Controller
>>>> powers
>>> off/on
>>>>> * Host will see an “unsolicited” NOOP and should realize that the
>>>>> Controller has just reset. Host should perform appropriate actions.
>>>>>
>>>>
>>>> No, because controller can send noop at any time and it does not
>>>> mean a reset - see section I mentioned earlier. But to be honest I
>>>> don't really know how this should be handled properly. Probably the
>>>> things would go so wrong (due to states on both sides which are out
>>>> of sync) that either controller would eventually issue a hardware
>>>> error event or host would request controller since it cannot talk
>>>> to it anymore. But it's up to implementations which one will detect this first, I guess.
>>>>
>>>> 4. Host and Controller were communicating fine and Host powers
>>>> off/on
>>>>> * Controller sees a HCI Reset and performs appropriate actions.
>>>>>
>>>>
>>>> Agree.
>>>>
>>>>
>>>>> An interesting case is one where the controller resets for a known
>>> reason
>>>>> (i.e. firmware asserts). Should the controller send a HW Error
>>>>> event in this case? Some folks I talked to thought it should;
>>>>> others were not
>>> sure.
>>>>> The nimble firmware does not do that; currently the only reason a
>>>>> HW
>>> error
>>>>> event is issued is when synchronization is lost between the host
>>>>> and controller (See Vol 4 Part A Section Part 4 Error Recovery).
>>>>>
>>>>
>>>> I'd say it should - this event is for "some type of hardware
>>>> failure" as spec says, so it could well be an assert in firmware.
>>>>
>>>>
>>>>>
>>>>> Comments/Thoughts?
>>>>>
>>>>>
>>>>>> On Feb 3, 2017, at 4:07 AM, Szymon Janc <sz...@codecoup.pl>
>>> wrote:
>>>>>>
>>>>>> Hi Alan,
>>>>>>
>>>>>> On 3 February 2017 at 07:16, Alan Graves
>>>>>> <ag...@deltacontrols.com>
>>>>> wrote:
>>>>>>> Hi Szymon,
>>>>>>>
>>>>>>> I don't think waiting for the NOP before attaching made any
>>> difference,
>>>>> but now I can't remember so I'll have to check that. In any case
>>>>> here is the btmon output I got during my initial testing:
>>>>>>>
>>>>>>> $ sudo btmon
>>>>>>> [sudo] password for alan:
>>>>>>> Bluetooth monitor ver 5.41
>>>>>>> = Note: Linux version 4.8.0-34-generic (x86_64)
>>>>> 0.977791
>>>>>>> = Note: Bluetooth subsystem version 2.21
>>>>> 0.977792
>>>>>>> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0]
>>>>> 121.060311
>>>>>>> = Open Index: 00:00:00:00:00:00 [hci0]
>>>>> 121.066478
>>>>>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0]
>>>>> 121.070996
>>>>>>> = bluetoothd: Bluetooth daemon 5.41
>>>>> 121.092783
>>>>>>> = bluetoothd: Starting SDP server
>>>>> 121.104354
>>>>>>> = bluetoothd: Bluetooth management interface 1.13 initialized
>>>>> 121.112600
>>>>>>>> HCI Event: Command Complete (0x0e) plen 3 [hci0]
>>>>> 126.168513
>>>>>>> NOP (0x00|0x0000) ncmd 1
>>>>>>> = Close Index: 00:00:00:00:00:00 [hci0]
>>>>> 131.246188
>>>>>>>
>>>>>>
>>>>>> I suspect that HCI Reset is simply ignored before NOP is sent and
>>>>>> Linux will not try sending another command before getting Command
>>>>>> Status for it.
>>>>>> And that will never happen since command was ignored ie. Zephyr
>>>>>> has special config option when used with Mynewt based BT firmware
>>>>>> to handle this exact situation - send HCI Reset only after
>>>>>> initial NOP was received.
>>>>>> Linux on the other hand assumes that once device is attached it
>>>>>> is ready to receive initial HCI Reset.
>>>>>>
>>>>>>> ALan
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>>>>>>> Sent: Thursday, February 02, 2017 12:18 PM
>>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>>
>>>>>>> Hi Alan,
>>>>>>>
>>>>>>> On 2 February 2017 at 19:16, Alan Graves
>>>>>>> <ag...@deltacontrols.com>
>>>>> 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...
>>>>>>>
>>>>>>> btattach has -N, --noflowctl option for disabling flow control.
>>>>>>> Yet,
>>>>> it is not recommended for H4 protocol (actually, H4 spec requires
>>>>> flow control to be enabled).
>>>>>>>
>>>>>>> But I'd first check if simply waiting for few seconds before
>>>>>>> calling
>>>>> btattach fix the problem (ie so that Linux sends initial HCI Reset
>>>>> after NOP event was emitted).
>>>>>>>
>>>>>>>> ALan
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher Collins [mailto:ccollins@apache.org]
>>>>>>>> Sent: Wednesday, February 01, 2017 4:00 PM
>>>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>>>
>>>>>>>> Hi Alan,
>>>>>>>>
>>>>>>>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I've spent some time trying to get nRF52832 DK running the 'blehci'
>>>>> code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>>>>>>>>
>>>>>>>> I just ran the latest blehci from develop with the following setup:
>>>>>>>>
>>>>>>>> * BlueZ 5.39
>>>>>>>> * Ubuntu 16.04 (Xenial)
>>>>>>>> * nRF52832 DK
>>>>>>>>
>>>>>>>> I didn't notice any issues when I tried. I'm afraid I don't
>>>>>>>> see
>>>>> anything wrong with the steps you follows. Maybe one of the
>>>>> following hints will help:
>>>>>>>>
>>>>>>>> * Make sure the two flow control pins (RTS / CTS) are attached.
>>>>>>>>
>>>>>>>> * Try killing btattach and restarting it. When you do this,
>>>>>>>> you
>>> should
>>>>>>>> see BlueZ send the host init sequence in btmon (starting with a
>>>>>>>> Reset command).
>>>>>>>>
>>>>>>>> The btattach step is required because the BlueZ host doesn't
>>>>>>>> seem to
>>>>> interpret the no-op event as a controller reset. You have to
>>>>> explicitly tell the host to reset the controller.
>>>>>>>>
>>>>>>>> Hopefully this gets you a little closer to a solution. If
>>>>>>>> you're
>>>>> still seeing the same issue, just let me know and we can debug it
>>> further.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> pozdrawiam
>>>>>>> Szymon K. Janc
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> pozdrawiam
>>>>>> Szymon K. Janc
>>>>>
>>>>>
>>>> BR,
>>>> Andrzej
>>>
>>>
>
RE: BLE HCI support on NRF52DK
Posted by Alan Graves <ag...@deltacontrols.com>.
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)
[hci1]#
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? However, I am able to get some activity going with the 'find' command, which seems to scan ok for BLE devices. For example I get this output:
[hci1]# find -l
Discovery started
hci1 type 6 discovering on
hci1 dev_found: FC:F1:36:2B:33:B0 type LE Public rssi -90 flags 0x0004
AD flags 0x00
eir_len 28
hci1 type 6 discovering off
[hci1]#
The usual 'hciconfig' command shows the following configuration:
$ hciconfig -a
hci1: Type: Primary Bus: UART
BD Address: 00:00:00:00:00:00 ACL MTU: 255:12 SCO MTU: 0:0
UP RUNNING
RX bytes:696 acl:0 sco:0 events:50 errors:0
TX bytes:367 acl:0 sco:0 commands:47 errors:0
Features: 0x00 0x00 0x00 0x00 0x60 0x00 0x00 0x00
Packet type: DM1 DH1 HV1
Link policy:
Link mode: SLAVE ACCEPT
Can't read local name on hci1: Input/output error (5)
$
Things are not making this command happy either. So when I drop the '-a' option I get the following:
$ hciconfig
hci1: Type: Primary Bus: UART
BD Address: 00:00:00:00:00:00 ACL MTU: 255:12 SCO MTU: 0:0
UP RUNNING
RX bytes:703 acl:0 sco:0 events:51 errors:0
TX bytes:371 acl:0 sco:0 commands:48 errors:0
hci0: Type: Primary Bus: USB
BD Address: 80:00:0B:C5:3E:C8 ACL MTU: 8192:128 SCO MTU: 64:128
UP RUNNING PSCAN ISCAN
RX bytes:1301 acl:0 sco:0 events:50 errors:0
TX bytes:702 acl:0 sco:0 commands:50 errors:0
$
This is a little better and shows that the BLE controller (on hci1) appears to be working properly. I therefore proceeded to try to get a simple C application to do the scanning and that's where I'm stuck. In particular I can't get past an ioctl function call that is used within the 'hci_inquiry' function of the BlueZ interface. This is the C code I'm testing with:
/* file: simplescan.c */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/socket.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>
int main(int argc, char **argv)
{
inquiry_info *ii = NULL;
int max_rsp, num_rsp;
int dev_id, sock, len, flags;
int i;
char addr[19] = { 0 };
char name[248] = { 0 };
#if 0
dev_id = hci_get_route(NULL);
#else
dev_id = hci_devid("00:00:00:00:00:00");
#endif
printf("dev_id=%d\n",dev_id);
if(dev_id < 0) {
perror("no device available");
exit(1);
}
sock = hci_open_dev( dev_id );
if (dev_id < 0 || sock < 0) {
perror("opening socket");
exit(1);
}
printf("scanning\n");
len = 8;
max_rsp = 255;
flags = IREQ_CACHE_FLUSH;
ii = (inquiry_info*)malloc(max_rsp * sizeof(inquiry_info));
num_rsp = hci_inquiry(dev_id, len, max_rsp, NULL, &ii, flags);
if( num_rsp < 0 ) {
perror("hci_inquiry");
}
for (i = 0; i < num_rsp; i++) {
ba2str(&(ii+i)->bdaddr, addr);
memset(name, 0, sizeof(name));
if (hci_read_remote_name(sock, &(ii+i)->bdaddr, sizeof(name),
name, 0) < 0)
strcpy(name, "[unknown]");
printf("%s %s\n", addr, name);
}
free( ii );
close( sock );
return 0;
}
/* end simplescan.c */
I built and execute this code as follows:
$gcc simplesscan.c -o simplescan ../bluez/lib/hci.c ../bluez/lib/bluetooth.c -I../bluez/lib
$ ./simplescan
dev_id=1
scanning
hci_get_route ok
socket ok
ioctl errno=95
hci_inquiry: Operation not supported
$
Note I added a few extra printf in the hci.c file to determine where the failure occurs. If I change the program to allow the dev_id=0 (i.e. my laptop's built-in USB Bluetooth adapter) to be used the scan actually finds a few BT devices:
$ ./simplescan
dev_id=0
scanning
hci_get_route ok
socket ok
ioctl ok
E0:D1:73:E1:AE:16 CP-8945
20:4C:9E:6C:BE:6E CP-8945
1C:E6:C7:9A:B0:86 CP-8945
00:02:72:C6:55:B9 DELSRY3595
$
Like I said it frustrating work and makes me want to abandon the HCI mode and just do my own serial protocol with a custom application on the nRF52 chip. In fact, the ublox NINA-B112 module comes with their own proprietary 'AT command' firmware that works ok with a serial host application and just uses the Nordic SoftDevice... But that would mean no MyNewt :O
ALan
-----Original Message-----
From: Alan Graves
Sent: Wednesday, February 22, 2017 5:25 PM
To: dev@mynewt.incubator.apache.org
Subject: RE: BLE HCI support on NRF52DK
I have an update on my progress with the HCI testing. I did as Chris suggested and rebuilt the BlueZ from source to disable the hardware flow control and configured the target HCI mode to disable the UART RTS/CTS handshake lines. So far it appears that everything is operating correctly although I haven't done very extensive testing yet.
ALan
-----Original Message-----
From: Alan Graves [mailto:agraves@deltacontrols.com]
Sent: Friday, February 10, 2017 2:00 PM
To: dev@mynewt.incubator.apache.org
Subject: RE: BLE HCI support on NRF52DK
Yes thanks I also got that from the discussion. In retrospect, I think my difficulty arouse because I did not connect the RTS/CTS lines on my hardware as would be case for testing on the standard nRF52DK board. As well I assume I couldn't type fast enough to issue all the terminal commands necessary. As a result the Host closed the connection. Unfortunately I haven't been able to retest as I am away from work for at least another week. The Linux Host I was testing with is a VM version of Xubuntu 16.10 however eventually it will be an custom embedded board (similar to a Beagle Bone). The BLE hardware + Host must come up correctly every time or it will be a serious problem.
ALan
-----Original Message-----
From: will sanfilippo [mailto:wills@runtime.io]
Sent: Friday, February 10, 2017 1:23 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Hello Alan:
I may be reading this incorrectly or mistaken, but the host does not need to see the NOOP from the controller. The controller needs to be ready to receive the HCI Reset command from the host. At least, that is my understanding after the email exchange with Andrzej. I would have thought there would be a retry mechanism as well but that is not the case. So all you need to insure is that the controller is up and running before the host sends the HCI Reset.
Am I making sense? :-)
> On Feb 10, 2017, at 12:39 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>
> Hi Guys,
>
> The BLE hardware I have to work with does not provide hardware flow control with RTS/CTS. The CTS line is grounded and the RTS is left not connected. In any case the BLE module is on its own board that is internally connected to the Linux host processor. It is probably safe to assume that in this situation the Nordic chip will be powered up and expecting the Host to be ready to receive any messages sent via the BLE HCI before the Linux BlueZ stack is initialized. Obviously I could arbitrarily delay the NOOP message timing so that the two ends can be in sync, but to not have a timeout mechanism on the HCI protocol would seem to me to be a guarantee that a deadlock condition would occur. Another possibility is that perhaps I can find a way to keep the BLE hardware in a reset state until the Host is initialized by driving the RESET signal with a GPIO line.
>
> ALan
>
> -----Original Message-----
> From: will sanfilippo [mailto:wills@runtime.io]
> Sent: Monday, February 06, 2017 5:55 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: BLE HCI support on NRF52DK
>
> Ah ok; that is quite interesting. I did not realize that was the case and I was thinking of an external board that was powered off (and not quite trusting the state of the flow control lines).
>
> Then really the only thing we need to make sure on our end is that when UART is brought up and the flow control line is properly de-asserted the nimble stack sees any commands that were sent by the host (in the case where the UART comes up first, then the rest of the nimble stack).
>
> Will
>
>> On Feb 6, 2017, at 10:27 AM, Andrzej Kaczmarek <an...@codecoup.pl> wrote:
>>
>> Hi Will,
>>
>> I could not find any timeout defined for HCI commands so the problem
>> here would be when host should timeout and resend HCI Reset. I think
>> we should just assume that hw is designed properly and flow control
>> lines are either pulled or driven externally all the time so this is not overly complicated.
>> Actually, if you check Vol 4 Part A Section 1, it says that objective
>> of UART TL is to have both ends on the same PCB and communication is
>> free form errors, so there is no case that we suddenly have
>> controller disconnected - I'd say above assumption is reasonable :-)
>>
>> BR,
>> Andrzej
>>
>>
>>
>> On Sat, Feb 4, 2017 at 12:25 AM, will sanfilippo <wi...@runtime.io> wrote:
>>
>>> Hi Andrzej
>>>
>>> Thanks for pointing me to Vol 2 Part E, Section 4.4. I was recalling
>>> a section of the spec that talked about this but could not find it
>>> when I sent this email. Thus, I completely agree that the controller
>>> sending a NOOP does not in any way indicate that it reset. It is
>>> fine if the controller does send a NOOP, but the host cannot use
>>> that as an indication that the controller reset. That does make
>>> things a bit tricky though as you mention, but hopefully if
>>> something is really badly out of sync the host will figure it out and reset the controller.
>>>
>>> I was also thinking of the following scenario which I should have
>>> explained a bit better. If the controller is powered off, it is not
>>> driving the flow control line so I am not sure what would happen HW
>>> wise in this case. It could be that the flow control line is
>>> floating, and therefore the host could see it in various states.
>>> Therefore, I would suspect that when a host issues a HCI Reset and
>>> does not get a response for some amount of time, it just keeps issuing the HCI Reset until it gets a response.
>>>
>>> Given that a controller can send a NOOP on power up, I cant see how
>>> we can guarantee that the following will NOT happen:
>>>
>>> * Host sends HCI Reset
>>> * Controller sends NOOP
>>> * Controller sends Command Complete w/Reset opcode
>>>
>>> I can also see this happening:
>>>
>>> * Host sends HCI Reset
>>> * Controller sends NOOP
>>> * Nothing else happens
>>>
>>> I certainly agree that once the controller actively takes control of
>>> the flow control line it should honor the HCI Reset although I still
>>> see the possibility of the two scenarios described above happening.
>>>
>>> Regarding HW Error: that is something we can do in the controller as
>>> we can look at the reason why the device reset and send a HW error event.
>>>
>>>
>>>> On Feb 3, 2017, at 12:12 PM, Andrzej Kaczmarek <
>>> andrzej.kaczmarek@codecoup.pl> wrote:
>>>>
>>>> Hi Will,
>>>>
>>>> On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <wi...@runtime.io>
>>> wrote:
>>>>
>>>>> I might be getting a bit confused here so hopefully I am making
>>>>> some sense. I seem to recall some discussion around this in the
>>>>> past but I
>>> cant
>>>>> recall :-) Anyway...
>>>>>
>>>>> It is my understanding that the first thing a controller should do
>>>>> when
>>> it
>>>>> powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6
>>>>> Part D Section 2 you can see a message sequence chart that shows this.
>>>>> It
>>> sounds
>>>>> like folks think MyNewt is different than other controllers in
>>>>> this respect. If so, we can change that behavior, but it makes
>>>>> sense to me
>>> to do
>>>>> this, as it will inform the host that the controller has powered up.
>>>>>
>>>>
>>>> The section you quote is only informative (see section 1.1 of the
>>>> same
>>>> part) and the diagram is only one of possibilities. The actual
>>> requirement
>>>> is in Vol 2, Part E, Section 4.4 which states that after power up
>>>> host is allowed to send up to 1 outstanding command so 1 credit is assumed here.
>>>> Also controller does not need to send noop, but it is also not an
>>>> error
>>> to
>>>> do so.
>>>>
>>>> Of course, there is a chicken and egg problem here. If the
>>>> controller is
>>>>> not powered up and the host sends a HCI Reset, the host is
>>>>> obviously not going to get a response. I am also not sure one can
>>>>> trust the flow
>>> control
>>>>> lines if the board is not powered up but one would hope that
>>>>> RTS/CTS are pulled the proper way if the controller is not powered.
>>>>>
>>>>
>>>> I guess host can assume that CTS/RTS lines work properly, otherwise
>>>> there is no way to detect when controller is ready to receive something (i.e.
>>> is
>>>> attached).
>>>>
>>>>
>>>>> Certainly, an interesting issue with the MyNewt HCI firmware would
>>>>> be
>>> the
>>>>> order in which the UART gets initialized and when the LL is
>>> initialized. In
>>>>> the end, I dont think it should really matter, as the host should
>>>>> have
>>> to
>>>>> deal with the controller not being ready to receive the HCI Reset.
>>>>>
>>>>
>>>> My understanding of spec section I mentioned is that controller
>>>> should be always ready to receive HCI Reset after power up. If it
>>>> is not, then flow control on transport layer should not be enabled.
>>>>
>>>>
>>>>> Here are the basic scenarios and what I would expect:
>>>>>
>>>>> 1. Controller powers up first and host is not powered or not ready
>>>>> * Controller issues NOOP but host does not see it.
>>>>> * Host wakes up and sends HCI Reset.
>>>>> * Host gets Command Complete (with proper opcode) and all is well
>>>>>
>>>>
>>>> Agree.
>>>>
>>>> 2. Host powers up first and controller powers up some time later
>>>>> * Host sends HCI Reset but gets no response.
>>>>> * Host sits in a loop, sending HCI Resets periodically.
>>>>> * If Host gets a NOOP, it knows that the controller has powered up.
>>>>> In this case, the host should issue HCI Reset and should get a
>>>>> Command Complete.
>>>>> * If the Host gets a Command Complete with proper opcode, all is well.
>>>>>
>>>>
>>>> I think this is the case where host actually does not send HCI
>>>> Reset
>>> since
>>>> controller is not ready and RTS/CTS flow control is not enabled. If
>>>> controller enabled hardware flow control, it should receive and
>>>> process anything according to spec.
>>>>
>>>> 3. Host and Controller were communicating fine and Controller
>>>> powers
>>> off/on
>>>>> * Host will see an “unsolicited” NOOP and should realize that the
>>>>> Controller has just reset. Host should perform appropriate actions.
>>>>>
>>>>
>>>> No, because controller can send noop at any time and it does not
>>>> mean a reset - see section I mentioned earlier. But to be honest I
>>>> don't really know how this should be handled properly. Probably the
>>>> things would go so wrong (due to states on both sides which are out
>>>> of sync) that either controller would eventually issue a hardware
>>>> error event or host would request controller since it cannot talk
>>>> to it anymore. But it's up to implementations which one will detect this first, I guess.
>>>>
>>>> 4. Host and Controller were communicating fine and Host powers
>>>> off/on
>>>>> * Controller sees a HCI Reset and performs appropriate actions.
>>>>>
>>>>
>>>> Agree.
>>>>
>>>>
>>>>> An interesting case is one where the controller resets for a known
>>> reason
>>>>> (i.e. firmware asserts). Should the controller send a HW Error
>>>>> event in this case? Some folks I talked to thought it should;
>>>>> others were not
>>> sure.
>>>>> The nimble firmware does not do that; currently the only reason a
>>>>> HW
>>> error
>>>>> event is issued is when synchronization is lost between the host
>>>>> and controller (See Vol 4 Part A Section Part 4 Error Recovery).
>>>>>
>>>>
>>>> I'd say it should - this event is for "some type of hardware
>>>> failure" as spec says, so it could well be an assert in firmware.
>>>>
>>>>
>>>>>
>>>>> Comments/Thoughts?
>>>>>
>>>>>
>>>>>> On Feb 3, 2017, at 4:07 AM, Szymon Janc <sz...@codecoup.pl>
>>> wrote:
>>>>>>
>>>>>> Hi Alan,
>>>>>>
>>>>>> On 3 February 2017 at 07:16, Alan Graves
>>>>>> <ag...@deltacontrols.com>
>>>>> wrote:
>>>>>>> Hi Szymon,
>>>>>>>
>>>>>>> I don't think waiting for the NOP before attaching made any
>>> difference,
>>>>> but now I can't remember so I'll have to check that. In any case
>>>>> here is the btmon output I got during my initial testing:
>>>>>>>
>>>>>>> $ sudo btmon
>>>>>>> [sudo] password for alan:
>>>>>>> Bluetooth monitor ver 5.41
>>>>>>> = Note: Linux version 4.8.0-34-generic (x86_64)
>>>>> 0.977791
>>>>>>> = Note: Bluetooth subsystem version 2.21
>>>>> 0.977792
>>>>>>> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0]
>>>>> 121.060311
>>>>>>> = Open Index: 00:00:00:00:00:00 [hci0]
>>>>> 121.066478
>>>>>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0]
>>>>> 121.070996
>>>>>>> = bluetoothd: Bluetooth daemon 5.41
>>>>> 121.092783
>>>>>>> = bluetoothd: Starting SDP server
>>>>> 121.104354
>>>>>>> = bluetoothd: Bluetooth management interface 1.13 initialized
>>>>> 121.112600
>>>>>>>> HCI Event: Command Complete (0x0e) plen 3 [hci0]
>>>>> 126.168513
>>>>>>> NOP (0x00|0x0000) ncmd 1
>>>>>>> = Close Index: 00:00:00:00:00:00 [hci0]
>>>>> 131.246188
>>>>>>>
>>>>>>
>>>>>> I suspect that HCI Reset is simply ignored before NOP is sent and
>>>>>> Linux will not try sending another command before getting Command
>>>>>> Status for it.
>>>>>> And that will never happen since command was ignored ie. Zephyr
>>>>>> has special config option when used with Mynewt based BT firmware
>>>>>> to handle this exact situation - send HCI Reset only after
>>>>>> initial NOP was received.
>>>>>> Linux on the other hand assumes that once device is attached it
>>>>>> is ready to receive initial HCI Reset.
>>>>>>
>>>>>>> ALan
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>>>>>>> Sent: Thursday, February 02, 2017 12:18 PM
>>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>>
>>>>>>> Hi Alan,
>>>>>>>
>>>>>>> On 2 February 2017 at 19:16, Alan Graves
>>>>>>> <ag...@deltacontrols.com>
>>>>> 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...
>>>>>>>
>>>>>>> btattach has -N, --noflowctl option for disabling flow control.
>>>>>>> Yet,
>>>>> it is not recommended for H4 protocol (actually, H4 spec requires
>>>>> flow control to be enabled).
>>>>>>>
>>>>>>> But I'd first check if simply waiting for few seconds before
>>>>>>> calling
>>>>> btattach fix the problem (ie so that Linux sends initial HCI Reset
>>>>> after NOP event was emitted).
>>>>>>>
>>>>>>>> ALan
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher Collins [mailto:ccollins@apache.org]
>>>>>>>> Sent: Wednesday, February 01, 2017 4:00 PM
>>>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>>>
>>>>>>>> Hi Alan,
>>>>>>>>
>>>>>>>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I've spent some time trying to get nRF52832 DK running the 'blehci'
>>>>> code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>>>>>>>>
>>>>>>>> I just ran the latest blehci from develop with the following setup:
>>>>>>>>
>>>>>>>> * BlueZ 5.39
>>>>>>>> * Ubuntu 16.04 (Xenial)
>>>>>>>> * nRF52832 DK
>>>>>>>>
>>>>>>>> I didn't notice any issues when I tried. I'm afraid I don't
>>>>>>>> see
>>>>> anything wrong with the steps you follows. Maybe one of the
>>>>> following hints will help:
>>>>>>>>
>>>>>>>> * Make sure the two flow control pins (RTS / CTS) are attached.
>>>>>>>>
>>>>>>>> * Try killing btattach and restarting it. When you do this,
>>>>>>>> you
>>> should
>>>>>>>> see BlueZ send the host init sequence in btmon (starting with a
>>>>>>>> Reset command).
>>>>>>>>
>>>>>>>> The btattach step is required because the BlueZ host doesn't
>>>>>>>> seem to
>>>>> interpret the no-op event as a controller reset. You have to
>>>>> explicitly tell the host to reset the controller.
>>>>>>>>
>>>>>>>> Hopefully this gets you a little closer to a solution. If
>>>>>>>> you're
>>>>> still seeing the same issue, just let me know and we can debug it
>>> further.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> pozdrawiam
>>>>>>> Szymon K. Janc
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> pozdrawiam
>>>>>> Szymon K. Janc
>>>>>
>>>>>
>>>> BR,
>>>> Andrzej
>>>
>>>
>
RE: BLE HCI support on NRF52DK
Posted by Alan Graves <ag...@deltacontrols.com>.
Yes thanks I also got that from the discussion. In retrospect, I think my difficulty arouse because I did not connect the RTS/CTS lines on my hardware as would be case for testing on the standard nRF52DK board. As well I assume I couldn't type fast enough to issue all the terminal commands necessary. As a result the Host closed the connection. Unfortunately I haven't been able to retest as I am away from work for at least another week. The Linux Host I was testing with is a VM version of Xubuntu 16.10 however eventually it will be an custom embedded board (similar to a Beagle Bone). The BLE hardware + Host must come up correctly every time or it will be a serious problem.
ALan
-----Original Message-----
From: will sanfilippo [mailto:wills@runtime.io]
Sent: Friday, February 10, 2017 1:23 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Hello Alan:
I may be reading this incorrectly or mistaken, but the host does not need to see the NOOP from the controller. The controller needs to be ready to receive the HCI Reset command from the host. At least, that is my understanding after the email exchange with Andrzej. I would have thought there would be a retry mechanism as well but that is not the case. So all you need to insure is that the controller is up and running before the host sends the HCI Reset.
Am I making sense? :-)
> On Feb 10, 2017, at 12:39 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>
> Hi Guys,
>
> The BLE hardware I have to work with does not provide hardware flow control with RTS/CTS. The CTS line is grounded and the RTS is left not connected. In any case the BLE module is on its own board that is internally connected to the Linux host processor. It is probably safe to assume that in this situation the Nordic chip will be powered up and expecting the Host to be ready to receive any messages sent via the BLE HCI before the Linux BlueZ stack is initialized. Obviously I could arbitrarily delay the NOOP message timing so that the two ends can be in sync, but to not have a timeout mechanism on the HCI protocol would seem to me to be a guarantee that a deadlock condition would occur. Another possibility is that perhaps I can find a way to keep the BLE hardware in a reset state until the Host is initialized by driving the RESET signal with a GPIO line.
>
> ALan
>
> -----Original Message-----
> From: will sanfilippo [mailto:wills@runtime.io]
> Sent: Monday, February 06, 2017 5:55 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: BLE HCI support on NRF52DK
>
> Ah ok; that is quite interesting. I did not realize that was the case and I was thinking of an external board that was powered off (and not quite trusting the state of the flow control lines).
>
> Then really the only thing we need to make sure on our end is that when UART is brought up and the flow control line is properly de-asserted the nimble stack sees any commands that were sent by the host (in the case where the UART comes up first, then the rest of the nimble stack).
>
> Will
>
>> On Feb 6, 2017, at 10:27 AM, Andrzej Kaczmarek <an...@codecoup.pl> wrote:
>>
>> Hi Will,
>>
>> I could not find any timeout defined for HCI commands so the problem
>> here would be when host should timeout and resend HCI Reset. I think
>> we should just assume that hw is designed properly and flow control
>> lines are either pulled or driven externally all the time so this is not overly complicated.
>> Actually, if you check Vol 4 Part A Section 1, it says that objective
>> of UART TL is to have both ends on the same PCB and communication is
>> free form errors, so there is no case that we suddenly have
>> controller disconnected - I'd say above assumption is reasonable :-)
>>
>> BR,
>> Andrzej
>>
>>
>>
>> On Sat, Feb 4, 2017 at 12:25 AM, will sanfilippo <wi...@runtime.io> wrote:
>>
>>> Hi Andrzej
>>>
>>> Thanks for pointing me to Vol 2 Part E, Section 4.4. I was recalling
>>> a section of the spec that talked about this but could not find it
>>> when I sent this email. Thus, I completely agree that the controller
>>> sending a NOOP does not in any way indicate that it reset. It is
>>> fine if the controller does send a NOOP, but the host cannot use
>>> that as an indication that the controller reset. That does make
>>> things a bit tricky though as you mention, but hopefully if
>>> something is really badly out of sync the host will figure it out and reset the controller.
>>>
>>> I was also thinking of the following scenario which I should have
>>> explained a bit better. If the controller is powered off, it is not
>>> driving the flow control line so I am not sure what would happen HW
>>> wise in this case. It could be that the flow control line is
>>> floating, and therefore the host could see it in various states.
>>> Therefore, I would suspect that when a host issues a HCI Reset and
>>> does not get a response for some amount of time, it just keeps issuing the HCI Reset until it gets a response.
>>>
>>> Given that a controller can send a NOOP on power up, I cant see how
>>> we can guarantee that the following will NOT happen:
>>>
>>> * Host sends HCI Reset
>>> * Controller sends NOOP
>>> * Controller sends Command Complete w/Reset opcode
>>>
>>> I can also see this happening:
>>>
>>> * Host sends HCI Reset
>>> * Controller sends NOOP
>>> * Nothing else happens
>>>
>>> I certainly agree that once the controller actively takes control of
>>> the flow control line it should honor the HCI Reset although I still
>>> see the possibility of the two scenarios described above happening.
>>>
>>> Regarding HW Error: that is something we can do in the controller as
>>> we can look at the reason why the device reset and send a HW error event.
>>>
>>>
>>>> On Feb 3, 2017, at 12:12 PM, Andrzej Kaczmarek <
>>> andrzej.kaczmarek@codecoup.pl> wrote:
>>>>
>>>> Hi Will,
>>>>
>>>> On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <wi...@runtime.io>
>>> wrote:
>>>>
>>>>> I might be getting a bit confused here so hopefully I am making
>>>>> some sense. I seem to recall some discussion around this in the
>>>>> past but I
>>> cant
>>>>> recall :-) Anyway...
>>>>>
>>>>> It is my understanding that the first thing a controller should do
>>>>> when
>>> it
>>>>> powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6
>>>>> Part D Section 2 you can see a message sequence chart that shows this.
>>>>> It
>>> sounds
>>>>> like folks think MyNewt is different than other controllers in
>>>>> this respect. If so, we can change that behavior, but it makes
>>>>> sense to me
>>> to do
>>>>> this, as it will inform the host that the controller has powered up.
>>>>>
>>>>
>>>> The section you quote is only informative (see section 1.1 of the
>>>> same
>>>> part) and the diagram is only one of possibilities. The actual
>>> requirement
>>>> is in Vol 2, Part E, Section 4.4 which states that after power up
>>>> host is allowed to send up to 1 outstanding command so 1 credit is assumed here.
>>>> Also controller does not need to send noop, but it is also not an
>>>> error
>>> to
>>>> do so.
>>>>
>>>> Of course, there is a chicken and egg problem here. If the
>>>> controller is
>>>>> not powered up and the host sends a HCI Reset, the host is
>>>>> obviously not going to get a response. I am also not sure one can
>>>>> trust the flow
>>> control
>>>>> lines if the board is not powered up but one would hope that
>>>>> RTS/CTS are pulled the proper way if the controller is not powered.
>>>>>
>>>>
>>>> I guess host can assume that CTS/RTS lines work properly, otherwise
>>>> there is no way to detect when controller is ready to receive something (i.e.
>>> is
>>>> attached).
>>>>
>>>>
>>>>> Certainly, an interesting issue with the MyNewt HCI firmware would
>>>>> be
>>> the
>>>>> order in which the UART gets initialized and when the LL is
>>> initialized. In
>>>>> the end, I dont think it should really matter, as the host should
>>>>> have
>>> to
>>>>> deal with the controller not being ready to receive the HCI Reset.
>>>>>
>>>>
>>>> My understanding of spec section I mentioned is that controller
>>>> should be always ready to receive HCI Reset after power up. If it
>>>> is not, then flow control on transport layer should not be enabled.
>>>>
>>>>
>>>>> Here are the basic scenarios and what I would expect:
>>>>>
>>>>> 1. Controller powers up first and host is not powered or not ready
>>>>> * Controller issues NOOP but host does not see it.
>>>>> * Host wakes up and sends HCI Reset.
>>>>> * Host gets Command Complete (with proper opcode) and all is well
>>>>>
>>>>
>>>> Agree.
>>>>
>>>> 2. Host powers up first and controller powers up some time later
>>>>> * Host sends HCI Reset but gets no response.
>>>>> * Host sits in a loop, sending HCI Resets periodically.
>>>>> * If Host gets a NOOP, it knows that the controller has powered up.
>>>>> In this case, the host should issue HCI Reset and should get a
>>>>> Command Complete.
>>>>> * If the Host gets a Command Complete with proper opcode, all is well.
>>>>>
>>>>
>>>> I think this is the case where host actually does not send HCI
>>>> Reset
>>> since
>>>> controller is not ready and RTS/CTS flow control is not enabled. If
>>>> controller enabled hardware flow control, it should receive and
>>>> process anything according to spec.
>>>>
>>>> 3. Host and Controller were communicating fine and Controller
>>>> powers
>>> off/on
>>>>> * Host will see an “unsolicited” NOOP and should realize that the
>>>>> Controller has just reset. Host should perform appropriate actions.
>>>>>
>>>>
>>>> No, because controller can send noop at any time and it does not
>>>> mean a reset - see section I mentioned earlier. But to be honest I
>>>> don't really know how this should be handled properly. Probably the
>>>> things would go so wrong (due to states on both sides which are out
>>>> of sync) that either controller would eventually issue a hardware
>>>> error event or host would request controller since it cannot talk
>>>> to it anymore. But it's up to implementations which one will detect this first, I guess.
>>>>
>>>> 4. Host and Controller were communicating fine and Host powers
>>>> off/on
>>>>> * Controller sees a HCI Reset and performs appropriate actions.
>>>>>
>>>>
>>>> Agree.
>>>>
>>>>
>>>>> An interesting case is one where the controller resets for a known
>>> reason
>>>>> (i.e. firmware asserts). Should the controller send a HW Error
>>>>> event in this case? Some folks I talked to thought it should;
>>>>> others were not
>>> sure.
>>>>> The nimble firmware does not do that; currently the only reason a
>>>>> HW
>>> error
>>>>> event is issued is when synchronization is lost between the host
>>>>> and controller (See Vol 4 Part A Section Part 4 Error Recovery).
>>>>>
>>>>
>>>> I'd say it should - this event is for "some type of hardware
>>>> failure" as spec says, so it could well be an assert in firmware.
>>>>
>>>>
>>>>>
>>>>> Comments/Thoughts?
>>>>>
>>>>>
>>>>>> On Feb 3, 2017, at 4:07 AM, Szymon Janc <sz...@codecoup.pl>
>>> wrote:
>>>>>>
>>>>>> Hi Alan,
>>>>>>
>>>>>> On 3 February 2017 at 07:16, Alan Graves
>>>>>> <ag...@deltacontrols.com>
>>>>> wrote:
>>>>>>> Hi Szymon,
>>>>>>>
>>>>>>> I don't think waiting for the NOP before attaching made any
>>> difference,
>>>>> but now I can't remember so I'll have to check that. In any case
>>>>> here is the btmon output I got during my initial testing:
>>>>>>>
>>>>>>> $ sudo btmon
>>>>>>> [sudo] password for alan:
>>>>>>> Bluetooth monitor ver 5.41
>>>>>>> = Note: Linux version 4.8.0-34-generic (x86_64)
>>>>> 0.977791
>>>>>>> = Note: Bluetooth subsystem version 2.21
>>>>> 0.977792
>>>>>>> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0]
>>>>> 121.060311
>>>>>>> = Open Index: 00:00:00:00:00:00 [hci0]
>>>>> 121.066478
>>>>>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0]
>>>>> 121.070996
>>>>>>> = bluetoothd: Bluetooth daemon 5.41
>>>>> 121.092783
>>>>>>> = bluetoothd: Starting SDP server
>>>>> 121.104354
>>>>>>> = bluetoothd: Bluetooth management interface 1.13 initialized
>>>>> 121.112600
>>>>>>>> HCI Event: Command Complete (0x0e) plen 3 [hci0]
>>>>> 126.168513
>>>>>>> NOP (0x00|0x0000) ncmd 1
>>>>>>> = Close Index: 00:00:00:00:00:00 [hci0]
>>>>> 131.246188
>>>>>>>
>>>>>>
>>>>>> I suspect that HCI Reset is simply ignored before NOP is sent and
>>>>>> Linux will not try sending another command before getting Command
>>>>>> Status for it.
>>>>>> And that will never happen since command was ignored ie. Zephyr
>>>>>> has special config option when used with Mynewt based BT firmware
>>>>>> to handle this exact situation - send HCI Reset only after
>>>>>> initial NOP was received.
>>>>>> Linux on the other hand assumes that once device is attached it
>>>>>> is ready to receive initial HCI Reset.
>>>>>>
>>>>>>> ALan
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>>>>>>> Sent: Thursday, February 02, 2017 12:18 PM
>>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>>
>>>>>>> Hi Alan,
>>>>>>>
>>>>>>> On 2 February 2017 at 19:16, Alan Graves
>>>>>>> <ag...@deltacontrols.com>
>>>>> 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...
>>>>>>>
>>>>>>> btattach has -N, --noflowctl option for disabling flow control.
>>>>>>> Yet,
>>>>> it is not recommended for H4 protocol (actually, H4 spec requires
>>>>> flow control to be enabled).
>>>>>>>
>>>>>>> But I'd first check if simply waiting for few seconds before
>>>>>>> calling
>>>>> btattach fix the problem (ie so that Linux sends initial HCI Reset
>>>>> after NOP event was emitted).
>>>>>>>
>>>>>>>> ALan
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher Collins [mailto:ccollins@apache.org]
>>>>>>>> Sent: Wednesday, February 01, 2017 4:00 PM
>>>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>>>
>>>>>>>> Hi Alan,
>>>>>>>>
>>>>>>>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I've spent some time trying to get nRF52832 DK running the 'blehci'
>>>>> code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>>>>>>>>
>>>>>>>> I just ran the latest blehci from develop with the following setup:
>>>>>>>>
>>>>>>>> * BlueZ 5.39
>>>>>>>> * Ubuntu 16.04 (Xenial)
>>>>>>>> * nRF52832 DK
>>>>>>>>
>>>>>>>> I didn't notice any issues when I tried. I'm afraid I don't
>>>>>>>> see
>>>>> anything wrong with the steps you follows. Maybe one of the
>>>>> following hints will help:
>>>>>>>>
>>>>>>>> * Make sure the two flow control pins (RTS / CTS) are attached.
>>>>>>>>
>>>>>>>> * Try killing btattach and restarting it. When you do this,
>>>>>>>> you
>>> should
>>>>>>>> see BlueZ send the host init sequence in btmon (starting with a
>>>>>>>> Reset command).
>>>>>>>>
>>>>>>>> The btattach step is required because the BlueZ host doesn't
>>>>>>>> seem to
>>>>> interpret the no-op event as a controller reset. You have to
>>>>> explicitly tell the host to reset the controller.
>>>>>>>>
>>>>>>>> Hopefully this gets you a little closer to a solution. If
>>>>>>>> you're
>>>>> still seeing the same issue, just let me know and we can debug it
>>> further.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> pozdrawiam
>>>>>>> Szymon K. Janc
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> pozdrawiam
>>>>>> Szymon K. Janc
>>>>>
>>>>>
>>>> BR,
>>>> Andrzej
>>>
>>>
>
Re: BLE HCI support on NRF52DK
Posted by will sanfilippo <wi...@runtime.io>.
Hello Alan:
I may be reading this incorrectly or mistaken, but the host does not need to see the NOOP from the controller. The controller needs to be ready to receive the HCI Reset command from the host. At least, that is my understanding after the email exchange with Andrzej. I would have thought there would be a retry mechanism as well but that is not the case. So all you need to insure is that the controller is up and running before the host sends the HCI Reset.
Am I making sense? :-)
> On Feb 10, 2017, at 12:39 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>
> Hi Guys,
>
> The BLE hardware I have to work with does not provide hardware flow control with RTS/CTS. The CTS line is grounded and the RTS is left not connected. In any case the BLE module is on its own board that is internally connected to the Linux host processor. It is probably safe to assume that in this situation the Nordic chip will be powered up and expecting the Host to be ready to receive any messages sent via the BLE HCI before the Linux BlueZ stack is initialized. Obviously I could arbitrarily delay the NOOP message timing so that the two ends can be in sync, but to not have a timeout mechanism on the HCI protocol would seem to me to be a guarantee that a deadlock condition would occur. Another possibility is that perhaps I can find a way to keep the BLE hardware in a reset state until the Host is initialized by driving the RESET signal with a GPIO line.
>
> ALan
>
> -----Original Message-----
> From: will sanfilippo [mailto:wills@runtime.io]
> Sent: Monday, February 06, 2017 5:55 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: BLE HCI support on NRF52DK
>
> Ah ok; that is quite interesting. I did not realize that was the case and I was thinking of an external board that was powered off (and not quite trusting the state of the flow control lines).
>
> Then really the only thing we need to make sure on our end is that when UART is brought up and the flow control line is properly de-asserted the nimble stack sees any commands that were sent by the host (in the case where the UART comes up first, then the rest of the nimble stack).
>
> Will
>
>> On Feb 6, 2017, at 10:27 AM, Andrzej Kaczmarek <an...@codecoup.pl> wrote:
>>
>> Hi Will,
>>
>> I could not find any timeout defined for HCI commands so the problem
>> here would be when host should timeout and resend HCI Reset. I think
>> we should just assume that hw is designed properly and flow control
>> lines are either pulled or driven externally all the time so this is not overly complicated.
>> Actually, if you check Vol 4 Part A Section 1, it says that objective
>> of UART TL is to have both ends on the same PCB and communication is
>> free form errors, so there is no case that we suddenly have controller
>> disconnected - I'd say above assumption is reasonable :-)
>>
>> BR,
>> Andrzej
>>
>>
>>
>> On Sat, Feb 4, 2017 at 12:25 AM, will sanfilippo <wi...@runtime.io> wrote:
>>
>>> Hi Andrzej
>>>
>>> Thanks for pointing me to Vol 2 Part E, Section 4.4. I was recalling
>>> a section of the spec that talked about this but could not find it
>>> when I sent this email. Thus, I completely agree that the controller
>>> sending a NOOP does not in any way indicate that it reset. It is fine
>>> if the controller does send a NOOP, but the host cannot use that as
>>> an indication that the controller reset. That does make things a bit
>>> tricky though as you mention, but hopefully if something is really
>>> badly out of sync the host will figure it out and reset the controller.
>>>
>>> I was also thinking of the following scenario which I should have
>>> explained a bit better. If the controller is powered off, it is not
>>> driving the flow control line so I am not sure what would happen HW
>>> wise in this case. It could be that the flow control line is
>>> floating, and therefore the host could see it in various states.
>>> Therefore, I would suspect that when a host issues a HCI Reset and
>>> does not get a response for some amount of time, it just keeps issuing the HCI Reset until it gets a response.
>>>
>>> Given that a controller can send a NOOP on power up, I cant see how
>>> we can guarantee that the following will NOT happen:
>>>
>>> * Host sends HCI Reset
>>> * Controller sends NOOP
>>> * Controller sends Command Complete w/Reset opcode
>>>
>>> I can also see this happening:
>>>
>>> * Host sends HCI Reset
>>> * Controller sends NOOP
>>> * Nothing else happens
>>>
>>> I certainly agree that once the controller actively takes control of
>>> the flow control line it should honor the HCI Reset although I still
>>> see the possibility of the two scenarios described above happening.
>>>
>>> Regarding HW Error: that is something we can do in the controller as
>>> we can look at the reason why the device reset and send a HW error event.
>>>
>>>
>>>> On Feb 3, 2017, at 12:12 PM, Andrzej Kaczmarek <
>>> andrzej.kaczmarek@codecoup.pl> wrote:
>>>>
>>>> Hi Will,
>>>>
>>>> On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <wi...@runtime.io>
>>> wrote:
>>>>
>>>>> I might be getting a bit confused here so hopefully I am making
>>>>> some sense. I seem to recall some discussion around this in the
>>>>> past but I
>>> cant
>>>>> recall :-) Anyway...
>>>>>
>>>>> It is my understanding that the first thing a controller should do
>>>>> when
>>> it
>>>>> powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6 Part
>>>>> D Section 2 you can see a message sequence chart that shows this.
>>>>> It
>>> sounds
>>>>> like folks think MyNewt is different than other controllers in this
>>>>> respect. If so, we can change that behavior, but it makes sense to
>>>>> me
>>> to do
>>>>> this, as it will inform the host that the controller has powered up.
>>>>>
>>>>
>>>> The section you quote is only informative (see section 1.1 of the
>>>> same
>>>> part) and the diagram is only one of possibilities. The actual
>>> requirement
>>>> is in Vol 2, Part E, Section 4.4 which states that after power up
>>>> host is allowed to send up to 1 outstanding command so 1 credit is assumed here.
>>>> Also controller does not need to send noop, but it is also not an
>>>> error
>>> to
>>>> do so.
>>>>
>>>> Of course, there is a chicken and egg problem here. If the
>>>> controller is
>>>>> not powered up and the host sends a HCI Reset, the host is
>>>>> obviously not going to get a response. I am also not sure one can
>>>>> trust the flow
>>> control
>>>>> lines if the board is not powered up but one would hope that
>>>>> RTS/CTS are pulled the proper way if the controller is not powered.
>>>>>
>>>>
>>>> I guess host can assume that CTS/RTS lines work properly, otherwise
>>>> there is no way to detect when controller is ready to receive something (i.e.
>>> is
>>>> attached).
>>>>
>>>>
>>>>> Certainly, an interesting issue with the MyNewt HCI firmware would
>>>>> be
>>> the
>>>>> order in which the UART gets initialized and when the LL is
>>> initialized. In
>>>>> the end, I dont think it should really matter, as the host should
>>>>> have
>>> to
>>>>> deal with the controller not being ready to receive the HCI Reset.
>>>>>
>>>>
>>>> My understanding of spec section I mentioned is that controller
>>>> should be always ready to receive HCI Reset after power up. If it is
>>>> not, then flow control on transport layer should not be enabled.
>>>>
>>>>
>>>>> Here are the basic scenarios and what I would expect:
>>>>>
>>>>> 1. Controller powers up first and host is not powered or not ready
>>>>> * Controller issues NOOP but host does not see it.
>>>>> * Host wakes up and sends HCI Reset.
>>>>> * Host gets Command Complete (with proper opcode) and all is well
>>>>>
>>>>
>>>> Agree.
>>>>
>>>> 2. Host powers up first and controller powers up some time later
>>>>> * Host sends HCI Reset but gets no response.
>>>>> * Host sits in a loop, sending HCI Resets periodically.
>>>>> * If Host gets a NOOP, it knows that the controller has powered up.
>>>>> In this case, the host should issue HCI Reset and should get a
>>>>> Command Complete.
>>>>> * If the Host gets a Command Complete with proper opcode, all is well.
>>>>>
>>>>
>>>> I think this is the case where host actually does not send HCI Reset
>>> since
>>>> controller is not ready and RTS/CTS flow control is not enabled. If
>>>> controller enabled hardware flow control, it should receive and
>>>> process anything according to spec.
>>>>
>>>> 3. Host and Controller were communicating fine and Controller powers
>>> off/on
>>>>> * Host will see an “unsolicited” NOOP and should realize that the
>>>>> Controller has just reset. Host should perform appropriate actions.
>>>>>
>>>>
>>>> No, because controller can send noop at any time and it does not
>>>> mean a reset - see section I mentioned earlier. But to be honest I
>>>> don't really know how this should be handled properly. Probably the
>>>> things would go so wrong (due to states on both sides which are out
>>>> of sync) that either controller would eventually issue a hardware
>>>> error event or host would request controller since it cannot talk to
>>>> it anymore. But it's up to implementations which one will detect this first, I guess.
>>>>
>>>> 4. Host and Controller were communicating fine and Host powers
>>>> off/on
>>>>> * Controller sees a HCI Reset and performs appropriate actions.
>>>>>
>>>>
>>>> Agree.
>>>>
>>>>
>>>>> An interesting case is one where the controller resets for a known
>>> reason
>>>>> (i.e. firmware asserts). Should the controller send a HW Error
>>>>> event in this case? Some folks I talked to thought it should;
>>>>> others were not
>>> sure.
>>>>> The nimble firmware does not do that; currently the only reason a
>>>>> HW
>>> error
>>>>> event is issued is when synchronization is lost between the host
>>>>> and controller (See Vol 4 Part A Section Part 4 Error Recovery).
>>>>>
>>>>
>>>> I'd say it should - this event is for "some type of hardware
>>>> failure" as spec says, so it could well be an assert in firmware.
>>>>
>>>>
>>>>>
>>>>> Comments/Thoughts?
>>>>>
>>>>>
>>>>>> On Feb 3, 2017, at 4:07 AM, Szymon Janc <sz...@codecoup.pl>
>>> wrote:
>>>>>>
>>>>>> Hi Alan,
>>>>>>
>>>>>> On 3 February 2017 at 07:16, Alan Graves
>>>>>> <ag...@deltacontrols.com>
>>>>> wrote:
>>>>>>> Hi Szymon,
>>>>>>>
>>>>>>> I don't think waiting for the NOP before attaching made any
>>> difference,
>>>>> but now I can't remember so I'll have to check that. In any case
>>>>> here is the btmon output I got during my initial testing:
>>>>>>>
>>>>>>> $ sudo btmon
>>>>>>> [sudo] password for alan:
>>>>>>> Bluetooth monitor ver 5.41
>>>>>>> = Note: Linux version 4.8.0-34-generic (x86_64)
>>>>> 0.977791
>>>>>>> = Note: Bluetooth subsystem version 2.21
>>>>> 0.977792
>>>>>>> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0]
>>>>> 121.060311
>>>>>>> = Open Index: 00:00:00:00:00:00 [hci0]
>>>>> 121.066478
>>>>>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0]
>>>>> 121.070996
>>>>>>> = bluetoothd: Bluetooth daemon 5.41
>>>>> 121.092783
>>>>>>> = bluetoothd: Starting SDP server
>>>>> 121.104354
>>>>>>> = bluetoothd: Bluetooth management interface 1.13 initialized
>>>>> 121.112600
>>>>>>>> HCI Event: Command Complete (0x0e) plen 3 [hci0]
>>>>> 126.168513
>>>>>>> NOP (0x00|0x0000) ncmd 1
>>>>>>> = Close Index: 00:00:00:00:00:00 [hci0]
>>>>> 131.246188
>>>>>>>
>>>>>>
>>>>>> I suspect that HCI Reset is simply ignored before NOP is sent and
>>>>>> Linux will not try sending another command before getting Command
>>>>>> Status for it.
>>>>>> And that will never happen since command was ignored ie. Zephyr
>>>>>> has special config option when used with Mynewt based BT firmware
>>>>>> to handle this exact situation - send HCI Reset only after initial
>>>>>> NOP was received.
>>>>>> Linux on the other hand assumes that once device is attached it is
>>>>>> ready to receive initial HCI Reset.
>>>>>>
>>>>>>> ALan
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>>>>>>> Sent: Thursday, February 02, 2017 12:18 PM
>>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>>
>>>>>>> Hi Alan,
>>>>>>>
>>>>>>> On 2 February 2017 at 19:16, Alan Graves
>>>>>>> <ag...@deltacontrols.com>
>>>>> 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...
>>>>>>>
>>>>>>> btattach has -N, --noflowctl option for disabling flow control.
>>>>>>> Yet,
>>>>> it is not recommended for H4 protocol (actually, H4 spec requires
>>>>> flow control to be enabled).
>>>>>>>
>>>>>>> But I'd first check if simply waiting for few seconds before
>>>>>>> calling
>>>>> btattach fix the problem (ie so that Linux sends initial HCI Reset
>>>>> after NOP event was emitted).
>>>>>>>
>>>>>>>> ALan
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher Collins [mailto:ccollins@apache.org]
>>>>>>>> Sent: Wednesday, February 01, 2017 4:00 PM
>>>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>>>
>>>>>>>> Hi Alan,
>>>>>>>>
>>>>>>>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I've spent some time trying to get nRF52832 DK running the 'blehci'
>>>>> code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>>>>>>>>
>>>>>>>> I just ran the latest blehci from develop with the following setup:
>>>>>>>>
>>>>>>>> * BlueZ 5.39
>>>>>>>> * Ubuntu 16.04 (Xenial)
>>>>>>>> * nRF52832 DK
>>>>>>>>
>>>>>>>> I didn't notice any issues when I tried. I'm afraid I don't see
>>>>> anything wrong with the steps you follows. Maybe one of the
>>>>> following hints will help:
>>>>>>>>
>>>>>>>> * Make sure the two flow control pins (RTS / CTS) are attached.
>>>>>>>>
>>>>>>>> * Try killing btattach and restarting it. When you do this, you
>>> should
>>>>>>>> see BlueZ send the host init sequence in btmon (starting with a
>>>>>>>> Reset command).
>>>>>>>>
>>>>>>>> The btattach step is required because the BlueZ host doesn't
>>>>>>>> seem to
>>>>> interpret the no-op event as a controller reset. You have to
>>>>> explicitly tell the host to reset the controller.
>>>>>>>>
>>>>>>>> Hopefully this gets you a little closer to a solution. If
>>>>>>>> you're
>>>>> still seeing the same issue, just let me know and we can debug it
>>> further.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> pozdrawiam
>>>>>>> Szymon K. Janc
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> pozdrawiam
>>>>>> Szymon K. Janc
>>>>>
>>>>>
>>>> BR,
>>>> Andrzej
>>>
>>>
>
RE: BLE HCI support on NRF52DK
Posted by Alan Graves <ag...@deltacontrols.com>.
Hi Guys,
The BLE hardware I have to work with does not provide hardware flow control with RTS/CTS. The CTS line is grounded and the RTS is left not connected. In any case the BLE module is on its own board that is internally connected to the Linux host processor. It is probably safe to assume that in this situation the Nordic chip will be powered up and expecting the Host to be ready to receive any messages sent via the BLE HCI before the Linux BlueZ stack is initialized. Obviously I could arbitrarily delay the NOOP message timing so that the two ends can be in sync, but to not have a timeout mechanism on the HCI protocol would seem to me to be a guarantee that a deadlock condition would occur. Another possibility is that perhaps I can find a way to keep the BLE hardware in a reset state until the Host is initialized by driving the RESET signal with a GPIO line.
ALan
-----Original Message-----
From: will sanfilippo [mailto:wills@runtime.io]
Sent: Monday, February 06, 2017 5:55 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Ah ok; that is quite interesting. I did not realize that was the case and I was thinking of an external board that was powered off (and not quite trusting the state of the flow control lines).
Then really the only thing we need to make sure on our end is that when UART is brought up and the flow control line is properly de-asserted the nimble stack sees any commands that were sent by the host (in the case where the UART comes up first, then the rest of the nimble stack).
Will
> On Feb 6, 2017, at 10:27 AM, Andrzej Kaczmarek <an...@codecoup.pl> wrote:
>
> Hi Will,
>
> I could not find any timeout defined for HCI commands so the problem
> here would be when host should timeout and resend HCI Reset. I think
> we should just assume that hw is designed properly and flow control
> lines are either pulled or driven externally all the time so this is not overly complicated.
> Actually, if you check Vol 4 Part A Section 1, it says that objective
> of UART TL is to have both ends on the same PCB and communication is
> free form errors, so there is no case that we suddenly have controller
> disconnected - I'd say above assumption is reasonable :-)
>
> BR,
> Andrzej
>
>
>
> On Sat, Feb 4, 2017 at 12:25 AM, will sanfilippo <wi...@runtime.io> wrote:
>
>> Hi Andrzej
>>
>> Thanks for pointing me to Vol 2 Part E, Section 4.4. I was recalling
>> a section of the spec that talked about this but could not find it
>> when I sent this email. Thus, I completely agree that the controller
>> sending a NOOP does not in any way indicate that it reset. It is fine
>> if the controller does send a NOOP, but the host cannot use that as
>> an indication that the controller reset. That does make things a bit
>> tricky though as you mention, but hopefully if something is really
>> badly out of sync the host will figure it out and reset the controller.
>>
>> I was also thinking of the following scenario which I should have
>> explained a bit better. If the controller is powered off, it is not
>> driving the flow control line so I am not sure what would happen HW
>> wise in this case. It could be that the flow control line is
>> floating, and therefore the host could see it in various states.
>> Therefore, I would suspect that when a host issues a HCI Reset and
>> does not get a response for some amount of time, it just keeps issuing the HCI Reset until it gets a response.
>>
>> Given that a controller can send a NOOP on power up, I cant see how
>> we can guarantee that the following will NOT happen:
>>
>> * Host sends HCI Reset
>> * Controller sends NOOP
>> * Controller sends Command Complete w/Reset opcode
>>
>> I can also see this happening:
>>
>> * Host sends HCI Reset
>> * Controller sends NOOP
>> * Nothing else happens
>>
>> I certainly agree that once the controller actively takes control of
>> the flow control line it should honor the HCI Reset although I still
>> see the possibility of the two scenarios described above happening.
>>
>> Regarding HW Error: that is something we can do in the controller as
>> we can look at the reason why the device reset and send a HW error event.
>>
>>
>>> On Feb 3, 2017, at 12:12 PM, Andrzej Kaczmarek <
>> andrzej.kaczmarek@codecoup.pl> wrote:
>>>
>>> Hi Will,
>>>
>>> On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <wi...@runtime.io>
>> wrote:
>>>
>>>> I might be getting a bit confused here so hopefully I am making
>>>> some sense. I seem to recall some discussion around this in the
>>>> past but I
>> cant
>>>> recall :-) Anyway...
>>>>
>>>> It is my understanding that the first thing a controller should do
>>>> when
>> it
>>>> powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6 Part
>>>> D Section 2 you can see a message sequence chart that shows this.
>>>> It
>> sounds
>>>> like folks think MyNewt is different than other controllers in this
>>>> respect. If so, we can change that behavior, but it makes sense to
>>>> me
>> to do
>>>> this, as it will inform the host that the controller has powered up.
>>>>
>>>
>>> The section you quote is only informative (see section 1.1 of the
>>> same
>>> part) and the diagram is only one of possibilities. The actual
>> requirement
>>> is in Vol 2, Part E, Section 4.4 which states that after power up
>>> host is allowed to send up to 1 outstanding command so 1 credit is assumed here.
>>> Also controller does not need to send noop, but it is also not an
>>> error
>> to
>>> do so.
>>>
>>> Of course, there is a chicken and egg problem here. If the
>>> controller is
>>>> not powered up and the host sends a HCI Reset, the host is
>>>> obviously not going to get a response. I am also not sure one can
>>>> trust the flow
>> control
>>>> lines if the board is not powered up but one would hope that
>>>> RTS/CTS are pulled the proper way if the controller is not powered.
>>>>
>>>
>>> I guess host can assume that CTS/RTS lines work properly, otherwise
>>> there is no way to detect when controller is ready to receive something (i.e.
>> is
>>> attached).
>>>
>>>
>>>> Certainly, an interesting issue with the MyNewt HCI firmware would
>>>> be
>> the
>>>> order in which the UART gets initialized and when the LL is
>> initialized. In
>>>> the end, I dont think it should really matter, as the host should
>>>> have
>> to
>>>> deal with the controller not being ready to receive the HCI Reset.
>>>>
>>>
>>> My understanding of spec section I mentioned is that controller
>>> should be always ready to receive HCI Reset after power up. If it is
>>> not, then flow control on transport layer should not be enabled.
>>>
>>>
>>>> Here are the basic scenarios and what I would expect:
>>>>
>>>> 1. Controller powers up first and host is not powered or not ready
>>>> * Controller issues NOOP but host does not see it.
>>>> * Host wakes up and sends HCI Reset.
>>>> * Host gets Command Complete (with proper opcode) and all is well
>>>>
>>>
>>> Agree.
>>>
>>> 2. Host powers up first and controller powers up some time later
>>>> * Host sends HCI Reset but gets no response.
>>>> * Host sits in a loop, sending HCI Resets periodically.
>>>> * If Host gets a NOOP, it knows that the controller has powered up.
>>>> In this case, the host should issue HCI Reset and should get a
>>>> Command Complete.
>>>> * If the Host gets a Command Complete with proper opcode, all is well.
>>>>
>>>
>>> I think this is the case where host actually does not send HCI Reset
>> since
>>> controller is not ready and RTS/CTS flow control is not enabled. If
>>> controller enabled hardware flow control, it should receive and
>>> process anything according to spec.
>>>
>>> 3. Host and Controller were communicating fine and Controller powers
>> off/on
>>>> * Host will see an “unsolicited” NOOP and should realize that the
>>>> Controller has just reset. Host should perform appropriate actions.
>>>>
>>>
>>> No, because controller can send noop at any time and it does not
>>> mean a reset - see section I mentioned earlier. But to be honest I
>>> don't really know how this should be handled properly. Probably the
>>> things would go so wrong (due to states on both sides which are out
>>> of sync) that either controller would eventually issue a hardware
>>> error event or host would request controller since it cannot talk to
>>> it anymore. But it's up to implementations which one will detect this first, I guess.
>>>
>>> 4. Host and Controller were communicating fine and Host powers
>>> off/on
>>>> * Controller sees a HCI Reset and performs appropriate actions.
>>>>
>>>
>>> Agree.
>>>
>>>
>>>> An interesting case is one where the controller resets for a known
>> reason
>>>> (i.e. firmware asserts). Should the controller send a HW Error
>>>> event in this case? Some folks I talked to thought it should;
>>>> others were not
>> sure.
>>>> The nimble firmware does not do that; currently the only reason a
>>>> HW
>> error
>>>> event is issued is when synchronization is lost between the host
>>>> and controller (See Vol 4 Part A Section Part 4 Error Recovery).
>>>>
>>>
>>> I'd say it should - this event is for "some type of hardware
>>> failure" as spec says, so it could well be an assert in firmware.
>>>
>>>
>>>>
>>>> Comments/Thoughts?
>>>>
>>>>
>>>>> On Feb 3, 2017, at 4:07 AM, Szymon Janc <sz...@codecoup.pl>
>> wrote:
>>>>>
>>>>> Hi Alan,
>>>>>
>>>>> On 3 February 2017 at 07:16, Alan Graves
>>>>> <ag...@deltacontrols.com>
>>>> wrote:
>>>>>> Hi Szymon,
>>>>>>
>>>>>> I don't think waiting for the NOP before attaching made any
>> difference,
>>>> but now I can't remember so I'll have to check that. In any case
>>>> here is the btmon output I got during my initial testing:
>>>>>>
>>>>>> $ sudo btmon
>>>>>> [sudo] password for alan:
>>>>>> Bluetooth monitor ver 5.41
>>>>>> = Note: Linux version 4.8.0-34-generic (x86_64)
>>>> 0.977791
>>>>>> = Note: Bluetooth subsystem version 2.21
>>>> 0.977792
>>>>>> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0]
>>>> 121.060311
>>>>>> = Open Index: 00:00:00:00:00:00 [hci0]
>>>> 121.066478
>>>>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0]
>>>> 121.070996
>>>>>> = bluetoothd: Bluetooth daemon 5.41
>>>> 121.092783
>>>>>> = bluetoothd: Starting SDP server
>>>> 121.104354
>>>>>> = bluetoothd: Bluetooth management interface 1.13 initialized
>>>> 121.112600
>>>>>>> HCI Event: Command Complete (0x0e) plen 3 [hci0]
>>>> 126.168513
>>>>>> NOP (0x00|0x0000) ncmd 1
>>>>>> = Close Index: 00:00:00:00:00:00 [hci0]
>>>> 131.246188
>>>>>>
>>>>>
>>>>> I suspect that HCI Reset is simply ignored before NOP is sent and
>>>>> Linux will not try sending another command before getting Command
>>>>> Status for it.
>>>>> And that will never happen since command was ignored ie. Zephyr
>>>>> has special config option when used with Mynewt based BT firmware
>>>>> to handle this exact situation - send HCI Reset only after initial
>>>>> NOP was received.
>>>>> Linux on the other hand assumes that once device is attached it is
>>>>> ready to receive initial HCI Reset.
>>>>>
>>>>>> ALan
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>>>>>> Sent: Thursday, February 02, 2017 12:18 PM
>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>
>>>>>> Hi Alan,
>>>>>>
>>>>>> On 2 February 2017 at 19:16, Alan Graves
>>>>>> <ag...@deltacontrols.com>
>>>> 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...
>>>>>>
>>>>>> btattach has -N, --noflowctl option for disabling flow control.
>>>>>> Yet,
>>>> it is not recommended for H4 protocol (actually, H4 spec requires
>>>> flow control to be enabled).
>>>>>>
>>>>>> But I'd first check if simply waiting for few seconds before
>>>>>> calling
>>>> btattach fix the problem (ie so that Linux sends initial HCI Reset
>>>> after NOP event was emitted).
>>>>>>
>>>>>>> ALan
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christopher Collins [mailto:ccollins@apache.org]
>>>>>>> Sent: Wednesday, February 01, 2017 4:00 PM
>>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>>
>>>>>>> Hi Alan,
>>>>>>>
>>>>>>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I've spent some time trying to get nRF52832 DK running the 'blehci'
>>>> code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>>>>>>>
>>>>>>> I just ran the latest blehci from develop with the following setup:
>>>>>>>
>>>>>>> * BlueZ 5.39
>>>>>>> * Ubuntu 16.04 (Xenial)
>>>>>>> * nRF52832 DK
>>>>>>>
>>>>>>> I didn't notice any issues when I tried. I'm afraid I don't see
>>>> anything wrong with the steps you follows. Maybe one of the
>>>> following hints will help:
>>>>>>>
>>>>>>> * Make sure the two flow control pins (RTS / CTS) are attached.
>>>>>>>
>>>>>>> * Try killing btattach and restarting it. When you do this, you
>> should
>>>>>>> see BlueZ send the host init sequence in btmon (starting with a
>>>>>>> Reset command).
>>>>>>>
>>>>>>> The btattach step is required because the BlueZ host doesn't
>>>>>>> seem to
>>>> interpret the no-op event as a controller reset. You have to
>>>> explicitly tell the host to reset the controller.
>>>>>>>
>>>>>>> Hopefully this gets you a little closer to a solution. If
>>>>>>> you're
>>>> still seeing the same issue, just let me know and we can debug it
>> further.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> pozdrawiam
>>>>>> Szymon K. Janc
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> pozdrawiam
>>>>> Szymon K. Janc
>>>>
>>>>
>>> BR,
>>> Andrzej
>>
>>
Re: BLE HCI support on NRF52DK
Posted by will sanfilippo <wi...@runtime.io>.
Ah ok; that is quite interesting. I did not realize that was the case and I was thinking of an external board that was powered off (and not quite trusting the state of the flow control lines).
Then really the only thing we need to make sure on our end is that when UART is brought up and the flow control line is properly de-asserted the nimble stack sees any commands that were sent by the host (in the case where the UART comes up first, then the rest of the nimble stack).
Will
> On Feb 6, 2017, at 10:27 AM, Andrzej Kaczmarek <an...@codecoup.pl> wrote:
>
> Hi Will,
>
> I could not find any timeout defined for HCI commands so the problem here
> would be when host should timeout and resend HCI Reset. I think we should
> just assume that hw is designed properly and flow control lines are either
> pulled or driven externally all the time so this is not overly complicated.
> Actually, if you check Vol 4 Part A Section 1, it says that objective of
> UART TL is to have both ends on the same PCB and communication is free form
> errors, so there is no case that we suddenly have controller disconnected -
> I'd say above assumption is reasonable :-)
>
> BR,
> Andrzej
>
>
>
> On Sat, Feb 4, 2017 at 12:25 AM, will sanfilippo <wi...@runtime.io> wrote:
>
>> Hi Andrzej
>>
>> Thanks for pointing me to Vol 2 Part E, Section 4.4. I was recalling a
>> section of the spec that talked about this but could not find it when I
>> sent this email. Thus, I completely agree that the controller sending a
>> NOOP does not in any way indicate that it reset. It is fine if the
>> controller does send a NOOP, but the host cannot use that as an indication
>> that the controller reset. That does make things a bit tricky though as you
>> mention, but hopefully if something is really badly out of sync the host
>> will figure it out and reset the controller.
>>
>> I was also thinking of the following scenario which I should have
>> explained a bit better. If the controller is powered off, it is not driving
>> the flow control line so I am not sure what would happen HW wise in this
>> case. It could be that the flow control line is floating, and therefore the
>> host could see it in various states. Therefore, I would suspect that when a
>> host issues a HCI Reset and does not get a response for some amount of
>> time, it just keeps issuing the HCI Reset until it gets a response.
>>
>> Given that a controller can send a NOOP on power up, I cant see how we can
>> guarantee that the following will NOT happen:
>>
>> * Host sends HCI Reset
>> * Controller sends NOOP
>> * Controller sends Command Complete w/Reset opcode
>>
>> I can also see this happening:
>>
>> * Host sends HCI Reset
>> * Controller sends NOOP
>> * Nothing else happens
>>
>> I certainly agree that once the controller actively takes control of the
>> flow control line it should honor the HCI Reset although I still see the
>> possibility of the two scenarios described above happening.
>>
>> Regarding HW Error: that is something we can do in the controller as we
>> can look at the reason why the device reset and send a HW error event.
>>
>>
>>> On Feb 3, 2017, at 12:12 PM, Andrzej Kaczmarek <
>> andrzej.kaczmarek@codecoup.pl> wrote:
>>>
>>> Hi Will,
>>>
>>> On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <wi...@runtime.io>
>> wrote:
>>>
>>>> I might be getting a bit confused here so hopefully I am making some
>>>> sense. I seem to recall some discussion around this in the past but I
>> cant
>>>> recall :-) Anyway...
>>>>
>>>> It is my understanding that the first thing a controller should do when
>> it
>>>> powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6 Part D
>>>> Section 2 you can see a message sequence chart that shows this. It
>> sounds
>>>> like folks think MyNewt is different than other controllers in this
>>>> respect. If so, we can change that behavior, but it makes sense to me
>> to do
>>>> this, as it will inform the host that the controller has powered up.
>>>>
>>>
>>> The section you quote is only informative (see section 1.1 of the same
>>> part) and the diagram is only one of possibilities. The actual
>> requirement
>>> is in Vol 2, Part E, Section 4.4 which states that after power up host is
>>> allowed to send up to 1 outstanding command so 1 credit is assumed here.
>>> Also controller does not need to send noop, but it is also not an error
>> to
>>> do so.
>>>
>>> Of course, there is a chicken and egg problem here. If the controller is
>>>> not powered up and the host sends a HCI Reset, the host is obviously not
>>>> going to get a response. I am also not sure one can trust the flow
>> control
>>>> lines if the board is not powered up but one would hope that RTS/CTS are
>>>> pulled the proper way if the controller is not powered.
>>>>
>>>
>>> I guess host can assume that CTS/RTS lines work properly, otherwise there
>>> is no way to detect when controller is ready to receive something (i.e.
>> is
>>> attached).
>>>
>>>
>>>> Certainly, an interesting issue with the MyNewt HCI firmware would be
>> the
>>>> order in which the UART gets initialized and when the LL is
>> initialized. In
>>>> the end, I dont think it should really matter, as the host should have
>> to
>>>> deal with the controller not being ready to receive the HCI Reset.
>>>>
>>>
>>> My understanding of spec section I mentioned is that controller should be
>>> always ready to receive HCI Reset after power up. If it is not, then flow
>>> control on transport layer should not be enabled.
>>>
>>>
>>>> Here are the basic scenarios and what I would expect:
>>>>
>>>> 1. Controller powers up first and host is not powered or not ready
>>>> * Controller issues NOOP but host does not see it.
>>>> * Host wakes up and sends HCI Reset.
>>>> * Host gets Command Complete (with proper opcode) and all is well
>>>>
>>>
>>> Agree.
>>>
>>> 2. Host powers up first and controller powers up some time later
>>>> * Host sends HCI Reset but gets no response.
>>>> * Host sits in a loop, sending HCI Resets periodically.
>>>> * If Host gets a NOOP, it knows that the controller has powered up. In
>>>> this case, the host should issue HCI Reset and should get a Command
>>>> Complete.
>>>> * If the Host gets a Command Complete with proper opcode, all is well.
>>>>
>>>
>>> I think this is the case where host actually does not send HCI Reset
>> since
>>> controller is not ready and RTS/CTS flow control is not enabled. If
>>> controller enabled hardware flow control, it should receive and process
>>> anything according to spec.
>>>
>>> 3. Host and Controller were communicating fine and Controller powers
>> off/on
>>>> * Host will see an “unsolicited” NOOP and should realize that the
>>>> Controller has just reset. Host should perform appropriate actions.
>>>>
>>>
>>> No, because controller can send noop at any time and it does not mean a
>>> reset - see section I mentioned earlier. But to be honest I don't really
>>> know how this should be handled properly. Probably the things would go so
>>> wrong (due to states on both sides which are out of sync) that either
>>> controller would eventually issue a hardware error event or host would
>>> request controller since it cannot talk to it anymore. But it's up to
>>> implementations which one will detect this first, I guess.
>>>
>>> 4. Host and Controller were communicating fine and Host powers off/on
>>>> * Controller sees a HCI Reset and performs appropriate actions.
>>>>
>>>
>>> Agree.
>>>
>>>
>>>> An interesting case is one where the controller resets for a known
>> reason
>>>> (i.e. firmware asserts). Should the controller send a HW Error event in
>>>> this case? Some folks I talked to thought it should; others were not
>> sure.
>>>> The nimble firmware does not do that; currently the only reason a HW
>> error
>>>> event is issued is when synchronization is lost between the host and
>>>> controller (See Vol 4 Part A Section Part 4 Error Recovery).
>>>>
>>>
>>> I'd say it should - this event is for "some type of hardware failure" as
>>> spec says, so it could well be an assert in firmware.
>>>
>>>
>>>>
>>>> Comments/Thoughts?
>>>>
>>>>
>>>>> On Feb 3, 2017, at 4:07 AM, Szymon Janc <sz...@codecoup.pl>
>> wrote:
>>>>>
>>>>> Hi Alan,
>>>>>
>>>>> On 3 February 2017 at 07:16, Alan Graves <ag...@deltacontrols.com>
>>>> wrote:
>>>>>> Hi Szymon,
>>>>>>
>>>>>> I don't think waiting for the NOP before attaching made any
>> difference,
>>>> but now I can't remember so I'll have to check that. In any case here is
>>>> the btmon output I got during my initial testing:
>>>>>>
>>>>>> $ sudo btmon
>>>>>> [sudo] password for alan:
>>>>>> Bluetooth monitor ver 5.41
>>>>>> = Note: Linux version 4.8.0-34-generic (x86_64)
>>>> 0.977791
>>>>>> = Note: Bluetooth subsystem version 2.21
>>>> 0.977792
>>>>>> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0]
>>>> 121.060311
>>>>>> = Open Index: 00:00:00:00:00:00 [hci0]
>>>> 121.066478
>>>>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0]
>>>> 121.070996
>>>>>> = bluetoothd: Bluetooth daemon 5.41
>>>> 121.092783
>>>>>> = bluetoothd: Starting SDP server
>>>> 121.104354
>>>>>> = bluetoothd: Bluetooth management interface 1.13 initialized
>>>> 121.112600
>>>>>>> HCI Event: Command Complete (0x0e) plen 3 [hci0]
>>>> 126.168513
>>>>>> NOP (0x00|0x0000) ncmd 1
>>>>>> = Close Index: 00:00:00:00:00:00 [hci0]
>>>> 131.246188
>>>>>>
>>>>>
>>>>> I suspect that HCI Reset is simply ignored before NOP is sent and
>>>>> Linux will not try sending another command before getting Command
>>>>> Status for it.
>>>>> And that will never happen since command was ignored ie. Zephyr has
>>>>> special config option when used with Mynewt based BT firmware to
>>>>> handle this
>>>>> exact situation - send HCI Reset only after initial NOP was received.
>>>>> Linux on the other hand assumes that once device is attached it is
>>>>> ready to
>>>>> receive initial HCI Reset.
>>>>>
>>>>>> ALan
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>>>>>> Sent: Thursday, February 02, 2017 12:18 PM
>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>
>>>>>> Hi Alan,
>>>>>>
>>>>>> On 2 February 2017 at 19:16, Alan Graves <ag...@deltacontrols.com>
>>>> 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...
>>>>>>
>>>>>> btattach has -N, --noflowctl option for disabling flow control. Yet,
>>>> it is not recommended for H4 protocol (actually, H4 spec requires flow
>>>> control to be enabled).
>>>>>>
>>>>>> But I'd first check if simply waiting for few seconds before calling
>>>> btattach fix the problem (ie so that Linux sends initial HCI Reset after
>>>> NOP event was emitted).
>>>>>>
>>>>>>> ALan
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christopher Collins [mailto:ccollins@apache.org]
>>>>>>> Sent: Wednesday, February 01, 2017 4:00 PM
>>>>>>> To: dev@mynewt.incubator.apache.org
>>>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>>>
>>>>>>> Hi Alan,
>>>>>>>
>>>>>>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I've spent some time trying to get nRF52832 DK running the 'blehci'
>>>> code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>>>>>>>
>>>>>>> I just ran the latest blehci from develop with the following setup:
>>>>>>>
>>>>>>> * BlueZ 5.39
>>>>>>> * Ubuntu 16.04 (Xenial)
>>>>>>> * nRF52832 DK
>>>>>>>
>>>>>>> I didn't notice any issues when I tried. I'm afraid I don't see
>>>> anything wrong with the steps you follows. Maybe one of the following
>>>> hints will help:
>>>>>>>
>>>>>>> * Make sure the two flow control pins (RTS / CTS) are attached.
>>>>>>>
>>>>>>> * Try killing btattach and restarting it. When you do this, you
>> should
>>>>>>> see BlueZ send the host init sequence in btmon (starting with a Reset
>>>>>>> command).
>>>>>>>
>>>>>>> The btattach step is required because the BlueZ host doesn't seem to
>>>> interpret the no-op event as a controller reset. You have to explicitly
>>>> tell the host to reset the controller.
>>>>>>>
>>>>>>> Hopefully this gets you a little closer to a solution. If you're
>>>> still seeing the same issue, just let me know and we can debug it
>> further.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> pozdrawiam
>>>>>> Szymon K. Janc
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> pozdrawiam
>>>>> Szymon K. Janc
>>>>
>>>>
>>> BR,
>>> Andrzej
>>
>>
Re: BLE HCI support on NRF52DK
Posted by Andrzej Kaczmarek <an...@codecoup.pl>.
Hi Will,
I could not find any timeout defined for HCI commands so the problem here
would be when host should timeout and resend HCI Reset. I think we should
just assume that hw is designed properly and flow control lines are either
pulled or driven externally all the time so this is not overly complicated.
Actually, if you check Vol 4 Part A Section 1, it says that objective of
UART TL is to have both ends on the same PCB and communication is free form
errors, so there is no case that we suddenly have controller disconnected -
I'd say above assumption is reasonable :-)
BR,
Andrzej
On Sat, Feb 4, 2017 at 12:25 AM, will sanfilippo <wi...@runtime.io> wrote:
> Hi Andrzej
>
> Thanks for pointing me to Vol 2 Part E, Section 4.4. I was recalling a
> section of the spec that talked about this but could not find it when I
> sent this email. Thus, I completely agree that the controller sending a
> NOOP does not in any way indicate that it reset. It is fine if the
> controller does send a NOOP, but the host cannot use that as an indication
> that the controller reset. That does make things a bit tricky though as you
> mention, but hopefully if something is really badly out of sync the host
> will figure it out and reset the controller.
>
> I was also thinking of the following scenario which I should have
> explained a bit better. If the controller is powered off, it is not driving
> the flow control line so I am not sure what would happen HW wise in this
> case. It could be that the flow control line is floating, and therefore the
> host could see it in various states. Therefore, I would suspect that when a
> host issues a HCI Reset and does not get a response for some amount of
> time, it just keeps issuing the HCI Reset until it gets a response.
>
> Given that a controller can send a NOOP on power up, I cant see how we can
> guarantee that the following will NOT happen:
>
> * Host sends HCI Reset
> * Controller sends NOOP
> * Controller sends Command Complete w/Reset opcode
>
> I can also see this happening:
>
> * Host sends HCI Reset
> * Controller sends NOOP
> * Nothing else happens
>
> I certainly agree that once the controller actively takes control of the
> flow control line it should honor the HCI Reset although I still see the
> possibility of the two scenarios described above happening.
>
> Regarding HW Error: that is something we can do in the controller as we
> can look at the reason why the device reset and send a HW error event.
>
>
> > On Feb 3, 2017, at 12:12 PM, Andrzej Kaczmarek <
> andrzej.kaczmarek@codecoup.pl> wrote:
> >
> > Hi Will,
> >
> > On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <wi...@runtime.io>
> wrote:
> >
> >> I might be getting a bit confused here so hopefully I am making some
> >> sense. I seem to recall some discussion around this in the past but I
> cant
> >> recall :-) Anyway...
> >>
> >> It is my understanding that the first thing a controller should do when
> it
> >> powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6 Part D
> >> Section 2 you can see a message sequence chart that shows this. It
> sounds
> >> like folks think MyNewt is different than other controllers in this
> >> respect. If so, we can change that behavior, but it makes sense to me
> to do
> >> this, as it will inform the host that the controller has powered up.
> >>
> >
> > The section you quote is only informative (see section 1.1 of the same
> > part) and the diagram is only one of possibilities. The actual
> requirement
> > is in Vol 2, Part E, Section 4.4 which states that after power up host is
> > allowed to send up to 1 outstanding command so 1 credit is assumed here.
> > Also controller does not need to send noop, but it is also not an error
> to
> > do so.
> >
> > Of course, there is a chicken and egg problem here. If the controller is
> >> not powered up and the host sends a HCI Reset, the host is obviously not
> >> going to get a response. I am also not sure one can trust the flow
> control
> >> lines if the board is not powered up but one would hope that RTS/CTS are
> >> pulled the proper way if the controller is not powered.
> >>
> >
> > I guess host can assume that CTS/RTS lines work properly, otherwise there
> > is no way to detect when controller is ready to receive something (i.e.
> is
> > attached).
> >
> >
> >> Certainly, an interesting issue with the MyNewt HCI firmware would be
> the
> >> order in which the UART gets initialized and when the LL is
> initialized. In
> >> the end, I dont think it should really matter, as the host should have
> to
> >> deal with the controller not being ready to receive the HCI Reset.
> >>
> >
> > My understanding of spec section I mentioned is that controller should be
> > always ready to receive HCI Reset after power up. If it is not, then flow
> > control on transport layer should not be enabled.
> >
> >
> >> Here are the basic scenarios and what I would expect:
> >>
> >> 1. Controller powers up first and host is not powered or not ready
> >> * Controller issues NOOP but host does not see it.
> >> * Host wakes up and sends HCI Reset.
> >> * Host gets Command Complete (with proper opcode) and all is well
> >>
> >
> > Agree.
> >
> > 2. Host powers up first and controller powers up some time later
> >> * Host sends HCI Reset but gets no response.
> >> * Host sits in a loop, sending HCI Resets periodically.
> >> * If Host gets a NOOP, it knows that the controller has powered up. In
> >> this case, the host should issue HCI Reset and should get a Command
> >> Complete.
> >> * If the Host gets a Command Complete with proper opcode, all is well.
> >>
> >
> > I think this is the case where host actually does not send HCI Reset
> since
> > controller is not ready and RTS/CTS flow control is not enabled. If
> > controller enabled hardware flow control, it should receive and process
> > anything according to spec.
> >
> > 3. Host and Controller were communicating fine and Controller powers
> off/on
> >> * Host will see an “unsolicited” NOOP and should realize that the
> >> Controller has just reset. Host should perform appropriate actions.
> >>
> >
> > No, because controller can send noop at any time and it does not mean a
> > reset - see section I mentioned earlier. But to be honest I don't really
> > know how this should be handled properly. Probably the things would go so
> > wrong (due to states on both sides which are out of sync) that either
> > controller would eventually issue a hardware error event or host would
> > request controller since it cannot talk to it anymore. But it's up to
> > implementations which one will detect this first, I guess.
> >
> > 4. Host and Controller were communicating fine and Host powers off/on
> >> * Controller sees a HCI Reset and performs appropriate actions.
> >>
> >
> > Agree.
> >
> >
> >> An interesting case is one where the controller resets for a known
> reason
> >> (i.e. firmware asserts). Should the controller send a HW Error event in
> >> this case? Some folks I talked to thought it should; others were not
> sure.
> >> The nimble firmware does not do that; currently the only reason a HW
> error
> >> event is issued is when synchronization is lost between the host and
> >> controller (See Vol 4 Part A Section Part 4 Error Recovery).
> >>
> >
> > I'd say it should - this event is for "some type of hardware failure" as
> > spec says, so it could well be an assert in firmware.
> >
> >
> >>
> >> Comments/Thoughts?
> >>
> >>
> >>> On Feb 3, 2017, at 4:07 AM, Szymon Janc <sz...@codecoup.pl>
> wrote:
> >>>
> >>> Hi Alan,
> >>>
> >>> On 3 February 2017 at 07:16, Alan Graves <ag...@deltacontrols.com>
> >> wrote:
> >>>> Hi Szymon,
> >>>>
> >>>> I don't think waiting for the NOP before attaching made any
> difference,
> >> but now I can't remember so I'll have to check that. In any case here is
> >> the btmon output I got during my initial testing:
> >>>>
> >>>> $ sudo btmon
> >>>> [sudo] password for alan:
> >>>> Bluetooth monitor ver 5.41
> >>>> = Note: Linux version 4.8.0-34-generic (x86_64)
> >> 0.977791
> >>>> = Note: Bluetooth subsystem version 2.21
> >> 0.977792
> >>>> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0]
> >> 121.060311
> >>>> = Open Index: 00:00:00:00:00:00 [hci0]
> >> 121.066478
> >>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0]
> >> 121.070996
> >>>> = bluetoothd: Bluetooth daemon 5.41
> >> 121.092783
> >>>> = bluetoothd: Starting SDP server
> >> 121.104354
> >>>> = bluetoothd: Bluetooth management interface 1.13 initialized
> >> 121.112600
> >>>>> HCI Event: Command Complete (0x0e) plen 3 [hci0]
> >> 126.168513
> >>>> NOP (0x00|0x0000) ncmd 1
> >>>> = Close Index: 00:00:00:00:00:00 [hci0]
> >> 131.246188
> >>>>
> >>>
> >>> I suspect that HCI Reset is simply ignored before NOP is sent and
> >>> Linux will not try sending another command before getting Command
> >>> Status for it.
> >>> And that will never happen since command was ignored ie. Zephyr has
> >>> special config option when used with Mynewt based BT firmware to
> >>> handle this
> >>> exact situation - send HCI Reset only after initial NOP was received.
> >>> Linux on the other hand assumes that once device is attached it is
> >>> ready to
> >>> receive initial HCI Reset.
> >>>
> >>>> ALan
> >>>>
> >>>> -----Original Message-----
> >>>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
> >>>> Sent: Thursday, February 02, 2017 12:18 PM
> >>>> To: dev@mynewt.incubator.apache.org
> >>>> Subject: Re: BLE HCI support on NRF52DK
> >>>>
> >>>> Hi Alan,
> >>>>
> >>>> On 2 February 2017 at 19:16, Alan Graves <ag...@deltacontrols.com>
> >> 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...
> >>>>
> >>>> btattach has -N, --noflowctl option for disabling flow control. Yet,
> >> it is not recommended for H4 protocol (actually, H4 spec requires flow
> >> control to be enabled).
> >>>>
> >>>> But I'd first check if simply waiting for few seconds before calling
> >> btattach fix the problem (ie so that Linux sends initial HCI Reset after
> >> NOP event was emitted).
> >>>>
> >>>>> ALan
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Christopher Collins [mailto:ccollins@apache.org]
> >>>>> Sent: Wednesday, February 01, 2017 4:00 PM
> >>>>> To: dev@mynewt.incubator.apache.org
> >>>>> Subject: Re: BLE HCI support on NRF52DK
> >>>>>
> >>>>> Hi Alan,
> >>>>>
> >>>>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I've spent some time trying to get nRF52832 DK running the 'blehci'
> >> code communicating with Xubuntu 16.10 (under VMware) with not much luck.
> >>>>>
> >>>>> I just ran the latest blehci from develop with the following setup:
> >>>>>
> >>>>> * BlueZ 5.39
> >>>>> * Ubuntu 16.04 (Xenial)
> >>>>> * nRF52832 DK
> >>>>>
> >>>>> I didn't notice any issues when I tried. I'm afraid I don't see
> >> anything wrong with the steps you follows. Maybe one of the following
> >> hints will help:
> >>>>>
> >>>>> * Make sure the two flow control pins (RTS / CTS) are attached.
> >>>>>
> >>>>> * Try killing btattach and restarting it. When you do this, you
> should
> >>>>> see BlueZ send the host init sequence in btmon (starting with a Reset
> >>>>> command).
> >>>>>
> >>>>> The btattach step is required because the BlueZ host doesn't seem to
> >> interpret the no-op event as a controller reset. You have to explicitly
> >> tell the host to reset the controller.
> >>>>>
> >>>>> Hopefully this gets you a little closer to a solution. If you're
> >> still seeing the same issue, just let me know and we can debug it
> further.
> >>>>>
> >>>>> Thanks,
> >>>>> Chris
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> pozdrawiam
> >>>> Szymon K. Janc
> >>>
> >>>
> >>>
> >>> --
> >>> pozdrawiam
> >>> Szymon K. Janc
> >>
> >>
> > BR,
> > Andrzej
>
>
Re: BLE HCI support on NRF52DK
Posted by will sanfilippo <wi...@runtime.io>.
Hi Andrzej
Thanks for pointing me to Vol 2 Part E, Section 4.4. I was recalling a section of the spec that talked about this but could not find it when I sent this email. Thus, I completely agree that the controller sending a NOOP does not in any way indicate that it reset. It is fine if the controller does send a NOOP, but the host cannot use that as an indication that the controller reset. That does make things a bit tricky though as you mention, but hopefully if something is really badly out of sync the host will figure it out and reset the controller.
I was also thinking of the following scenario which I should have explained a bit better. If the controller is powered off, it is not driving the flow control line so I am not sure what would happen HW wise in this case. It could be that the flow control line is floating, and therefore the host could see it in various states. Therefore, I would suspect that when a host issues a HCI Reset and does not get a response for some amount of time, it just keeps issuing the HCI Reset until it gets a response.
Given that a controller can send a NOOP on power up, I cant see how we can guarantee that the following will NOT happen:
* Host sends HCI Reset
* Controller sends NOOP
* Controller sends Command Complete w/Reset opcode
I can also see this happening:
* Host sends HCI Reset
* Controller sends NOOP
* Nothing else happens
I certainly agree that once the controller actively takes control of the flow control line it should honor the HCI Reset although I still see the possibility of the two scenarios described above happening.
Regarding HW Error: that is something we can do in the controller as we can look at the reason why the device reset and send a HW error event.
> On Feb 3, 2017, at 12:12 PM, Andrzej Kaczmarek <an...@codecoup.pl> wrote:
>
> Hi Will,
>
> On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <wi...@runtime.io> wrote:
>
>> I might be getting a bit confused here so hopefully I am making some
>> sense. I seem to recall some discussion around this in the past but I cant
>> recall :-) Anyway...
>>
>> It is my understanding that the first thing a controller should do when it
>> powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6 Part D
>> Section 2 you can see a message sequence chart that shows this. It sounds
>> like folks think MyNewt is different than other controllers in this
>> respect. If so, we can change that behavior, but it makes sense to me to do
>> this, as it will inform the host that the controller has powered up.
>>
>
> The section you quote is only informative (see section 1.1 of the same
> part) and the diagram is only one of possibilities. The actual requirement
> is in Vol 2, Part E, Section 4.4 which states that after power up host is
> allowed to send up to 1 outstanding command so 1 credit is assumed here.
> Also controller does not need to send noop, but it is also not an error to
> do so.
>
> Of course, there is a chicken and egg problem here. If the controller is
>> not powered up and the host sends a HCI Reset, the host is obviously not
>> going to get a response. I am also not sure one can trust the flow control
>> lines if the board is not powered up but one would hope that RTS/CTS are
>> pulled the proper way if the controller is not powered.
>>
>
> I guess host can assume that CTS/RTS lines work properly, otherwise there
> is no way to detect when controller is ready to receive something (i.e. is
> attached).
>
>
>> Certainly, an interesting issue with the MyNewt HCI firmware would be the
>> order in which the UART gets initialized and when the LL is initialized. In
>> the end, I dont think it should really matter, as the host should have to
>> deal with the controller not being ready to receive the HCI Reset.
>>
>
> My understanding of spec section I mentioned is that controller should be
> always ready to receive HCI Reset after power up. If it is not, then flow
> control on transport layer should not be enabled.
>
>
>> Here are the basic scenarios and what I would expect:
>>
>> 1. Controller powers up first and host is not powered or not ready
>> * Controller issues NOOP but host does not see it.
>> * Host wakes up and sends HCI Reset.
>> * Host gets Command Complete (with proper opcode) and all is well
>>
>
> Agree.
>
> 2. Host powers up first and controller powers up some time later
>> * Host sends HCI Reset but gets no response.
>> * Host sits in a loop, sending HCI Resets periodically.
>> * If Host gets a NOOP, it knows that the controller has powered up. In
>> this case, the host should issue HCI Reset and should get a Command
>> Complete.
>> * If the Host gets a Command Complete with proper opcode, all is well.
>>
>
> I think this is the case where host actually does not send HCI Reset since
> controller is not ready and RTS/CTS flow control is not enabled. If
> controller enabled hardware flow control, it should receive and process
> anything according to spec.
>
> 3. Host and Controller were communicating fine and Controller powers off/on
>> * Host will see an “unsolicited” NOOP and should realize that the
>> Controller has just reset. Host should perform appropriate actions.
>>
>
> No, because controller can send noop at any time and it does not mean a
> reset - see section I mentioned earlier. But to be honest I don't really
> know how this should be handled properly. Probably the things would go so
> wrong (due to states on both sides which are out of sync) that either
> controller would eventually issue a hardware error event or host would
> request controller since it cannot talk to it anymore. But it's up to
> implementations which one will detect this first, I guess.
>
> 4. Host and Controller were communicating fine and Host powers off/on
>> * Controller sees a HCI Reset and performs appropriate actions.
>>
>
> Agree.
>
>
>> An interesting case is one where the controller resets for a known reason
>> (i.e. firmware asserts). Should the controller send a HW Error event in
>> this case? Some folks I talked to thought it should; others were not sure.
>> The nimble firmware does not do that; currently the only reason a HW error
>> event is issued is when synchronization is lost between the host and
>> controller (See Vol 4 Part A Section Part 4 Error Recovery).
>>
>
> I'd say it should - this event is for "some type of hardware failure" as
> spec says, so it could well be an assert in firmware.
>
>
>>
>> Comments/Thoughts?
>>
>>
>>> On Feb 3, 2017, at 4:07 AM, Szymon Janc <sz...@codecoup.pl> wrote:
>>>
>>> Hi Alan,
>>>
>>> On 3 February 2017 at 07:16, Alan Graves <ag...@deltacontrols.com>
>> wrote:
>>>> Hi Szymon,
>>>>
>>>> I don't think waiting for the NOP before attaching made any difference,
>> but now I can't remember so I'll have to check that. In any case here is
>> the btmon output I got during my initial testing:
>>>>
>>>> $ sudo btmon
>>>> [sudo] password for alan:
>>>> Bluetooth monitor ver 5.41
>>>> = Note: Linux version 4.8.0-34-generic (x86_64)
>> 0.977791
>>>> = Note: Bluetooth subsystem version 2.21
>> 0.977792
>>>> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0]
>> 121.060311
>>>> = Open Index: 00:00:00:00:00:00 [hci0]
>> 121.066478
>>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0]
>> 121.070996
>>>> = bluetoothd: Bluetooth daemon 5.41
>> 121.092783
>>>> = bluetoothd: Starting SDP server
>> 121.104354
>>>> = bluetoothd: Bluetooth management interface 1.13 initialized
>> 121.112600
>>>>> HCI Event: Command Complete (0x0e) plen 3 [hci0]
>> 126.168513
>>>> NOP (0x00|0x0000) ncmd 1
>>>> = Close Index: 00:00:00:00:00:00 [hci0]
>> 131.246188
>>>>
>>>
>>> I suspect that HCI Reset is simply ignored before NOP is sent and
>>> Linux will not try sending another command before getting Command
>>> Status for it.
>>> And that will never happen since command was ignored ie. Zephyr has
>>> special config option when used with Mynewt based BT firmware to
>>> handle this
>>> exact situation - send HCI Reset only after initial NOP was received.
>>> Linux on the other hand assumes that once device is attached it is
>>> ready to
>>> receive initial HCI Reset.
>>>
>>>> ALan
>>>>
>>>> -----Original Message-----
>>>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>>>> Sent: Thursday, February 02, 2017 12:18 PM
>>>> To: dev@mynewt.incubator.apache.org
>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>
>>>> Hi Alan,
>>>>
>>>> On 2 February 2017 at 19:16, Alan Graves <ag...@deltacontrols.com>
>> 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...
>>>>
>>>> btattach has -N, --noflowctl option for disabling flow control. Yet,
>> it is not recommended for H4 protocol (actually, H4 spec requires flow
>> control to be enabled).
>>>>
>>>> But I'd first check if simply waiting for few seconds before calling
>> btattach fix the problem (ie so that Linux sends initial HCI Reset after
>> NOP event was emitted).
>>>>
>>>>> ALan
>>>>>
>>>>> -----Original Message-----
>>>>> From: Christopher Collins [mailto:ccollins@apache.org]
>>>>> Sent: Wednesday, February 01, 2017 4:00 PM
>>>>> To: dev@mynewt.incubator.apache.org
>>>>> Subject: Re: BLE HCI support on NRF52DK
>>>>>
>>>>> Hi Alan,
>>>>>
>>>>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've spent some time trying to get nRF52832 DK running the 'blehci'
>> code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>>>>>
>>>>> I just ran the latest blehci from develop with the following setup:
>>>>>
>>>>> * BlueZ 5.39
>>>>> * Ubuntu 16.04 (Xenial)
>>>>> * nRF52832 DK
>>>>>
>>>>> I didn't notice any issues when I tried. I'm afraid I don't see
>> anything wrong with the steps you follows. Maybe one of the following
>> hints will help:
>>>>>
>>>>> * Make sure the two flow control pins (RTS / CTS) are attached.
>>>>>
>>>>> * Try killing btattach and restarting it. When you do this, you should
>>>>> see BlueZ send the host init sequence in btmon (starting with a Reset
>>>>> command).
>>>>>
>>>>> The btattach step is required because the BlueZ host doesn't seem to
>> interpret the no-op event as a controller reset. You have to explicitly
>> tell the host to reset the controller.
>>>>>
>>>>> Hopefully this gets you a little closer to a solution. If you're
>> still seeing the same issue, just let me know and we can debug it further.
>>>>>
>>>>> Thanks,
>>>>> Chris
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> pozdrawiam
>>>> Szymon K. Janc
>>>
>>>
>>>
>>> --
>>> pozdrawiam
>>> Szymon K. Janc
>>
>>
> BR,
> Andrzej
Re: BLE HCI support on NRF52DK
Posted by Andrzej Kaczmarek <an...@codecoup.pl>.
Hi Will,
On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <wi...@runtime.io> wrote:
> I might be getting a bit confused here so hopefully I am making some
> sense. I seem to recall some discussion around this in the past but I cant
> recall :-) Anyway...
>
> It is my understanding that the first thing a controller should do when it
> powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6 Part D
> Section 2 you can see a message sequence chart that shows this. It sounds
> like folks think MyNewt is different than other controllers in this
> respect. If so, we can change that behavior, but it makes sense to me to do
> this, as it will inform the host that the controller has powered up.
>
The section you quote is only informative (see section 1.1 of the same
part) and the diagram is only one of possibilities. The actual requirement
is in Vol 2, Part E, Section 4.4 which states that after power up host is
allowed to send up to 1 outstanding command so 1 credit is assumed here.
Also controller does not need to send noop, but it is also not an error to
do so.
Of course, there is a chicken and egg problem here. If the controller is
> not powered up and the host sends a HCI Reset, the host is obviously not
> going to get a response. I am also not sure one can trust the flow control
> lines if the board is not powered up but one would hope that RTS/CTS are
> pulled the proper way if the controller is not powered.
>
I guess host can assume that CTS/RTS lines work properly, otherwise there
is no way to detect when controller is ready to receive something (i.e. is
attached).
> Certainly, an interesting issue with the MyNewt HCI firmware would be the
> order in which the UART gets initialized and when the LL is initialized. In
> the end, I dont think it should really matter, as the host should have to
> deal with the controller not being ready to receive the HCI Reset.
>
My understanding of spec section I mentioned is that controller should be
always ready to receive HCI Reset after power up. If it is not, then flow
control on transport layer should not be enabled.
> Here are the basic scenarios and what I would expect:
>
> 1. Controller powers up first and host is not powered or not ready
> * Controller issues NOOP but host does not see it.
> * Host wakes up and sends HCI Reset.
> * Host gets Command Complete (with proper opcode) and all is well
>
Agree.
2. Host powers up first and controller powers up some time later
> * Host sends HCI Reset but gets no response.
> * Host sits in a loop, sending HCI Resets periodically.
> * If Host gets a NOOP, it knows that the controller has powered up. In
> this case, the host should issue HCI Reset and should get a Command
> Complete.
> * If the Host gets a Command Complete with proper opcode, all is well.
>
I think this is the case where host actually does not send HCI Reset since
controller is not ready and RTS/CTS flow control is not enabled. If
controller enabled hardware flow control, it should receive and process
anything according to spec.
3. Host and Controller were communicating fine and Controller powers off/on
> * Host will see an “unsolicited” NOOP and should realize that the
> Controller has just reset. Host should perform appropriate actions.
>
No, because controller can send noop at any time and it does not mean a
reset - see section I mentioned earlier. But to be honest I don't really
know how this should be handled properly. Probably the things would go so
wrong (due to states on both sides which are out of sync) that either
controller would eventually issue a hardware error event or host would
request controller since it cannot talk to it anymore. But it's up to
implementations which one will detect this first, I guess.
4. Host and Controller were communicating fine and Host powers off/on
> * Controller sees a HCI Reset and performs appropriate actions.
>
Agree.
> An interesting case is one where the controller resets for a known reason
> (i.e. firmware asserts). Should the controller send a HW Error event in
> this case? Some folks I talked to thought it should; others were not sure.
> The nimble firmware does not do that; currently the only reason a HW error
> event is issued is when synchronization is lost between the host and
> controller (See Vol 4 Part A Section Part 4 Error Recovery).
>
I'd say it should - this event is for "some type of hardware failure" as
spec says, so it could well be an assert in firmware.
>
> Comments/Thoughts?
>
>
> > On Feb 3, 2017, at 4:07 AM, Szymon Janc <sz...@codecoup.pl> wrote:
> >
> > Hi Alan,
> >
> > On 3 February 2017 at 07:16, Alan Graves <ag...@deltacontrols.com>
> wrote:
> >> Hi Szymon,
> >>
> >> I don't think waiting for the NOP before attaching made any difference,
> but now I can't remember so I'll have to check that. In any case here is
> the btmon output I got during my initial testing:
> >>
> >> $ sudo btmon
> >> [sudo] password for alan:
> >> Bluetooth monitor ver 5.41
> >> = Note: Linux version 4.8.0-34-generic (x86_64)
> 0.977791
> >> = Note: Bluetooth subsystem version 2.21
> 0.977792
> >> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0]
> 121.060311
> >> = Open Index: 00:00:00:00:00:00 [hci0]
> 121.066478
> >> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0]
> 121.070996
> >> = bluetoothd: Bluetooth daemon 5.41
> 121.092783
> >> = bluetoothd: Starting SDP server
> 121.104354
> >> = bluetoothd: Bluetooth management interface 1.13 initialized
> 121.112600
> >>> HCI Event: Command Complete (0x0e) plen 3 [hci0]
> 126.168513
> >> NOP (0x00|0x0000) ncmd 1
> >> = Close Index: 00:00:00:00:00:00 [hci0]
> 131.246188
> >>
> >
> > I suspect that HCI Reset is simply ignored before NOP is sent and
> > Linux will not try sending another command before getting Command
> > Status for it.
> > And that will never happen since command was ignored ie. Zephyr has
> > special config option when used with Mynewt based BT firmware to
> > handle this
> > exact situation - send HCI Reset only after initial NOP was received.
> > Linux on the other hand assumes that once device is attached it is
> > ready to
> > receive initial HCI Reset.
> >
> >> ALan
> >>
> >> -----Original Message-----
> >> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
> >> Sent: Thursday, February 02, 2017 12:18 PM
> >> To: dev@mynewt.incubator.apache.org
> >> Subject: Re: BLE HCI support on NRF52DK
> >>
> >> Hi Alan,
> >>
> >> On 2 February 2017 at 19:16, Alan Graves <ag...@deltacontrols.com>
> 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...
> >>
> >> btattach has -N, --noflowctl option for disabling flow control. Yet,
> it is not recommended for H4 protocol (actually, H4 spec requires flow
> control to be enabled).
> >>
> >> But I'd first check if simply waiting for few seconds before calling
> btattach fix the problem (ie so that Linux sends initial HCI Reset after
> NOP event was emitted).
> >>
> >>> ALan
> >>>
> >>> -----Original Message-----
> >>> From: Christopher Collins [mailto:ccollins@apache.org]
> >>> Sent: Wednesday, February 01, 2017 4:00 PM
> >>> To: dev@mynewt.incubator.apache.org
> >>> Subject: Re: BLE HCI support on NRF52DK
> >>>
> >>> Hi Alan,
> >>>
> >>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
> >>>> Hi,
> >>>>
> >>>> I've spent some time trying to get nRF52832 DK running the 'blehci'
> code communicating with Xubuntu 16.10 (under VMware) with not much luck.
> >>>
> >>> I just ran the latest blehci from develop with the following setup:
> >>>
> >>> * BlueZ 5.39
> >>> * Ubuntu 16.04 (Xenial)
> >>> * nRF52832 DK
> >>>
> >>> I didn't notice any issues when I tried. I'm afraid I don't see
> anything wrong with the steps you follows. Maybe one of the following
> hints will help:
> >>>
> >>> * Make sure the two flow control pins (RTS / CTS) are attached.
> >>>
> >>> * Try killing btattach and restarting it. When you do this, you should
> >>> see BlueZ send the host init sequence in btmon (starting with a Reset
> >>> command).
> >>>
> >>> The btattach step is required because the BlueZ host doesn't seem to
> interpret the no-op event as a controller reset. You have to explicitly
> tell the host to reset the controller.
> >>>
> >>> Hopefully this gets you a little closer to a solution. If you're
> still seeing the same issue, just let me know and we can debug it further.
> >>>
> >>> Thanks,
> >>> Chris
> >>
> >>
> >>
> >>
> >> --
> >> pozdrawiam
> >> Szymon K. Janc
> >
> >
> >
> > --
> > pozdrawiam
> > Szymon K. Janc
>
>
BR,
Andrzej
Re: BLE HCI support on NRF52DK
Posted by will sanfilippo <wi...@runtime.io>.
I might be getting a bit confused here so hopefully I am making some sense. I seem to recall some discussion around this in the past but I cant recall :-) Anyway...
It is my understanding that the first thing a controller should do when it powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6 Part D Section 2 you can see a message sequence chart that shows this. It sounds like folks think MyNewt is different than other controllers in this respect. If so, we can change that behavior, but it makes sense to me to do this, as it will inform the host that the controller has powered up.
Of course, there is a chicken and egg problem here. If the controller is not powered up and the host sends a HCI Reset, the host is obviously not going to get a response. I am also not sure one can trust the flow control lines if the board is not powered up but one would hope that RTS/CTS are pulled the proper way if the controller is not powered.
Certainly, an interesting issue with the MyNewt HCI firmware would be the order in which the UART gets initialized and when the LL is initialized. In the end, I dont think it should really matter, as the host should have to deal with the controller not being ready to receive the HCI Reset.
Here are the basic scenarios and what I would expect:
1. Controller powers up first and host is not powered or not ready
* Controller issues NOOP but host does not see it.
* Host wakes up and sends HCI Reset.
* Host gets Command Complete (with proper opcode) and all is well
2. Host powers up first and controller powers up some time later
* Host sends HCI Reset but gets no response.
* Host sits in a loop, sending HCI Resets periodically.
* If Host gets a NOOP, it knows that the controller has powered up. In this case, the host should issue HCI Reset and should get a Command Complete.
* If the Host gets a Command Complete with proper opcode, all is well.
3. Host and Controller were communicating fine and Controller powers off/on
* Host will see an “unsolicited” NOOP and should realize that the Controller has just reset. Host should perform appropriate actions.
4. Host and Controller were communicating fine and Host powers off/on
* Controller sees a HCI Reset and performs appropriate actions.
An interesting case is one where the controller resets for a known reason (i.e. firmware asserts). Should the controller send a HW Error event in this case? Some folks I talked to thought it should; others were not sure. The nimble firmware does not do that; currently the only reason a HW error event is issued is when synchronization is lost between the host and controller (See Vol 4 Part A Section Part 4 Error Recovery).
Comments/Thoughts?
> On Feb 3, 2017, at 4:07 AM, Szymon Janc <sz...@codecoup.pl> wrote:
>
> Hi Alan,
>
> On 3 February 2017 at 07:16, Alan Graves <ag...@deltacontrols.com> wrote:
>> Hi Szymon,
>>
>> I don't think waiting for the NOP before attaching made any difference, but now I can't remember so I'll have to check that. In any case here is the btmon output I got during my initial testing:
>>
>> $ sudo btmon
>> [sudo] password for alan:
>> Bluetooth monitor ver 5.41
>> = Note: Linux version 4.8.0-34-generic (x86_64) 0.977791
>> = Note: Bluetooth subsystem version 2.21 0.977792
>> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0] 121.060311
>> = Open Index: 00:00:00:00:00:00 [hci0] 121.066478
>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 121.070996
>> = bluetoothd: Bluetooth daemon 5.41 121.092783
>> = bluetoothd: Starting SDP server 121.104354
>> = bluetoothd: Bluetooth management interface 1.13 initialized 121.112600
>>> HCI Event: Command Complete (0x0e) plen 3 [hci0] 126.168513
>> NOP (0x00|0x0000) ncmd 1
>> = Close Index: 00:00:00:00:00:00 [hci0] 131.246188
>>
>
> I suspect that HCI Reset is simply ignored before NOP is sent and
> Linux will not try sending another command before getting Command
> Status for it.
> And that will never happen since command was ignored ie. Zephyr has
> special config option when used with Mynewt based BT firmware to
> handle this
> exact situation - send HCI Reset only after initial NOP was received.
> Linux on the other hand assumes that once device is attached it is
> ready to
> receive initial HCI Reset.
>
>> ALan
>>
>> -----Original Message-----
>> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
>> Sent: Thursday, February 02, 2017 12:18 PM
>> To: dev@mynewt.incubator.apache.org
>> Subject: Re: BLE HCI support on NRF52DK
>>
>> Hi Alan,
>>
>> On 2 February 2017 at 19:16, Alan Graves <ag...@deltacontrols.com> 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...
>>
>> btattach has -N, --noflowctl option for disabling flow control. Yet, it is not recommended for H4 protocol (actually, H4 spec requires flow control to be enabled).
>>
>> But I'd first check if simply waiting for few seconds before calling btattach fix the problem (ie so that Linux sends initial HCI Reset after NOP event was emitted).
>>
>>> ALan
>>>
>>> -----Original Message-----
>>> From: Christopher Collins [mailto:ccollins@apache.org]
>>> Sent: Wednesday, February 01, 2017 4:00 PM
>>> To: dev@mynewt.incubator.apache.org
>>> Subject: Re: BLE HCI support on NRF52DK
>>>
>>> Hi Alan,
>>>
>>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
>>>> Hi,
>>>>
>>>> I've spent some time trying to get nRF52832 DK running the 'blehci' code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>>>
>>> I just ran the latest blehci from develop with the following setup:
>>>
>>> * BlueZ 5.39
>>> * Ubuntu 16.04 (Xenial)
>>> * nRF52832 DK
>>>
>>> I didn't notice any issues when I tried. I'm afraid I don't see anything wrong with the steps you follows. Maybe one of the following hints will help:
>>>
>>> * Make sure the two flow control pins (RTS / CTS) are attached.
>>>
>>> * Try killing btattach and restarting it. When you do this, you should
>>> see BlueZ send the host init sequence in btmon (starting with a Reset
>>> command).
>>>
>>> The btattach step is required because the BlueZ host doesn't seem to interpret the no-op event as a controller reset. You have to explicitly tell the host to reset the controller.
>>>
>>> Hopefully this gets you a little closer to a solution. If you're still seeing the same issue, just let me know and we can debug it further.
>>>
>>> Thanks,
>>> Chris
>>
>>
>>
>>
>> --
>> pozdrawiam
>> Szymon K. Janc
>
>
>
> --
> pozdrawiam
> Szymon K. Janc
Re: BLE HCI support on NRF52DK
Posted by Szymon Janc <sz...@codecoup.pl>.
Hi Alan,
On 3 February 2017 at 07:16, Alan Graves <ag...@deltacontrols.com> wrote:
> Hi Szymon,
>
> I don't think waiting for the NOP before attaching made any difference, but now I can't remember so I'll have to check that. In any case here is the btmon output I got during my initial testing:
>
> $ sudo btmon
> [sudo] password for alan:
> Bluetooth monitor ver 5.41
> = Note: Linux version 4.8.0-34-generic (x86_64) 0.977791
> = Note: Bluetooth subsystem version 2.21 0.977792
> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0] 121.060311
> = Open Index: 00:00:00:00:00:00 [hci0] 121.066478
> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 121.070996
> = bluetoothd: Bluetooth daemon 5.41 121.092783
> = bluetoothd: Starting SDP server 121.104354
> = bluetoothd: Bluetooth management interface 1.13 initialized 121.112600
>> HCI Event: Command Complete (0x0e) plen 3 [hci0] 126.168513
> NOP (0x00|0x0000) ncmd 1
> = Close Index: 00:00:00:00:00:00 [hci0] 131.246188
>
I suspect that HCI Reset is simply ignored before NOP is sent and
Linux will not try sending another command before getting Command
Status for it.
And that will never happen since command was ignored ie. Zephyr has
special config option when used with Mynewt based BT firmware to
handle this
exact situation - send HCI Reset only after initial NOP was received.
Linux on the other hand assumes that once device is attached it is
ready to
receive initial HCI Reset.
> ALan
>
> -----Original Message-----
> From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
> Sent: Thursday, February 02, 2017 12:18 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: BLE HCI support on NRF52DK
>
> Hi Alan,
>
> On 2 February 2017 at 19:16, Alan Graves <ag...@deltacontrols.com> 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...
>
> btattach has -N, --noflowctl option for disabling flow control. Yet, it is not recommended for H4 protocol (actually, H4 spec requires flow control to be enabled).
>
> But I'd first check if simply waiting for few seconds before calling btattach fix the problem (ie so that Linux sends initial HCI Reset after NOP event was emitted).
>
>> ALan
>>
>> -----Original Message-----
>> From: Christopher Collins [mailto:ccollins@apache.org]
>> Sent: Wednesday, February 01, 2017 4:00 PM
>> To: dev@mynewt.incubator.apache.org
>> Subject: Re: BLE HCI support on NRF52DK
>>
>> Hi Alan,
>>
>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
>> > Hi,
>> >
>> > I've spent some time trying to get nRF52832 DK running the 'blehci' code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>>
>> I just ran the latest blehci from develop with the following setup:
>>
>> * BlueZ 5.39
>> * Ubuntu 16.04 (Xenial)
>> * nRF52832 DK
>>
>> I didn't notice any issues when I tried. I'm afraid I don't see anything wrong with the steps you follows. Maybe one of the following hints will help:
>>
>> * Make sure the two flow control pins (RTS / CTS) are attached.
>>
>> * Try killing btattach and restarting it. When you do this, you should
>> see BlueZ send the host init sequence in btmon (starting with a Reset
>> command).
>>
>> The btattach step is required because the BlueZ host doesn't seem to interpret the no-op event as a controller reset. You have to explicitly tell the host to reset the controller.
>>
>> Hopefully this gets you a little closer to a solution. If you're still seeing the same issue, just let me know and we can debug it further.
>>
>> Thanks,
>> Chris
>
>
>
>
> --
> pozdrawiam
> Szymon K. Janc
--
pozdrawiam
Szymon K. Janc
RE: BLE HCI support on NRF52DK
Posted by Alan Graves <ag...@deltacontrols.com>.
Hi Szymon,
I don't think waiting for the NOP before attaching made any difference, but now I can't remember so I'll have to check that. In any case here is the btmon output I got during my initial testing:
$ sudo btmon
[sudo] password for alan:
Bluetooth monitor ver 5.41
= Note: Linux version 4.8.0-34-generic (x86_64) 0.977791
= Note: Bluetooth subsystem version 2.21 0.977792
= New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0] 121.060311
= Open Index: 00:00:00:00:00:00 [hci0] 121.066478
< HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 121.070996
= bluetoothd: Bluetooth daemon 5.41 121.092783
= bluetoothd: Starting SDP server 121.104354
= bluetoothd: Bluetooth management interface 1.13 initialized 121.112600
> HCI Event: Command Complete (0x0e) plen 3 [hci0] 126.168513
NOP (0x00|0x0000) ncmd 1
= Close Index: 00:00:00:00:00:00 [hci0] 131.246188
ALan
-----Original Message-----
From: Szymon Janc [mailto:szymon.janc@codecoup.pl]
Sent: Thursday, February 02, 2017 12:18 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Hi Alan,
On 2 February 2017 at 19:16, Alan Graves <ag...@deltacontrols.com> 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...
btattach has -N, --noflowctl option for disabling flow control. Yet, it is not recommended for H4 protocol (actually, H4 spec requires flow control to be enabled).
But I'd first check if simply waiting for few seconds before calling btattach fix the problem (ie so that Linux sends initial HCI Reset after NOP event was emitted).
> ALan
>
> -----Original Message-----
> From: Christopher Collins [mailto:ccollins@apache.org]
> Sent: Wednesday, February 01, 2017 4:00 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: BLE HCI support on NRF52DK
>
> Hi Alan,
>
> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
> > Hi,
> >
> > I've spent some time trying to get nRF52832 DK running the 'blehci' code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>
> I just ran the latest blehci from develop with the following setup:
>
> * BlueZ 5.39
> * Ubuntu 16.04 (Xenial)
> * nRF52832 DK
>
> I didn't notice any issues when I tried. I'm afraid I don't see anything wrong with the steps you follows. Maybe one of the following hints will help:
>
> * Make sure the two flow control pins (RTS / CTS) are attached.
>
> * Try killing btattach and restarting it. When you do this, you should
> see BlueZ send the host init sequence in btmon (starting with a Reset
> command).
>
> The btattach step is required because the BlueZ host doesn't seem to interpret the no-op event as a controller reset. You have to explicitly tell the host to reset the controller.
>
> Hopefully this gets you a little closer to a solution. If you're still seeing the same issue, just let me know and we can debug it further.
>
> Thanks,
> Chris
--
pozdrawiam
Szymon K. Janc
Re: BLE HCI support on NRF52DK
Posted by Szymon Janc <sz...@codecoup.pl>.
Hi Alan,
On 2 February 2017 at 19:16, Alan Graves <ag...@deltacontrols.com> 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...
btattach has -N, --noflowctl option for disabling flow control. Yet,
it is not recommended for H4 protocol
(actually, H4 spec requires flow control to be enabled).
But I'd first check if simply waiting for few seconds before calling
btattach fix the problem (ie so that Linux
sends initial HCI Reset after NOP event was emitted).
> ALan
>
> -----Original Message-----
> From: Christopher Collins [mailto:ccollins@apache.org]
> Sent: Wednesday, February 01, 2017 4:00 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: BLE HCI support on NRF52DK
>
> Hi Alan,
>
> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
> > Hi,
> >
> > I've spent some time trying to get nRF52832 DK running the 'blehci' code communicating with Xubuntu 16.10 (under VMware) with not much luck.
>
> I just ran the latest blehci from develop with the following setup:
>
> * BlueZ 5.39
> * Ubuntu 16.04 (Xenial)
> * nRF52832 DK
>
> I didn't notice any issues when I tried. I'm afraid I don't see anything wrong with the steps you follows. Maybe one of the following hints will help:
>
> * Make sure the two flow control pins (RTS / CTS) are attached.
>
> * Try killing btattach and restarting it. When you do this, you should
> see BlueZ send the host init sequence in btmon (starting with a Reset
> command).
>
> The btattach step is required because the BlueZ host doesn't seem to interpret the no-op event as a controller reset. You have to explicitly tell the host to reset the controller.
>
> Hopefully this gets you a little closer to a solution. If you're still seeing the same issue, just let me know and we can debug it further.
>
> Thanks,
> Chris
--
pozdrawiam
Szymon K. Janc
RE: BLE HCI support on NRF52DK
Posted by Alan Graves <ag...@deltacontrols.com>.
Hi Chris,
Thank you for clarifying things - that helps a lot! I will work on making a demo that works as you described. I'm thinking that at this early stage I can make a hardware change to our board to include the RTS and CTS signals and that would be better in the long run.
ALan
-----Original Message-----
From: Christopher Collins [mailto:ccollins@apache.org]
Sent: Thursday, February 02, 2017 12:23 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Hi Alan,
On Thu, Feb 02, 2017 at 06:16:42PM +0000, 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 1000000 (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);
ti.c_cflag |= (speed | CLOCAL | CREAD);
/* Set flow control */
- ti.c_cflag |= CRTSCTS;
+ ti.c_cflag &= ~CRTSCTS;
if (tcsetattr(fd, TCSANOW, &ti) < 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
Re: BLE HCI support on NRF52DK
Posted by Christopher Collins <cc...@apache.org>.
Hi Alan,
On Thu, Feb 02, 2017 at 06:16:42PM +0000, 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 1000000
(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);
ti.c_cflag |= (speed | CLOCAL | CREAD);
/* Set flow control */
- ti.c_cflag |= CRTSCTS;
+ ti.c_cflag &= ~CRTSCTS;
if (tcsetattr(fd, TCSANOW, &ti) < 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
RE: BLE HCI support on NRF52DK
Posted by Alan Graves <ag...@deltacontrols.com>.
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...
ALan
-----Original Message-----
From: Christopher Collins [mailto:ccollins@apache.org]
Sent: Wednesday, February 01, 2017 4:00 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: BLE HCI support on NRF52DK
Hi Alan,
On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
> Hi,
>
> I've spent some time trying to get nRF52832 DK running the 'blehci' code communicating with Xubuntu 16.10 (under VMware) with not much luck.
I just ran the latest blehci from develop with the following setup:
* BlueZ 5.39
* Ubuntu 16.04 (Xenial)
* nRF52832 DK
I didn't notice any issues when I tried. I'm afraid I don't see anything wrong with the steps you follows. Maybe one of the following hints will help:
* Make sure the two flow control pins (RTS / CTS) are attached.
* Try killing btattach and restarting it. When you do this, you should
see BlueZ send the host init sequence in btmon (starting with a Reset
command).
The btattach step is required because the BlueZ host doesn't seem to interpret the no-op event as a controller reset. You have to explicitly tell the host to reset the controller.
Hopefully this gets you a little closer to a solution. If you're still seeing the same issue, just let me know and we can debug it further.
Thanks,
Chris
Re: BLE HCI support on NRF52DK
Posted by Christopher Collins <cc...@apache.org>.
Hi Alan,
On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote:
> Hi,
>
> I've spent some time trying to get nRF52832 DK running the 'blehci' code communicating with Xubuntu 16.10 (under VMware) with not much luck.
I just ran the latest blehci from develop with the following setup:
* BlueZ 5.39
* Ubuntu 16.04 (Xenial)
* nRF52832 DK
I didn't notice any issues when I tried. I'm afraid I don't see
anything wrong with the steps you follows. Maybe one of the following
hints will help:
* Make sure the two flow control pins (RTS / CTS) are attached.
* Try killing btattach and restarting it. When you do this, you should
see BlueZ send the host init sequence in btmon (starting with a Reset
command).
The btattach step is required because the BlueZ host doesn't seem to
interpret the no-op event as a controller reset. You have to explicitly
tell the host to reset the controller.
Hopefully this gets you a little closer to a solution. If you're still
seeing the same issue, just let me know and we can debug it further.
Thanks,
Chris