Firmware v2.03 of Puck.js fails with an internal NRF code error on BluetoothRemoteServer.gatt.connect();

Dear Puck.js developers,

Thanks for the great work, I'm impressed by the Puck.js quality.

If I use the firmware v2.03 (I reverted to v2.02 for now) when I perform a simple connection of this kind :

 NRF.requestDevice({ filters: [{ services: ['4300'] }] }).then(function(device) {
      console.log("Device found !");
      return device.gatt.connect();
    }).then(function(g) {
      console.log("Now gatt.getPrimaryService");
      gatt = g;
      return gatt.getPrimaryService("4300");
    }).then(function(service) {
      return service.getCharacteristic("53415554-4552-2D2D-4241-53454C2DCAFE");
    }).then(function(characteristic) {
      console.log("Writing !");
      //glob_characteristic = characteristic;
      digitalPulse(LED3,1,[10,200,10,200,10]);
      characteristic.writeValue([JSON.stringify({"chan" : 6, "v" : global_counter++})]);
      gatt.disconnect();
    }).then(function() {
      console.log("Write finished !");
      digitalPulse(LED2,1,[10,200,10,200,10]);
      gatt.disconnect();
      console.log("Done!");
      busy=false;
    }).catch(function(e) {
      digitalPulse(LED1,1,10);
      console.log("ERROR",e);
      busy=false;
    });

I get during gatt.connect an error message on the console:

clearTimeout(undefined) cannot be used, please use clearTimeout();

I don't do any clearTimeout myself, so it must be some of NRF code that is doing this.

Another error that I could workaround is that if I return the promise of the line

characteristic.writeValue([JSON.stringify({"chan" : 6, "v" : global_counter++})]);

And don't forcibly disconnect, then the write while effective on the BLE device accessed, will take ages to complete ( like 15 seconds ) and it won't really complete it will go in catch() for a Disconnected error.

Cheers,

Hi - yes, unfortunately the clearTimeout from requestDevice error was introduced in 2v03. It's now fixed if you use a 'Cutting Edge' build, or you can work around it for now just by using NRF.findDevices.

Please can you paste up the exact code that causes the second error so I can try it out here and be certain it's the same? I'm pretty sure I'm using exactly the code pattern you're referring to without issues on 2v03.

Do you also get the error on 2v02? I guess it's possible it's actually related to the device you're connecting to.

Thank you very much for this info, I'll give a try to a Cutting Edge build then.

The exact code where this happen is :

var global_counter = 0;
var gatt;
var busy = false;


function write_ble() {
  LED1.write(false);
  
  if (busy) {
    digitalPulse(LED1,1,[10,200,10,200,10]);
    return;
  }
  busy = true;
  
    NRF.requestDevice({ filters: [{ services: ['4300'] }] }).then(function(device) {
      console.log("Device found !");
      return device.gatt.connect();
    }).then(function(g) {
      console.log("Now gatt.getPrimaryService");
      gatt = g;
      return gatt.getPrimaryService("4300");
    }).then(function(service) {
      return service.getCharacteristic("53415554-4552-2D2D-4241-53454C2DCAFE");
    }).then(function(characteristic) {
      console.log("Writing !");
      digitalPulse(LED3,1,[10,200,10,200,10]);
      return characteristic.writeValue([JSON.stringify({"chan" : 6, "v" : global_counter++})]);
      //gatt.disconnect();
    }).then(function() {
      console.log("Write finished !");
      digitalPulse(LED2,1,[10,200,10,200,10]);
      gatt.disconnect();
      console.log("Done!");
      busy=false;
    }).catch(function(e) {
      digitalPulse(LED1,1,10);
      console.log("ERROR",e);
      busy=false;
    });

}

setWatch(write_ble, BTN, { edge:"rising", repeat:true, debounce:50 })

It generates the following output :

 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v00 (c) 2018 G.Williams
>
Device found !
Now gatt.getPrimaryService
Writing !
[... After ~15 secs ...]
ERROR Disconnected

It looks like it takes ~15 seconds to go to the catch and never ends in "Write finished !". I tested to write the property on the other device with the LightBlue Explorer App on iOS 13 with an Iphone SE and it doesn't look like to hang in the same way, but implementation might be totally different.

The other BLE device is also developed by myself and colleague it's a Linux Embedded with a Laird Bluetooth Module BT830 https://www.lairdconnect.com/wireless-modules/bluetooth-modules/bluetooth-42-and-40-modules/bt830

We use a somewhat quirky implementation of BLE for now that seems to work ok with the BLE mobile apps : https://github.com/comarius/bunget but indeed it definitely might be there. I'll debug it further.

Ahh, ok - I just changed the UUIDs to those for Nordic UART and everything works perfectly.

I'd be pretty sure then that the Bluetooth device you're connecting to advertises that the characteristic does 'write with response', but doesn't actually send a response back. Espruino waits for a response and after 15 secs it times out and disconnects.

You might be able to hack around it with:

...
   }).then(function(characteristic) {
      console.log("Writing !");
      digitalPulse(LED3,1,[10,200,10,200,10]);
      characteristic.properties.writeWithoutResponse = true; // override BLE characteristic data
      return characteristic.writeValue([JSON.stringify({"chan" : 6, "v" : global_counter++})]);
    }).then(function() {

Thank you. I tried to define the property as writeWithoutResponse from the BLE server running on linux and it didn't work in my first try, but this was due to a mistake. When I set the property as such on the remote device and I set it as well in Espruino it works. When I try to force writeWithoutResponse while the other serves a read + write properties then write are not accepted by the comarius/bunget stack.

Note that if I write and disconnect each time as proposed in my code it puts the NRF stack in error and triggers a reboot after 3/4 writes done with 5seconds interval.

So not disconnecting each time and using a writeWithoutResponse prop solved it for my case.