Hi Jacob,
On Mon, Jan 23, 2017 at 08:36:40PM -0700, Jacob Rosenthal wrote:
> dfu service is advertised and present.. though only while in loader, not
> while in app? Is this normal?
Your second-stage app needs to advertise on the BLE network. I would
say this is a documentation screw up on my part. The docs suggest using
bleprph as the loader and splitty as the app. This setup doesn't make a
lot of sense, because the splitty app doesn't do anything with the BLE
stack. As a consequence, you'll only be able to connect to your device
when it's in loader-only mode.
I am going to create and push an app suitable for BLE in split mode.
This app will be pretty much identical to bleprph, except it does not
function as a loader. Of course, the user can add extra functionality
to it.
Unfortunately, split functionality appears to be broken at the moment.
I'll push the app now, and verify that it still works after the split
issues are resolved.
> Connection profiles:
> ble1: type=ble, connstring='nimble-bleprph'
> serial1: type=serial, connstring='/dev/tty.usbmodem1411'
> Jacobs-MacBook-Air:mynewt-hr-observer jacobrosenthal$
[...]
> [jacobrosenthal@localhost ~]$ newtmgr image list -cble1 -ldebug -t
> 2017/01/21 01:03:09 [DEBUG] BLE Connection devaddr:[]
> 2017/01/21 01:03:09 dev: hci0 up
> 2017/01/21 01:03:09 [DEBUG] goroutine 1 [running]:
> mynewt.apache.org/newt/newtmgr/vendor/mynewt.apache.org/newt/util.NewNewtError(0xa07ead,
[...]
I think the problem here is that you don't have permissions to access
the bluetooth hardware in your machine. The easy workaround is to run
newtmgr as root:
sudo $GOPATH/bin/newtmgr <...>
The gatt library that newtmgr seems unconventional. It circumvents
the BlueZ daemon and uses the kernel to interact with the bluetooth
hardware. This is why it requires extra privileges. Just to reiterate,
the gatt library is only a temporary solution, so the need to run
newtmgr as root should go away soon.
Chris
