Sun 2019.04.28 Concise summary
    While I understand the WeMos D1 mini is an unsupported board, but as I didn't have an authentic Espruino Wifi handy, . . . leaving the following as information only.

    Does anyone have a WeMos D1 mini to attempt a current ESP8266 flash for comparison?
    or, has anyone experienced the same error?
    Was never able to get a successful upload after three separate flash attempts, and even an attempt after a successful flash of 1V96
    See #10 below for 2v1: frame_error

    Sat 2019.04.27

    Am attempting to run a WiFi example on a current flash of 2v0 on ESP8266

    Verified WebIDE baud at 115200

    Stripped out all but

    var http = require("http");
    var Wifi = require("Wifi");

    Uploading from R-hand editor side of WebIDE

    WebIDE console output

    Espruino.Core.Utils.getURL: got HTTP status code 404 for http://www.espruino.com/modules/Wifi.min­.js
    Espruino.Core.Utils.getURL: got HTTP status code 404 for http://www.espruino.com/modules/http.min­.js
    Espruino.Core.Utils.getURL: got HTTP status code 404 for http://www.espruino.com/modules/ESP8266.­min.js
    Espruino.Core.Utils.getURL: got HTTP status code 404 for http://www.espruino.com/modules/Wifi.js
    WARNING: [notify_warn] Module Wifi not found
    Espruino.Core.Utils.getURL: got HTTP status code 404 for http://www.espruino.com/modules/http.js
    WARNING: [notify_warn] Module http not found
    Espruino.Core.Utils.getURL: got HTTP status code 404 for http://www.espruino.com/modules/ESP8266.­js
    WARNING: [notify_warn] Module ESP8266 not found
    Got ""

    Turned off minification

    Browser also unable to find source and 404's



    In the meantime looking back over


    Pulling links from:


    I reflashed to 1v96 as explained here


    C:\Espruino\esp8266\1V96>python "../esptool/esptool.py" --port COM3 --baud 115200 erase_flash
    esptool.py v2.0-beta1
    Detecting chip type... ESP8266
    Uploading stub...
    Running stub...
    Stub running...
    Erasing flash (this may take a while)...
    Chip erase completed successfully in 0.0s
    Hard resetting...

    Board reset then flash 1v96

    C:\Espruino\esp8266\1V96>python "../esptool/esptool.py" --port COM3 --baud 115200 write_flash --flash_freq 80m --flash_mode qio --flash_size 4MB 0x0000 "boot_v1.6.bin" 0x1000 espruino_esp8266_user1.bin  0x3FC000 esp_init_data_default.bin 0x3FE000 blank.bin
    esptool.py v2.0-beta1
    Detecting chip type... ESP8266
    Uploading stub...
    Running stub...
    Stub running...
    Attaching SPI flash...
    Configuring flash size...
    Flash params set to 0x004f
    Compressed 3856 bytes to 2763...
    Wrote 3856 bytes (2763 compressed) at 0x00000000 in 0.3 seconds (effective 121.0 kbit/s)...
    Hash of data verified.
    Compressed 518516 bytes to 345913...
    Wrote 518516 bytes (345913 compressed) at 0x00001000 in 31.3 seconds (effective 132.7 kbit/s)...
    Hash of data verified.
    Compressed 128 bytes to 75...
    Wrote 128 bytes (75 compressed) at 0x003fc000 in 0.0 seconds (effective 31.0 kbit/s)...
    Hash of data verified.
    Compressed 4096 bytes to 26...
    Wrote 4096 bytes (26 compressed) at 0x003fe000 in 0.0 seconds (effective 3640.9 kbit/s)...
    Hash of data verified.
    Hard resetting...

    Success!! for 1v96

     ____                 _
    |  __|___ ___ ___ _ _|_|___ ___
    |  __|_ -| . |  _| | | |   | . |
    |____|___|  _|_| |___|_|_|_|___|
             |_| espruino.com
     1v96 (c) 2017 G.Williams
    Espruino is Open Source. Our work is supported
    only by sales of official boards and donations:
    Flash map 4MB:512/512, manuf 0xe0 chip 0x4016

    And a little more detective work and the source was located, and now I understand why the min files are not able to be viewed by the browser.




    Still, wonder about why 2v0 behaves as indicated in #1 ? . . . .

  • http, Wifi and ESP8266 are Espruino firmware built-in modules. When IDE is connected, it tries to read the board specs from where it then knows which modules are part of the firmware and which are not. The ones that are not, IDE will try to pull from what ever is specified in IDE configuration / setup (with precedences).

    I assume the code snippet is uploaded from the IDE Editor, is it?

    I also assume that regarding module naming and ESP8266 firmware builds there is no difference for 2v00 and 2v01 versions. Most recent version

    With everything above, I guess something in the Espruino firmware upload to ES8266 did not make it as expected.

    See Espruino on ESP8266 ESP-09 - 1 powerful cm2 and WebServer and Chirp Sensor (moisture, temperature, light) on ESP8266 ESP-09

    I know that you most likely do not target the ESP8266 ESP-09, but that makes no difference on the level of Espruino JavaScript application code.

  • @Robin, cool... you were faster to get it to success than I was with providing you with pointers.

  • Hey thanks @allObjects, for the info. Sometimes just writing it down and pluggin' away gets results.

    But, . . . that success was for 1v96. I attempted again with 2v0 and well, gave up. Went back to 1v96 which will consistently upload. Wish I had another board to perform more attempts. Will have to wait five weeks for next shipment. ;-)

    and, . . . just speed read your chirp sensor page and realized ironically, that I had added that exact sensor to my order. Now with that, learning will be much easier! . . . .

  • Hi @Robin,

    for ESP8266 the named modules used in #1 are included in the Espruino by default as @allObjects explained, it is not possible to load them from github

    this is how you can printout the included modules:

  • Thanks @MaBe for that snippet. Don't know if you remember, but I'm back at a chunk of code you supplied over a year ago, that never got finished. While waiting for parts to arrive, now that I have a flashed board, I'll be able to garner insight from that code block, that wasn't gained back then. I do appreciate what you passed my way back then.

  • Flash map 4MB:512/512, manuf 0xe0 chip 0x4016

    You should load the 4MB build because your board has a 0x4016 flash wich is 4MB.

  • Confirmed:
    2018-02-21 16:17 506K


    Flash map 4MB:512/512, manuf 0xe0 chip 0x4016

    The Wemos D1 Mini device features a 4 MB (32 Mb) flash memory organized in sectors of 4k each. The flash memory address starts at 0x40200000




    By elmar - Fri Dec 04, 2015 6:46 am
    You provide in the same message states that Winbond manufacturer ID is EFh (0xef). Manufacturer ID 0xe0 seems to be LG Semiconductor, but I can't find any flash memory datasheet for that manufacturer.



  • Sun 2019.04.28

    Another attempt and bizarre lockup.
    Running this @MaBe code block b0ba169 on Mar 10, 2017 (with exports commented out)


    ran fine under 1v96, until I clicked on the rendered (to connect to Wifi gateway) browser page. That click event caused an endless fatal error and locked up the WeMos D1 Manual button Reset did not recover.

    Fatal exception (3):
    epc1=0x401000b8, epc2=0x00000000, epc3=0x00000000, excvaddr=0x401000df, depc=0x00000000
    Fatal exception (3):

    Attempting to re-connect now generates the same 'WARNING: [notify_warn] Module Wifi not found' error as what started this thread.

    Re-flashing looked to be the only answer, and this time attempted 2v01
    Flashes okay, but unable to render the output in the browser. Browser just keeps timing out. No visible page generation.

    I understand the WeMos D1 mini is an unsupported board, but as I didn't have an authentic Espruino Wifi, providing this content as information only.

  • Sun 2019.04.28 mid-day

    Did a re-flash of 2v1. Uploaded the #9 example.

    joinWif() will not allow successful reliable communication unless I do the following, by hard coding a connect first. (which is what the web page is for, isn't it, to enter that detail on the fly?)

    wifi.connect("2WIRE113", {password: "3321205"},
    :  function(err){
    :  if(err)console.log(err);
    :  else console.log("connected!");

    Then in the browser:

    but with 2v1 I now get an immediate disconnect and what appears to be a fatal error:

    >wifi.connect("2WIRE113", {password: "3321205"},
    :  function(err){
    :  if(err)console.log(err);
    :  else console.log("connected!");
     ets Jan  8 2013,rst cause:2, boot mode:(3,7)
    load 0x40100000, len 2408, room 16
    tail 8
    chksum 0xe5
    load 0x3ffe8000, len 776, room 0
    tail 8
    chksum 0x84
    load 0x3ffe8310, len 632, room 0
    tail 8
    chksum 0xd8
    csum 0xd8
    2nd boot version : 1.6
      SPI Speed      : 80MHz
      SPI Mode       : QIO
      SPI Flash Size & Map: 32Mbit(512KB+512KB)
    jump to run user1 @ 1000

    The end of console log

    Splitting for reset(), delay 250
    >>> Sent
    >>> Sending...
    ---> "wifi.getAPDetails().ssid"
    >>> Sent
    >>> Sending...
    ---> "wifi.connect(\"2WIRE113\", {password: \"3321205\"},\n  function(err){\n  if(err)console.log(err);\n  else console.log(\"connected!\");\n});"
    >>> Sent
    ERROR: RECEIVE ERROR: {"connectionId":3,"error":"frame_error"}­
    Disconnect callback...
    WARNING: [notify_warn] Disconnected
    >>> Disconnected

    Just noticed from line #27 above, that the content there differs from what the WebIDE returns 32Mbit vs 4MB - important?

    Erasing saved code.
     ____                 _
    |  __|___ ___ ___ _ _|_|___ ___
    |  __|_ -| . |  _| | | |   | . |
    |____|___|  _|_| |___|_|_|_|___|
             |_| espruino.com
     2v01 (c) 2018 G.Williams
    Espruino is Open Source. Our work is supported
    only by sales of official boards and donations:
    Flash map 4MB:512/512, manuf 0xe0 chip 0x4016
    ={ free: 1398, usage: 202, total: 1600, history: 228,
      gc: 0, gctime: 1.861 }

    Not sure if that gleans any insight.

  • @Robin, form the code/log blocks I assume that you do everything(?) in the console. It is difficult to grok what is going on when you publish only parts of your code you execute and also not specify where you execute it or where it is executed. For example, I do not see anything of what joinWifi() is all about... I can only assume (and that's just not good enough... (to use AT&T's current infomercial words... as much I dislike these things, they have subtile hints 'to get us' - :\ )). To resolve this challenge - and that others can reproduce - create an xyz.js file in the Espruino Web IDE, save it, run it, grab the console output and share it in two separate code blocks. That makes it very clear - unambiguous - and easy reproducible. What board exactly you use helps as well, because - at least me - I go to the Web and read up on these things... ESP8266s exist like sand on the beach, and even if millions are really the same, there are thousands of variations... a pic also helps to identify what the hardware is built like.

    Im very happy that you tried 2v01, because as you rightly pointed out, I was successful only w/ a 1v96... even though 2v00 was already out there... and many things have changed since then (of course more in the area ob BLE, but with that also a lot of generic JS which goes for all boards).

    What I conclude from your block two - lines 11..15 - it is an 'auto reset' or 'auto boot' - or much simpler - a simple crash after it connected.

    What I do not know about the power supply situation, but that is something that invokes these 'auto resets'. ESP8266EX chip / firmware tries to calibrate itself. Doing some HAMming myself, I guess it does figure out the sweet spot of RF connectivity, may be even 'measure' / derive / guess the SWR / antenna adaption to protect itself from self-destruction. While doing so it has surges in power urges and that's when it then enters in a brown out / reset... I usually fight this with a decent capacitor as close as possible to the device and with good connectivity (breadboards have the attitude to some times be not so consistent in creating good galvanic connection...) - see http://forum.espruino.com/comments/12602­395/ (bottom right on the pic) - C still on the breadboard - and even better http://forum.espruino.com/comments/12950­869/ - C soldered right onto the board - and 'humongous' in Espruino on ESP8266 ESP-09 - 1 powerful cm2.

    Board manufacturers have different reasons to not overdo with decoupling / power stabilizing Cs for different reasons - good and bad. Good ones are: embedder will know best and most optimal to come up with stable power, either by the supply and wiring itself or decoupling Cs. The bad one - more spread - it saves the manufacturer pennies when not tens of pennies - because a good SMD solution - two different types of Cs - costs them the margin that they try to squeeze out of what's left after price dumping... (with the 'excuse' of: ...embedder will know best how to...). - Sorry for me ranting (about the bad ones).

    I would try a decent C w/ good connection as close as possible to the device (I hope there is not a bad / cold soldering point on your device - because even with best supply that makes it break). Did you ever have a good connection with that device when you used it with serial connection? That can validate independence from Espruino context in the device's/board's good working order.

    If nothing helps, then it must be something in the timing of Espruino that causes this reset. If JS is too busy for too long and ESP8266 SW / firmware stack does not get the CPU back to handle the Wifi, it does an 'auto-reset' / 'auto boot'. This happens most of the time when user code makes the mistake to hog the CPU (for example, having the connect in the upload and not putting he connect in an onInit() sequence, which has to be called way after upload happens in a separate JS execution cycle (for convenience to start my code I use as last line while developing setTimeout(onInit,1000);. But because @Gordon is very much aware of the timing constraints, he has taken every precaution to not even go near to that within Espruino's firmware, such as interrupt handlings, etc.

    I hope this give you some food for experiment thoughts... ;-) and most: success! ...because it is about time to see 2v01+ working on ESP8266 xyz.

  • Thank you for responding @allObjects Although this thread does have some content, the questions you pose are answered above.

    The manufacturer is spelled out in #8 along with pic and the best datasheet I could locate.
    Code is as the file in #9 above and uploaded 'Sent' via the WebIDE on the R-hand editor side.
    Snippets from this link were entered on the L-hand console side to get the output as shown.


    @MaBe helped me on my very first tutorial attempt back in Feb 2017 and have the same setup that was running with 1V87 Re-flashing might not have been the best choice to make progress with newer features.


    It appears only versions back to 1V95 are available, so unable to verify with what I had then.


    Espruino Wifi, other ESP8266-12 and batteries on order to rule out noise spikes, devices etc.

  • Oops... get it. Sometimes I get lost in the forest of links but I looked them up now.

    With the hardware in use as you documented, I would not expect power issues on the board itself.

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

WARNING: [notify_warn] Module Wifi not found - Browser 404's on module also

Posted by Avatar for Robin @Robin