BBC micro:bit Espruino v2.05 quite unstable?

Posted on
  • Hi folks,

    after many months of inactivity, I thought I'd give Espruino on BBC micro:bit another try and installed Version v2.05.

    It worked in the very beginning (when doing some simple one- or few-liners from the Espruino Web-IDE), but after a few minutes I already got my first disconnect. Such sudden disconnects continued to occur - sometimes I even had to reset the micro:bit before it reappeared in the WebBT list of BT devices - but, initially, I thought, it would be my Mac (macOS is known for its horrible BT support) until I found the first weird pattern on the LED matrix.

    Now, I'm quite sure that it's the micro:bit which crashes after a few minutes (usually less than 5) of activity.

    Do you have any experiences with that version? As I remember, Espruino ran stable on the micro:bit several months ago (but I can't tell you the version number)

    Do you know, which version runs stable?

    Thanks in advance for any response!

    Kind regards from Germany,

    Andreas Rozek

  • Ok,

    I now have some code which crashes the BBC micro:bit within seconds:

    var Gfx = Graphics.createArrayBuffer(5,5,1);
    Gfx.flip = function () { show(this.buffer); };
    
    function currentXYZ () {
      return [2,0,5];
    }
    
    function updateDisplay () {
      var XYZ = currentXYZ();
    
      Gfx.clear();
      Gfx.drawLine(0,4, 0,4-Math.max(0,Math.min(4,XYZ[0])));
      Gfx.drawLine(2,4, 2,4-Math.max(0,Math.min(4,XYZ[1])));
      Gfx.drawLine(4,4, 4,4-Math.max(0,Math.min(4,XYZ[2])));
      Gfx.flip();
    }
    setInterval(updateDisplay,100);
    

    Does anybody have any idea why?

    [EDIT] if the WebBT connection is kept, but the display runs havoc, the IDE's terminal sometimes issues New interpreter error: MEMORY_BUSY. Does this message help you?

    Thanks in advance for your effort!

    Kind regards,

    Andreas Rozek

  • Here are the results of process.env and process.memory()

    >process.env
    ={
      VERSION: "2v05",
      GIT_COMMIT: "990dac35",
      BOARD: "MICROBIT",
      FLASH: 262144, STORAGE: 2048, RAM: 16384,
      SERIAL: "a7508229-3abf344e",
      CONSOLE: "Bluetooth",
      MODULES: ""
     }
    >process.memory()
    ={ free: 276, usage: 24, total: 300, history: 11,
      gc: 0, gctime: 2.99072265625, blocksize: 12, "stackEndAddress": 536884560, flash_start: 0,
      "flash_binary_end": 258580, "flash_code_start": 260096, flash_length: 262144 }
    > 
    
  • Hmmm, I made some progress...

    Adding an invocation of process.memory() to the beginning of updateDisplay made my few lines of JS run stable for many more seconds - but in the end it still crashed...

    Is there any chance to work with Espruino on BBC micro:bit? Or does it simply have too little memory?

    With greetings from Germany,

    Andreas Rozek

  • if show() is slower than 100ms it probably gets queued up, try to increase the interval

  • Brilliant idea,

    unfortunately, there must be more that goes wrong:

    I order to make it right from the very beginning, I tried to replace setInterval by setTimeout within updateDisplay (that saves me the "trial-and-error" approaches to find the proper interval whenever I change s.th. within the loop)

    The result looked like this:

    var Gfx = Graphics.createArrayBuffer(5,5,1);
    Gfx.flip = function () { show(this.buffer); };
    
    function currentXYZ () {
      return [2,0,5];
    }
    
    function updateDisplay () {
      var XYZ = currentXYZ();
    
      Gfx.clear();
      Gfx.drawLine(0,4, 0,4-Math.max(0,Math.min(4,XYZ[0])));
      Gfx.drawLine(2,4, 2,4-Math.max(0,Math.min(4,XYZ[1])));
      Gfx.drawLine(4,4, 4,4-Math.max(0,Math.min(4,XYZ[2])));
      Gfx.flip();
      
      setTimeout(updateDisplay,100);
    }
    updateDisplay();
    

    but did not work at all!!!! (when entered into the Editor area of the IDE and sent to RAM from there - which implies a "reset" before uploading)

    So, I commented the setTimeout and tried again - and now I got the following message:

    >Uncaught Error: Too much recursion - the stack is about to overflow
     at line 4 col 41
      Gfx.drawLine(0,4, 0,4-Math.max(0,Math.min(4,XYZ[0])));
                                            ^
    in function "updateDisplay" called from line 1 col 15
    updateDisplay();
                  ^
    Execution Interrupted
    > 
    

    Now, I'm completely lost (I do not have any pretokenization or other kind of minification switched on)

    What makes it even worse: after crashing, I have to push the reset button of my BBC micro:bit in order to let it reappear in the scanned list of BT devices. Sometimes even several resets are necessary before I'm able to upload any JS code again....)

    I'm now also trying to figure out whether the device itself is broken (which could theoretically be the reason for all these weird problems)
    [UPDATE] my second micro:bit behaves the same...

    Any ideas?

  • It's extremely weird:

    if I change the last line of the above code to

    setTimeout(updateDisplay,1000);
    

    the BBC micro:bit does no longer hang up immediately after upload - but it also does not start unless a press RETURN once from within the Terminal area.

    There must be s.th. going terribly wrong here...

  • My conclusions so far:

    1. setTimeout seems to be terribly broken (I could not get it working at all)
    2. code sent from the IDE (to RAM) should not be started immediately after uploading (the IDE seems to expect some response from the connected device which it might not receive otherwise). But you will have to use setInterval for that purpose (as setTimeout is broken, see above)
    3. the graphics library also seems to have its problems (drawString seems to work fine, but drawLine seems to be flaky)

    My updated code

    function currentXYZ () {
      return [2,0,5];
    }
    
    var Buffer;
    function drawBar (x,Length) {
      for (var i = 0; i <= Length; i++) {
        var Bit = x+(4-i)*5;
        Buffer = Buffer | (1 << Bit);
      }
    }
    
    function updateDisplay () {
      var XYZ = currentXYZ();
    
      Buffer = 0;
      drawBar(0,Math.max(0,Math.min(4,XYZ[0]))­);
      drawBar(2,Math.max(0,Math.min(4,XYZ[1]))­);
      drawBar(4,Math.max(0,Math.min(4,XYZ[2]))­);
      show(Buffer);
    }
    setInterval(updateDisplay,100);
    

    runs fine for much longer now than any other variant did.

    With greetings from Germany,

    Andreas Rozek

  • Hmm, that doesn't sound good. Espruino's pretty limited on the micro:bit (there's only ~6kB of RAM total) - I guess it's possible that something has grown and used up more of the available RAM so there isn't enough stack for it to work reliably?

    How does 2v04 work?

  • Hello Gordon,

    I tried 1.95 (the latest one from the list of available downloads) and that behaved like 2.05.

    The misbehaviour of setTimeout sounds critical, but graphics.drawLine might "just" have a hidden memory leak from what I found by my little tests.

    Oh, and, meanwhile, my own implementation of "drawLine" crashed as well (on the micro:bit, on Calliope it's still running - but presumably because that was started much later) - I will now try to increase interval length.

    What also sounds weird is that both devices sometimes suddenly disconnect themselves from the WebBT connection.

    With greetings from Germany,

    Andreas Rozek

  • Increasing interval length does not really help - both boards will eventually hang up.

    Additionally: when trying to connect after a reset, I also often get the error message "Unable to retrieve board information. Connection Error?"

    Even if that is followed by "Connected to Web Bluetooth, Espruino MICROBIT (No response from board)" that connection appears to be inoperable.

  • I meanwhile found the old firmware distributions and tried 1.85 - but apart from a different API (compared to 2.05) I often encounter communication failures (lost characters when uploading) which prevent me from testing...

    [Update]
    Communication errors can be solved by disabling "Reset before Send", but then the program runs havoc almost immediately => the old version behaves even worse than the new one

    This is strange as I made my first experiments with Espruino on BBC micro:bit with 1.85 - and I can't remember these problems (my boards are still the same and weren't touched since then).

  • Oh, what I found in my old notes from 1.85: Espruino on BBC micro:bit hangs quite soon when trying to run the ticker you mentioned in your video about Espruino on the micro:bit...

    Thus, it seems to have been unstable in those days as well...

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

BBC micro:bit Espruino v2.05 quite unstable?

Posted by Avatar for Andreas_Rozek @Andreas_Rozek

Actions