You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by James Howarth <ja...@gmail.com> on 2016/05/16 17:49:10 UTC
Trouble running bleprh example
Hi,
I am trying to get the bleprph example up and running on a Nordic nRF52
PDK. But I can't seem to see the device using the LightBlue app running on
my iPhone.
Here's what I have done:
- I copied the "repos/apache-mynewt-core/apps/bleprph" folder to apps/
- I edited the pkg.deps: in apps/bleprph/pkg.yml to:
pkg.deps:
- "@apache-mynewt-core/libs/os"
- "@apache-mynewt-core/sys/log"
- "@apache-mynewt-core/net/nimble/controller"
- "@apache-mynewt-core/net/nimble/host"
- "@apache-mynewt-core/libs/console/full"
- "@apache-mynewt-core/libs/baselibc"
- I set up the following targets:
targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
build_profile=optimized
targets/perph
app=apps/bleprph
bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
build_profile=debug
- I then loaded the boot and perph images.
- Power-cycled the board
Any suggestions are greatly appreciated.
Cheers
James
Re: Trouble running bleprh example
Posted by James Howarth <ja...@gmail.com>.
Hi Chris,
- I am using LightBlue on my iPhone. I have also tried the nRF MCP app
as well with the same result.
- Yes, the LightBlue does not show the device when you tell it to
re-scan.
- I also tried commenting out the data-length extension, but that did
not seem to change the behavior.
Is there a better osx or iPhone app to interrogate the BLE device?
According to the LightBlue Explorer, bleprph doesn't seem to be advertising
any services, when I would expect it to be at least advertising the 'Alert
Notification Service".
Cheers
James
On Mon, May 16, 2016 at 11:44 PM, Christopher Collins <cc...@apache.org>
wrote:
> On Mon, May 16, 2016 at 09:29:37PM -0700, James Howarth wrote:
> > Hi Chris,
> >
> > Thanks. I'm getting closer.
> >
> > Using the 'LightBlue Explorer' app:
> >
> > - I can see the nimble-bleprh device
> > - nim-bleprh appears to be advertising no services.
> > - When I try and connect to the nRF52, the app times out.
>
> Are you using LightBlue for the iPhone or for OS X? We have observed
> an apparent bug in the CoreBluetooth implemention in OS X which results
> in a disconnect shortly after the connection is established. I am not
> sure if this bug has been fixed in the latest OS X release.
>
> The bug is related to the data-length-extension link layer procedure.
> When the nimble device initiates this procedure, the mac replies with a
> malformed packet. You can disable the data length extension feature by
> modifying the
> repos/apache-mynewt-core/net/nimble/controller/include/controller/ble_ll.h
> file as follows:
>
> FROM:
> #define BLE_LL_CFG_FEAT_DATA_LEN_EXT
>
> TO:
> //#define BLE_LL_CFG_FEAT_DATA_LEN_EXT
>
> I.e., comment out the line which defines the
> BLE_LL_CFG_FEAT_DATA_LEN_EXT symbol.
>
> (disabling features such as this one has been made easier in more recent
> code, but for now you need to modify the code directly).
>
> > - After I connect once, it takes a couple of minutes, before the
> nimble
> > device will show up in my app, I thought it was supposed to be
> instant.
>
> The bleprph app should resume advertising as soon as the connection is
> broken. However, it does not advertise while it is still connected to
> something. Are you saying LightBlue does not show the device when you
> tell it to scan?
>
> Chris
>
Re: Trouble running bleprh example
Posted by Christopher Collins <cc...@apache.org>.
On Mon, May 16, 2016 at 09:29:37PM -0700, James Howarth wrote:
> Hi Chris,
>
> Thanks. I'm getting closer.
>
> Using the 'LightBlue Explorer' app:
>
> - I can see the nimble-bleprh device
> - nim-bleprh appears to be advertising no services.
> - When I try and connect to the nRF52, the app times out.
Are you using LightBlue for the iPhone or for OS X? We have observed
an apparent bug in the CoreBluetooth implemention in OS X which results
in a disconnect shortly after the connection is established. I am not
sure if this bug has been fixed in the latest OS X release.
The bug is related to the data-length-extension link layer procedure.
When the nimble device initiates this procedure, the mac replies with a
malformed packet. You can disable the data length extension feature by
modifying the
repos/apache-mynewt-core/net/nimble/controller/include/controller/ble_ll.h
file as follows:
FROM:
#define BLE_LL_CFG_FEAT_DATA_LEN_EXT
TO:
//#define BLE_LL_CFG_FEAT_DATA_LEN_EXT
I.e., comment out the line which defines the
BLE_LL_CFG_FEAT_DATA_LEN_EXT symbol.
(disabling features such as this one has been made easier in more recent
code, but for now you need to modify the code directly).
> - After I connect once, it takes a couple of minutes, before the nimble
> device will show up in my app, I thought it was supposed to be instant.
The bleprph app should resume advertising as soon as the connection is
broken. However, it does not advertise while it is still connected to
something. Are you saying LightBlue does not show the device when you
tell it to scan?
Chris
Re: Trouble running bleprh example
Posted by James Howarth <ja...@gmail.com>.
Hi Chris,
Thanks. I'm getting closer.
Using the 'LightBlue Explorer' app:
- I can see the nimble-bleprh device
- nim-bleprh appears to be advertising no services.
- When I try and connect to the nRF52, the app times out. Below is what
is output from the serial port during this exchange
13285:[ts=13285000ssb, mod=4 level=1] host_hci_data_rx(): handle=1 pb=2
len=7 data=0x03 0x00 0x04 0x00 0x02 0x9e 0x00
13293:[ts=13293000ssb, mod=4 level=1] host_hci_data_rx(): handle=1 pb=2
len=27 data=0x3b 0x00 0x3a 0x00 0x01 0x39 0x02 0x14 0x01 0x00 0x02 0x0f
0x63 0x6f 0x6d 0x2e 0x61 0x70 0x70 0x6c 0x65 0x2e 0x42 0x54 0x2e 0x54 0x53
13313:[ts=13313000ssb, mod=4 level=1] host_hci_data_rx(): handle=1 pb=1
len=27 data=0x01 0x22 0x02 0x00 0x01 0x1d 0x63 0x6f 0x6d 0x2e 0x61 0x70
0x70 0x6c 0x65 0x2e 0x42 0x54 0x4c 0x45 0x53 0x65 0x72 0x76 0x65 0x72 0x2e
13333:[ts=13333000ssb, mod=4 level=1] host_hci_data_rx(): handle=1 pb=1
len=9 data=0x63 0x6c 0x61 0x73 0x73 0x69 0x63 0x00 0x01
13345:[ts=13345000ssb, mod=4 level=1] host_hci_data_rx(): handle=1 pb=2
len=11 data=0x07 0x00 0x3a 0x00 0x09 0x05 0x01 0x00 0x00 0x00 0x00
28165:[ts=28165000ssb, mod=4 level=1] Disconnection Complete: status=0
handle=1 reason=19
- After I connect once, it takes a couple of minutes, before the nimble
device will show up in my app, I thought it was supposed to be instant.
Is this the expected behavior?
Cheers
James
On Mon, May 16, 2016 at 3:21 PM, chris collins <ch...@runtime.io> wrote:
> Hi James,
>
> Yes, there are two ways. The easier of the two is to use the "virtual COM
> port" that is exposed via the USB port. The other way is to attach a three
> wire serial cable to the appropriate pins on the nRF52. Either way, you
> will need the FTDI driver on your machine and a terminal emulator that is
> capable of attaching to a tty device (e.g., minicom or screen). If you are
> using a mac, it should already come with the FTDI driver. There may be a
> configuration step that I have forgotten about; please feel free to reply
> back if you run into issues.
>
> On a mac, I attach to the virtual COM device as follows (I use the dterm
> program, but the procedure should be the same with a different tool):
>
> dterm /dev/tty.usbmodem145121 115200 8 n 1
>
> Alternatively, to connect to the 3-wire serial port, I would run dterm like
> this:
>
> dterm /dev/tty.usbserial-A6009JND 115200 8 n 1
>
>
> There is one other means of debugging these issues: you can run the app in
> gdb. To do this, use the "newt run" command:
>
> newt run perph 0
>
> Chris
>
>
> On Mon, May 16, 2016 at 3:10 PM, James Howarth <ja...@gmail.com>
> wrote:
>
> > Hi Chris,
> > Is there a way to hook up to the device while it is running to see the
> > debug messages? So that I can diagnose some of these problems myself?
> > CheersJames
> >
> >
> >
> >
> >
> >
> > On Mon, May 16, 2016 at 12:38 PM -0700, "Christopher Collins" <
> > ccollins@apache.org> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi James,
> >
> > On Mon, May 16, 2016 at 10:49:10AM -0700, James Howarth wrote:
> > > Hi,
> > >
> > > I am trying to get the bleprph example up and running on a Nordic nRF52
> > > PDK. But I can't seem to see the device using the LightBlue app
> running
> > on
> > > my iPhone.
> > [...]
> >
> > Hi James,
> >
> > I'm pretty sure I know what the problem is - the application task's
> > stack is overflowing right out the gate. I'm afraid I have to take the
> > blame for this one; the default logging settings use a lot of stack, and
> > I don't often test with them.
> >
> > The fix is simple: increase the application stack size from 200 to 288
> > words. You can do this by changing apps/bleprph/src/main.c as follows:
> >
> > #define BLEPRPH_STACK_SIZE (OS_STACK_ALIGN(288))
> >
> > This change has already been made to the development branch, but it
> > didn't make it into the previous release. Using the develop branch
> > instead of fixing the bug yourself is also an option; you can do so by
> > changing your project.yml as follows:
> >
> > FROM:
> >
> > repository.apache-mynewt-core:
> > type: github
> > vers: 0-latest
> > user: apache
> > repo: incubator-mynewt-core
> >
> > TO:
> >
> > repository.apache-mynewt-core:
> > type: github
> > vers: 0-dev
> > user: apache
> > repo: incubator-mynewt-core
> >
> > (change the "vers" field).
> >
> > Then upgrade your packages with "newt upgrade", e.g.,
> >
> > [ccollins@iori:~/tmp/myproj]$ newt upgrade
> > apache-mynewt-core
> > Would you like to upgrade repository apache-mynewt-core from
> > 0.7.9-none to 0.0.0-none ? [Yn] y
> >
> > Naturally, this branch is quite unstable!
> >
> > Chris
> >
> >
> >
> >
> >
> >
>
Re: Trouble running bleprh example
Posted by chris collins <ch...@runtime.io>.
Hi James,
Yes, there are two ways. The easier of the two is to use the "virtual COM
port" that is exposed via the USB port. The other way is to attach a three
wire serial cable to the appropriate pins on the nRF52. Either way, you
will need the FTDI driver on your machine and a terminal emulator that is
capable of attaching to a tty device (e.g., minicom or screen). If you are
using a mac, it should already come with the FTDI driver. There may be a
configuration step that I have forgotten about; please feel free to reply
back if you run into issues.
On a mac, I attach to the virtual COM device as follows (I use the dterm
program, but the procedure should be the same with a different tool):
dterm /dev/tty.usbmodem145121 115200 8 n 1
Alternatively, to connect to the 3-wire serial port, I would run dterm like
this:
dterm /dev/tty.usbserial-A6009JND 115200 8 n 1
There is one other means of debugging these issues: you can run the app in
gdb. To do this, use the "newt run" command:
newt run perph 0
Chris
On Mon, May 16, 2016 at 3:10 PM, James Howarth <ja...@gmail.com>
wrote:
> Hi Chris,
> Is there a way to hook up to the device while it is running to see the
> debug messages? So that I can diagnose some of these problems myself?
> CheersJames
>
>
>
>
>
>
> On Mon, May 16, 2016 at 12:38 PM -0700, "Christopher Collins" <
> ccollins@apache.org> wrote:
>
>
>
>
>
>
>
>
>
>
> Hi James,
>
> On Mon, May 16, 2016 at 10:49:10AM -0700, James Howarth wrote:
> > Hi,
> >
> > I am trying to get the bleprph example up and running on a Nordic nRF52
> > PDK. But I can't seem to see the device using the LightBlue app running
> on
> > my iPhone.
> [...]
>
> Hi James,
>
> I'm pretty sure I know what the problem is - the application task's
> stack is overflowing right out the gate. I'm afraid I have to take the
> blame for this one; the default logging settings use a lot of stack, and
> I don't often test with them.
>
> The fix is simple: increase the application stack size from 200 to 288
> words. You can do this by changing apps/bleprph/src/main.c as follows:
>
> #define BLEPRPH_STACK_SIZE (OS_STACK_ALIGN(288))
>
> This change has already been made to the development branch, but it
> didn't make it into the previous release. Using the develop branch
> instead of fixing the bug yourself is also an option; you can do so by
> changing your project.yml as follows:
>
> FROM:
>
> repository.apache-mynewt-core:
> type: github
> vers: 0-latest
> user: apache
> repo: incubator-mynewt-core
>
> TO:
>
> repository.apache-mynewt-core:
> type: github
> vers: 0-dev
> user: apache
> repo: incubator-mynewt-core
>
> (change the "vers" field).
>
> Then upgrade your packages with "newt upgrade", e.g.,
>
> [ccollins@iori:~/tmp/myproj]$ newt upgrade
> apache-mynewt-core
> Would you like to upgrade repository apache-mynewt-core from
> 0.7.9-none to 0.0.0-none ? [Yn] y
>
> Naturally, this branch is quite unstable!
>
> Chris
>
>
>
>
>
>
Re: Trouble running bleprh example
Posted by James Howarth <ja...@gmail.com>.
Hi Chris,
Is there a way to hook up to the device while it is running to see the debug messages? So that I can diagnose some of these problems myself?
CheersJames
On Mon, May 16, 2016 at 12:38 PM -0700, "Christopher Collins" <cc...@apache.org> wrote:
Hi James,
On Mon, May 16, 2016 at 10:49:10AM -0700, James Howarth wrote:
> Hi,
>
> I am trying to get the bleprph example up and running on a Nordic nRF52
> PDK. But I can't seem to see the device using the LightBlue app running on
> my iPhone.
[...]
Hi James,
I'm pretty sure I know what the problem is - the application task's
stack is overflowing right out the gate. I'm afraid I have to take the
blame for this one; the default logging settings use a lot of stack, and
I don't often test with them.
The fix is simple: increase the application stack size from 200 to 288
words. You can do this by changing apps/bleprph/src/main.c as follows:
#define BLEPRPH_STACK_SIZE (OS_STACK_ALIGN(288))
This change has already been made to the development branch, but it
didn't make it into the previous release. Using the develop branch
instead of fixing the bug yourself is also an option; you can do so by
changing your project.yml as follows:
FROM:
repository.apache-mynewt-core:
type: github
vers: 0-latest
user: apache
repo: incubator-mynewt-core
TO:
repository.apache-mynewt-core:
type: github
vers: 0-dev
user: apache
repo: incubator-mynewt-core
(change the "vers" field).
Then upgrade your packages with "newt upgrade", e.g.,
[ccollins@iori:~/tmp/myproj]$ newt upgrade
apache-mynewt-core
Would you like to upgrade repository apache-mynewt-core from 0.7.9-none to 0.0.0-none ? [Yn] y
Naturally, this branch is quite unstable!
Chris
Re: Trouble running bleprh example
Posted by James Howarth <ja...@gmail.com>.
Hi Chris,
Thanks. I'll try that.
CheersJames
On Mon, May 16, 2016 at 12:38 PM -0700, "Christopher Collins" <cc...@apache.org> wrote:
Hi James,
On Mon, May 16, 2016 at 10:49:10AM -0700, James Howarth wrote:
> Hi,
>
> I am trying to get the bleprph example up and running on a Nordic nRF52
> PDK. But I can't seem to see the device using the LightBlue app running on
> my iPhone.
[...]
Hi James,
I'm pretty sure I know what the problem is - the application task's
stack is overflowing right out the gate. I'm afraid I have to take the
blame for this one; the default logging settings use a lot of stack, and
I don't often test with them.
The fix is simple: increase the application stack size from 200 to 288
words. You can do this by changing apps/bleprph/src/main.c as follows:
#define BLEPRPH_STACK_SIZE (OS_STACK_ALIGN(288))
This change has already been made to the development branch, but it
didn't make it into the previous release. Using the develop branch
instead of fixing the bug yourself is also an option; you can do so by
changing your project.yml as follows:
FROM:
repository.apache-mynewt-core:
type: github
vers: 0-latest
user: apache
repo: incubator-mynewt-core
TO:
repository.apache-mynewt-core:
type: github
vers: 0-dev
user: apache
repo: incubator-mynewt-core
(change the "vers" field).
Then upgrade your packages with "newt upgrade", e.g.,
[ccollins@iori:~/tmp/myproj]$ newt upgrade
apache-mynewt-core
Would you like to upgrade repository apache-mynewt-core from 0.7.9-none to 0.0.0-none ? [Yn] y
Naturally, this branch is quite unstable!
Chris
Re: Trouble running bleprh example
Posted by Christopher Collins <cc...@apache.org>.
Hi James,
On Mon, May 16, 2016 at 10:49:10AM -0700, James Howarth wrote:
> Hi,
>
> I am trying to get the bleprph example up and running on a Nordic nRF52
> PDK. But I can't seem to see the device using the LightBlue app running on
> my iPhone.
[...]
Hi James,
I'm pretty sure I know what the problem is - the application task's
stack is overflowing right out the gate. I'm afraid I have to take the
blame for this one; the default logging settings use a lot of stack, and
I don't often test with them.
The fix is simple: increase the application stack size from 200 to 288
words. You can do this by changing apps/bleprph/src/main.c as follows:
#define BLEPRPH_STACK_SIZE (OS_STACK_ALIGN(288))
This change has already been made to the development branch, but it
didn't make it into the previous release. Using the develop branch
instead of fixing the bug yourself is also an option; you can do so by
changing your project.yml as follows:
FROM:
repository.apache-mynewt-core:
type: github
vers: 0-latest
user: apache
repo: incubator-mynewt-core
TO:
repository.apache-mynewt-core:
type: github
vers: 0-dev
user: apache
repo: incubator-mynewt-core
(change the "vers" field).
Then upgrade your packages with "newt upgrade", e.g.,
[ccollins@iori:~/tmp/myproj]$ newt upgrade
apache-mynewt-core
Would you like to upgrade repository apache-mynewt-core from 0.7.9-none to 0.0.0-none ? [Yn] y
Naturally, this branch is quite unstable!
Chris