-
• #2
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.
-
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:
>process.env.MODULES.split(','); =[ "Flash", "Storage", "heatshrink", "net", "dgram", "http", "NetworkJS", "Wifi", "ESP8266", "TelnetServer", "crypto", "neopixel" ] > -
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.
-
Confirmed:
2018-02-21 16:17 506Khttps://www.espruino.com/binaries/espruino_1v96_esp8266_4mb/
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
https://docs.zerynth.com/latest/official/board.zerynth.wemos_d1_mini/docs/index.html
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.Datasheet
https://www.winbond.com/resource-files/w25q32bv_revi_100413_wo_automotive.pdf
-
Sun 2019.04.28
Another attempt and bizarre lockup.
Running this @MaBe code block b0ba169 on Mar 10, 2017 (with exports commented out)https://github.com/MaBecker/esp8266/blob/master/Espruino/JoinWifi.js
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: http://192.168.1.70:8080
but with 2v1 I now get an immediate disconnect and what appears to be a fatal error:
>joinWifi() =undefined >wifi.getAPDetails().ssid ="ESP_067BFF" >wifi.connect("2WIRE113", {password: "3321205"}, : function(err){ : if(err)console.log(err); : else console.log("connected!"); :}); =undefined 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 logSplitting 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?
>reset(1) 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: http://espruino.com/Donate Flash map 4MB:512/512, manuf 0xe0 chip 0x4016 >>process.memory() ={ free: 1398, usage: 202, total: 1600, history: 228, gc: 0, gctime: 1.861 } >wifi.getAPDetails().ssid ="ESP_067BFF"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/12602395/ (bottom right on the pic) - C still on the breadboard - and even better http://forum.espruino.com/comments/12950869/ - 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.
allObjects
MaBe-
Post a reply
About
WARNING: [notify_warn] Module Wifi not found - Browser 404's on module also
Posted by
@Robin
EDIT
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
Uploading from R-hand editor side of WebIDE
WebIDE console output
Turned off minification
Browser also unable to find source and 404's
In the meantime looking back over
UPDATE:
Pulling links from:
I reflashed to 1v96 as explained here
Board reset then flash 1v96
Success!! for 1v96
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 ? . . . .