Search results for:

Yes, that was the "Disconnect Alert" I mentioned. This is shown in a popup coming from LightBlue. Sorry for being unclear.

Yes, no problem from a PC. There was never a timeout when connecting from the Web IDE. And yes, as mentioned in the first post I am using 1v91. On both Pucks.

Hi @Gordon, thanks for your answers!

I think the timeout is around 2 minutes. It happens whether I write from time to time or not.

I am pretty sure that the problem is that the connection breaks down: I checked from the iPhone with LightBlue and saw the peripheral Puck listed there after a while. And I was also able to connect to it from LightBlue. I think that is evidence that the connection between the two Pucks is no longer existing.

Another interesting observation is that when doing the connection from LightBlue as a central I see the same problem: After about 2 minutes I get a "Disconnected Alert" from LightBlue. So for whatever reason the connection is disconnected from the peripheral after 2 minutes (or so).

I agree that it is necessary to handle the breakdown of connections. But on the other hand having a connection for more than 2 minutes is probably important for a lot of applications. Especially since the reconnect takes about 10-15 seconds.

I like the idea of using gatt.connected to check upfront if the connection is still existing. However in my case it still returns true, although writing fails. Even with a regular timer it still returns true at a point where the connection is no longer existing (because LightBlue lists the peripheral Puck again as advertising).

Hi,

I have a problem that when connecting two Pucks together using BLE, there seems to be some sort of timeout going on which I did not program. I am using 1v91.

I have a central and a peripheral Puck. Here is the code for the peripheral, which is pretty vanilla:

var g_value = 0;

function onInit() {
  NRF.setServices({
    "A4AF09E7-5BC2-46F6-BA08-DA8E0982D84D" :
    {
      0x2A6E:
      {
        readable: true,
        writable: true,
        notify: true,
        value : g_value,
        onWrite : function(evt)
        {
          digitalPulse(LED2, true, 10);
          g_value = evt.data[0];
        }
    }}});
}

Here is the code for the central:

var g_gatt = false;
var g_characteristic = false;
var g_counter = 0;

function connect(nextStep) {
    console.log("Requesting device");
    NRF.requestDevice({
        filters: [{
            name: 'Puck.js 2061'
        }]
    }).then(function(device) {
        console.log("Connecting to GATT");
        return device.gatt.connect();
    }).then(function(gatt) {
        console.log("Connecting to service");
        g_gatt = gatt;
        return g_gatt.getPrimaryService("A4AF09E7-5BC2-46F6-BA08-DA8E0982D84D");
    }).then(function(service) {
        console.log("Getting characteristic");
        return service.getCharacteristic("0x2A6E");
    }).then(function(characteristic) {
        console.log("Calling next step");
        g_characteristic = characteristic;
        nextStep();
    }).catch(function() {
        console.log("Error connecting");
    });
}

function write(value) {
    if (!g_characteristic)
        connect(function() {
            write(value);
        });
    else
    {
        console.log("Writing ", value);
        g_characteristic.writeValue(value).catch(function() {
            g_characteristic = false;
            write(value);
        });
    }
}

function onInit() {
    setWatch(function() {
        write(g_counter++);
    }, BTN, {
        edge: "rising",
        debounce: 50,
        repeat: true
    });
}

Again, nothing special. So when I first press the button on the central, it will connect to the peripheral and write the value. The peripheral will shortly blink green. Connecting of course takes a while, but subsequent writes will be fast. So far so good.

The problem is that after letting the Pucks rest for a while, the write will fail. Then the catch will come into play and reconnect. So there seems to be some kind of inactivity timeout somewhere. I did not find any documentation for that or any hint how I can avoid that. Any ideas?

The question is if there is a better way to send integers (preferably not just 8 bits) than sending them as a character and reconverting to an integer? Also, the way I handle the !g_characteristic case feels pretty clumsy. Any better idea on how to handle that? Generally, any hint on how to program the central more elegant is welcome.

Thanks!

Hi Gordon, just tested the fix, works perfectly now, thanks!

I just flashed on my Puck and it works very nicely, no problem. Uploaded from the same app.

Very nice update, I like the NRF.setLowPowerConnection (note that the announcement above wrongly says E.setLowPowerConnection() ), and the hwRand fix especially! Thanks! Also the getAddress() is very nice, I needed that for some kind of self organization of a swarm of puck. So far I configured this in the boot code, but being able to ask for it is great!

