-
Some interesting extra findings:
Of the 3 devices I have, 1 doesn't disconnect after programming, but the other two do. Interestingly, the one that doesn't disconnect is running 2v05, and the two that do are running 2v04. Coincidence?
I don't think there is anything I have done to influence configuration/state on any of them. I have only run code from RAM. Maybe there is some bonding info or something client side where my Mac is doing something different for different devices based on history of how I have interacted with them.
Another difference occurred when I tried a Hard Reset to understand if there may be any state impacting behaviour (as described https://www.espruino.com/Pixl.js); interestingly the 2v04 devices do go through the process as described, but the 2v05 device just goes on to displaying "BOOTING" after the 10s.
Simon
-
Hi,
A few questions about BLE connection and download that I couldn't find answers for in the various (very good) BLE pages - related to logic I'm implementing for switching between the device active and debug/download mode. Just want to understand the "right" way to do things:
When using the CLI to download a program (> espruino file.js), it automatically finds/connects, but seems to stay connected after CLI has completed (on MacOS). Is there an option or preferred way to make it disconnect BLE once the application is downloaded?
On the device, how can you see if you are currently connected? I can happily hook NRF.on('connect', ... ) and NRF.on('disconnect', ...), but want to just ask the question e.g. I might already be connected when application starts, so won't have seen any events. Was expecting Bluetooth.connected() or NRF.connected(), but they are not available. What is the preferred way to understand (in particular when the application starts running) what the BLE connection state is?
If I do want to force a disconnect from the device side as part of my application once programming is complete (presumably using NRF.disconnect()), what is the best/preferred approach? Having disconnect as the last line in the file is probably not appropriate, as all actions of loading have probably not completed (maybe there is an onLoad() equivalent?). How do you elegantly disconnect from the device side after a programming event?
Thanks!
Simon
I had killed all pairings, so didn't think it could be that. However, I tracked down what was up:
I had a chrome window open somewhere from a few days back with the IDE loaded. It or the web BLE stack must have been hanging on to the device whenever it saw it turn up! So kill that and it is working as expected now.
On the BOOTING comment, yes, assume that is working fine, just didn't match the docs. I updated a 2v04 to 2v05 in the process to check, and all continued to work fine which helped confirm it was likely client side.
The NRF.getSecurityStatus().connected call is working fine too, and disconnect() logic is not needed now I understand the correct behaviour is it to disconnect anyway.
Thanks for your all your help!
Simon