On Sun, Apr 16, 2017 at 5:46 PM, Christopher Collins <ch...@runtime.io> wrote:
> Welcome to return code hell :). The status=8 is actually a Bluetooth > error code, not a NimBLE host error code. In this case, the controller > belonging to the destination device has indicated a disconnect reason of > 8, which translates to "supervision timeout." In other words, your PC's > controller unexpectedly went silent, so the NimBLE device was forced to > drop the connection. > Oh interesting. > > The GATT library (what newtmgr uses for BLE) is a bit sketchy, so it's > hard to tell who as at fault. What controller are you using to send the > newtmgr command (e.g., built-in Bluetooth radio)? > > This is the build in radio on my a1466 2012 macbook air in fedora. Interestingly enough this happens on my node port on osx as well, which is why I went back to trying to get newtmgr under linux working first. > Do you have any luck with a smaller newtmgr command (e.g., echo)? The > image upload command is especially troublesome because it causes the > destination device to perform a flash erase operation. This causes the > MCU to stall, which can lead to supervision timeouts. I believe the > newtmgr tool uses fairly lenient connection settings for this reason, > but this could still be the problem, especially on the nRF51. > > All other commands have worked great so far. > You could try connecting to the NimBLE device with a known good setup > such as the Lightblue app on OS X or an iphone. Then, subscribe to the > newtmgr characteristic and try writing a value to the same > characteristic. If the connection stays up and you get a notification > from the NimBLE device (newtmgr response), then I would suspect > something on the PC side. > Im just writing 0x01 and the connection stays up, but I dont seem to get any response.
