Avatar for mike_k


Member since Oct 2018 • Last active Aug 2020
  • 2 conversations

Most recent activity

  • in ESP32
    Avatar for mike_k

    There has been a problem with wifi for all versions following espruino_2v00.42 (due to espressif's SDK 3.1) . Feel free to follow along here https://github.com/espruino/Espruino/iss­ues/1571. I don't think a stable wifi release has been cut yet, as I just tried the latest and I'm seeing the same results. @Wilberforce and @JumJum have been making good progress though!

  • in ESP32
    Avatar for mike_k

    Also, I've used the same code on both the an official espruino board and an esp8266 without Chrome throwing any error. (For reference). Thank you!

  • in ESP32
    Avatar for mike_k

    I'm using the exact example here on port 3030 to create a websocket server on an esp32 and when I attempt to connect to the server via a Chrome browser client I receive the error below:

    ws server connection error

    The js code used in Chrome is extremely simple:

    new WebSocket('ws://')

    The weird part is the callback for when a websocket connection opens is called on the espruino websocket server:

    server.on('websocket', function(ws){
      console.log('websocket opened!');

    but right after, Chrome throws the error shown in the image above, and I'm not able to send or receive messages.

    The current espruino version info is:

      VERSION: "2v00.42",
      GIT_COMMIT: "1a1fd36",
      BOARD: "ESP32",
      FLASH: 0, RAM: 524288,
      CONSOLE: "Serial1",
      EXPTR: 1073483756

    Thank you in advance!

  • in ESP32
    Avatar for mike_k

    @Gordon you are awesome. I am unbelievably grateful that you jumped on this bug so quickly. I will try out the latest build later on tonight. Thank you again everyone!

  • in ESP32
    Avatar for mike_k

    I don’t think I explained myself well enough in my last post above. My apologies.

    Every call I make to E.openFile is always followed by an f.close. This works consistently, until a call to E.openFile returns undefined, and i can no longer open and close files, respectively. The above example is explicitly showing the product of this - after running E.openFile, nothing is opened, i.e. undefined is returned (The 3rd-4th lines of the last image demonstrates the execution of the var f, and shows that undefined was assigned to it instead of a file object). Again, I open and close files sequentially, every time I open a file that actually returns a file object, I close right after.

    I hope that explains it better. As for the process.memory().free call, I am very grateful you found that work-around! I just hope I can find out why, after opening and closing a file multiple times, and making sure every file I open is indeed closed directly after, eventually causes E.openFile to no longer return anything.

    I think the first step in determining why the returned undefined value occurs is to explicitly throw an Out Of Memory error in the C code on the line of code that you’ve provided so it can much more easily be determined that we are simply out of memory vs some other underlying issue:


    Or, we should make E.openFile configurable in order to enable error throwing when we are out of memory. Again, this will allow developers to choose how to handle and discern whether or not a give api function isn’t working correctly because of lack of memory, or a different bug.

    I’d love to hear your thoughts on this, because it wouldn’t cause a lot (if any) of overhead and it gives the developer the choice of how they want to deal with Out Of Memory issues, whether it be via an undefined return value (like it currently does) or an actual thrown error.

    Thank you again @Wilberforce!!

  • in ESP32
    Avatar for mike_k

    @Wilberforce that is a solid work-around for now! I am able to execute write operations slightly more predictably now. But disappointingly, the ability to E.openFile still seems to lock up and return undefined after multiple read and write operations:

    Cannot openFile after a while

    If I can overcome this last lockup issue that would be excellent! Thank you again!

  • in ESP32
    Avatar for mike_k

    Thank you again for your attempt at mitigating the bug that I am facing. There are a few things I would like to cover regarding the code that you've provided, but it's important to note upfront that your changes still result in the same error that I am facing, so I would definitely call it a bug at this point.

    First off, your code has an unrecoverable syntax error on line 13:
    error in your code

    This was an easy fix, just had to find the syntax issue.

    Secondly, accessing a property on an object, regardless if it's global or not, does not need to be accessed via bracket notation just because it has a number at the end, so this may mislead someone to think this makes a difference stumbling upon this issue:


    Like you stated, writing anything like the following is not idiomatic javascript, and as you stated, the code involves a security risk if there is anything interpolated into the string in the first argument (because it uses eval under the hood), so I wouldn't do this either (but for the purposes of finding this fs related bug, I will leave it for now):

    potential security issue and not idiomatic

    Without further ado, Here is a screenshot of the resulting syntactically correct code randomly failing to write 14 / 100 files:

    14 writes failing

    I think the most frustrating part is that this issue occurs on both writes and reads (When reading, somethings undefined is returned even though using fs.statSync showns that the file exists and has length).

    Touching upon your other statement:

    your other statement

    I never stated that fs has a open or close function:


    I was stating that I had also attempted an alternative way of writing a file, specifically the functionality below that I did not post originally, because I had stated that "The same problems occur" intermittently:

    var file = E.openFile('test_f', 'w');
    file.write("wrote data");

    Thank you again for all your help. I do not think there is any solution to this bug without looking under the hood, so I will file an issue on the github repo and then start digging.

    I have written error handling code that retries writing on error, but even then, sometimes it completely stops allowing me from writing to any file what-so-ever, until I execute a full reboot (which won't work in my control flow). So In the end, I think I'm going to have to look at the C code to see if there is anything suspicious occurring.

  • in ESP32
    Avatar for mike_k

    I am emphasizing that I am writing to a brand new file, I’ve tried all three possible ways of uploading, including uploading via console, uploading via the Upload button, as well as uploading via the Espruino command line tool, there are no other ways to upload. I’ve even wrapped the above code in an anonomyous function and executed, even with a setTimout to allow ANY other running scripts to load.

    I think @Gordon should give his opinion. If he thinks This is developer error, I will gladly continue to debug. I’ve reached a point where the only thing left for me to do is post on the forum, which I will always hold out as long as possible to do. but I’ve reached a point where i’ve narrowed down the problem and provided a example script that demonstrates the issue consistently.

    If you feel like this is still developer error, please let me know, and I will forgo the above conversation and move to a different library. Again, thank you for your help.

    Also, the first device I began tinkering with was an Espruino board because I wanted to support @Gordon ‘s work, because I know how hard he’s worked on this.