@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.
© Espruino, powered by microcosm.
Report a problem