I wonder if this issue is related to other controllers that we have had issues with. Try disabling Data Length Extension. Set BLE_LL_CFG_FEAT_DATA_LEN_EXT in net/nimble/controller/syscfg.yml to 0
Let us know if that changes anything. > On Apr 16, 2017, at 6:13 PM, Jacob Rosenthal <jakerosent...@gmail.com> wrote: > > 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.