Very cool, works like a charm! Finally we can do HTML based control interfaces from IOS devices!!!

1. I use a little cable between the GND and RST pads. Isn't that pretty much the same? Seems slightly more elegant?
   
2. That will be so great!!!
   
   

I would also certainly be very interested in the Puck Jacket. Especially if it has the pogo pins. If someone produces it, I will be in!

It happened to me with various code snippets as far as I know. As simple as setting an interval which blinks an LED.

For me it happens without the BLE message. I actually use a little cable between reset and GND to do the reset. More convenient than popping the battery. And maybe less stressful for the battery holder...

Hi, it seems using the mentioned function crashes the Puck reliably. I encountered this on two different Pucks. I also tried writing (using poke8) to the task register directly, same effect. So something seems to be wrong there. Is anyone else seeing this? Could this be some missing initialization? Some wrongly handled interrupt?

So I think we have a pattern here: It seems this happens at least on some pucks from time to time. The more you use save() the more often it happens.

I never again got the weird display. But I got the disconnect on save():

>save()
=undefined
Erasing Flash...
Disconnected

I then did the peeks and here is the result:

>peek32(479232)
=4294967295
>peek32(479236)
=4294967295

I did nothing special, just uploaded code a couple of times.

Agreed, awesome work. Thanks! Enjoy your vacation a lot. Looking forward to buying more Pucks...

Hi @Gordon, would that only apply to @ChristianW's problem or also to mine?

+1

Okay, I will do that!

Hi, my Puck had the same thing happening again on the Puck which was showing it initially, just yesterday. Actually at some point I had it happening on all three. I think I did nothing special, just upload new code. Two things which are just impressions without being sure:

• I think it never happened with 1.89, just with 1.90
  
• I got the feeling that it happens after a number of uploads. Then if you erase it's gone for a while and then comes back.
  
  

Just wanted to stress that there is no evidence about the impressions above. I was not able to reproduce it systematically.

Thanks!

One more things: Doing a dump() in that situation showed first the normal code and then an endless line of those Yen characters being dumped to the Web UI. It looks like a missing '\0' character at the end or so. Again, just an impression.

You are welcome!

For gcc what I did was actually to just download the arm gcc binary distribution, unpack to some location and put it in the path. That way I can have multiple different versions and can just set the path from some project related build script.

Actually I never used the 'save on send'. So I don't think that was the reason for the corruption. Also 'E.setBootCode()' also crashed immediately, so I couldn't even type the reset(). But for now everything seems to be fine. I'll observe if the same thing happens again. But it's good to have a way out, should it ever happen again.

Thanks!

Brilliant!!!! That did the trick. I did the following according to the location of the saved code:

flash.erasePage((120 - 3) * 4096)
flash.erasePage((120 - 2) * 4096)
flash.erasePage((120 - 1) * 4096)

And now everything is back to normal. Thanks a lot!

Maybe some "eraseCode" function might be helpful. Unless it's there and I just overlooked it like the "load" function.

Yes, I tried that but it does not change anything. The thing is, I can interact with it just fine. Just when trying to save to flash or trying to read from flash it acts up. I was thinking about using the Flash module to erase things, but don't really know the address to erase and what to write there.

More information: When typing load (which I just learned about :-) ) it outputs the following:

>load()
=undefined
Invalid saved code in flash!
Uncaught SyntaxError: Got ?[255] expected EOF
 at line 1 col 1
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ...

Seems to support my thesis...

Load is cool! I also overlooked it...

Hi @Gordon,

one of my Pucks has started acting weird: Suddenly when saving code it crashed. Since then after typing reset() it will output the following:

|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v90.1890 Copyright 2016 G.Williams
Uncaught SyntaxError: Got ?[255] expected EOF
 at line 1 col 1
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ...
^
>

Also whenever I try to write to the flash memory it will crash. Either by typing save() or by using E.setBootCode(). My only theory is that either the flash memory is damaged or that it was somehow corrupted and the Puck firmware cannot deal with that.

Note that except for those things it works fine. I also tried to replace the firmware with a new version, but that did not help. I am using the newest firmware. The self test is also okay, but I guess that really only checks for shorts between the exposed pins. Any idea how to check if the flash is damaged? If that's the case any idea how to fix / workaround that. Maybe by not using damaged pages?

Thanks!