save() on espruino_1v91.122_esp8266 results in immediate Disconnected prompt #5661
Replies: 1 comment
-
Posted at 2017-02-12 by @MaBecker WebIDE:
flashing:
Posted at 2017-02-12 by Robin Sun 2017.02.12 Thank you @MaBecker for your quick response. Could you please elaborate on
could this mean 'INITIAL FLASHING ON WINDOWS' in the link provided? Forgive me, but search did not dig up any detail on 'erase_flash' ref:
Made three more attempts at 1v91 For a sanity check, went back to 1v84
As one can see, save() does work on this previous version. For me, 1v91 does not. Anyone else struggling with the new version? Posted at 2017-02-12 by Robin For a second sanity check, and as I have this flash procedure down pat now, again tried 1v91
Engraved on chip shield: FCC ID:2ADUI ESP-12 Posted at 2017-02-12 by @MaBecker
sorry, don't know, as I am working with esptool.py in command line.
esptool.py --port /dev/ttyUSB0 --baud 115200 erase_flash Wow, looks like you have many lines of code ..... If you like you can try a 1v91 build from this here Posted at 2017-02-12 by Ollie Was going to test @robin, but that link to travis/master is holding 1.87 builds when I go look. Are all custom builds still using this FTP resource I wonder. Edit: Yes, they are :/ @robin if you can link to the firmware version, be happy to test. Posted at 2017-02-12 by Robin Sun 2017.02.12 @MaBecker Downloaded the suggested 1v91.2150 files from https://github.com/MaBecker/esp8266/tree/master/firmware/espruino_1v91.2150_esp8266 but unfortunately get the same issue when attempting to save, or use setIP()
Even tried a much smaller known .js source file to quell your file size surprise
I did notice in other posts that some were having save() issues with the puck during flash. Could this be related? Q: As 1v84 save() is working for me now, is it worth the time trying to load other versions between 1v84 and 1v91? If so, any suggestions on the better ones to try first? Posted at 2017-02-12 by Robin Sun 2017.02.12 @ollie An extra pair of eyes will help here thank you.
The link provided by MaBe was for the parent folder; up one level, and looked for last folder modified provided 1v91.122 http://www.espruino.com/binaries/travis/bfeb548ef8d2241d25f2c78f1b999d8077c67b8c/ Since Mark provided yet a newer version 1v91.2150 link would that make more sense? Posted at 2017-02-12 by Ollie I've flashed @MaBecker link 1v91.122 and can send code and save. I was going to suggest try a smaller file to you, since my code is small enough not to need the command history deleting but looks like you have tried that. Posted at 2017-02-12 by Ollie See edit at foot of this post... not sure if this is a bug but same in 1.87 when I replicate the process. There is a regression in that build, a memory leak, maybe Wifi or socket related? I don't know at what point it may have been introduced, since I'm on 1.87, but there's a steady reduction in The sample code I tried.
Edit: Actually, you only get this on saving code, and in 1.87 too. Upload the code, let it start running, Normally, code will be wrapped by Am interested to know what could be happening here though Posted at 2017-02-12 by Robin Thanks @ollie, I'm grasping at straws here, as I've been following the flash instructions at: http://www.espruino.com/ESP8266_Flashing
the only difference I see is the com port and the boot ver This works flawlessly for ver 1v84 so I don't see why it shouldn't for 1v91 I've also tried using hardwired com port vs Wifi and get the same results. Could there be something strange with the manufacturer of this particular chip? (unlikely) Could it be related to WebIDE on Windows 10? BTW what PC system was used for successful 1v91.122 flash? Posted at 2017-02-12 by Ollie My command string is very similar. Have you run Posted at 2017-02-12 by Robin I did use erase_flash with no observed difference. To rule out some of the obvious; To confirm, your development chip is an ESP8266-12 and are you developing on the Windows 10 platform? Might be down to a PC reboot, although I did cold start yesterday. To me still appears to be new firmware that is causing issue, as boot_v1.6.bin is newer than that 1.4 in flash instructions. Posted at 2017-02-12 by Ollie Mac - and I used a nodeMCU with ESP8266-12 onboard. How are you powering your ESP8266-12, is it standalone? Posted at 2017-02-12 by Robin Yes. I read up on the USB supply limitations ~500ma 2.0 ~900ma 3.0 and use a wallwort with 3.3v regulator. That way I can power the Espruino Orig and PICO off the USB port and the ESP on it's dedicated supply. Posted at 2017-02-12 by @MaBecker Yes, that was very bad calling Release 1v91 work fine for all the ESPs I am having on my desk..... Posted at 2017-02-12 by @MaBecker I do not believe that this is a Espruino issue, would say it is more a how to thing and environment setup. Posted at 2017-02-12 by Ollie Ah ok, I need to look to some newer versions. It was only the issue with the SDK and bootloader than kept me on 1.87. Thanks Posted at 2017-02-12 by countxerox Hi @robin, the flash recipe you quoted above does not look right, for 1v91 it's...
Also, how do you know the flash recipe for travis builds? The link to travis binaries doesn't include any flash instructions? Thanks Posted at 2017-02-12 by Robin I noticed these very similar issues in a separate forum topic thread but primarily with the puck. Could changes then (a month ago) now have an effect on the existing firmware? I only bring this up as @robin 1v84 and @ollie 1v87 commented on stable save() use after flash, yet right around 1v90 a month ago, a few have had similar disconnect issues after save() doing different tasks on separate development environments.
Posted at 2017-02-20 by Robin Sun 2017.02.19 Re-flash update: While owning a PICO and Orig, I understand that support running on non-official Espruino boards is minimal, but I didn't want these observations to go un-noticed and this thread detail to fade. Repeated this flashing sequence for multiple versions in entirety on two separate days. The results for this board are repeatable. save() after a 'Send to Espruino' task ends with an immediate disconnect. Tried: 1v90 1v91 1v91.122 1v91.2150 What does work: 1v84 1v87 1v89 but not 1v88 (see below) Initial observation is that flash with boot_v1.4(b1).bin works, while versions with boot_v1.6.bin are problematic. The module I have running is an ESP-12 and cover is etched with the following: FCC ID:2ADUI ESP-12 Flashing from a Windows 10 Home ver 10.0.14393 Build 14393 laptop running Chrome ver 56.0.2924.87 Firefox ver 51.0.1 WebIDE ver 0.65.9 I have spent an entire week doing nothing but flashing this module in hopes of getting at least one of the new 1v91 versions functional. Initially had flawless flashing of 1v84 and had running for two weeks when I decided to attempt a re-flash using 1v91 The immediate disconnect is the reason I started this thread. As suggested previously, made sure I performed an 'erase_flash' before each firmware attempt and used the same esptool command line, except for changing the name of the boot_??_.bin file version and used the same code.js each attempt Functional versions 1v84 1v87 and 1v89 have this similar output following a save() typed into the left panel http://www.espruino.com/binaries/espruino_1v87_esp8266/
Interestingly, I couldn't get wifi enabled (connected) on 1v88 and abandoned this version
The following would flash with no errors and would receive a file using the WebIDE 'Send to Espruino' button. However, save() in left panel would result in immediate disconnect. 1v90 1v91 1v91.122 1v91.2150 http://www.espruino.com/binaries/espruino_1v90_esp8266/ http://www.espruino.com/binaries/travis/bfeb548ef8d2241d25f2c78f1b999d8077c67b8c/ Mark provided yet a newer version 1v91.2150 link Lists version and appropriate changes http://www.espruino.com/ChangeLog Maps folder version to date http://www.espruino.com/binaries/ While stuck at 1v89 will have to purchase more ESP-12 modules in order to rule out vendor related issues. @gfwilliams I still find it curious that the same disconnect event occurs following a save() on the puck (a month ago) device also. Posted at 2017-04-17 by Viktor Hi,
This 2 libraries is pretty basic. Do I do something wrong or this is known issue? Posted at 2017-04-17 by @MaBecker There is some ongoing work to increase save area to 64k Posted at 2017-04-17 by Viktor Thanks for the reply. Posted at 2017-04-17 by @MaBecker you should place the code in some flash areas and use eval or pipe. With that new board build you will have this areas:
Posted at 2017-04-17 by Viktor By the way. Posted at 2017-04-17 by @MaBecker Hmm, maybe cause by require() statements Posted at 2017-04-17 by Viktor I have built code with webpack. Result bundle was 7K. It is pretty much same as buint by espruino-tool but without In this case Espruino tried to save 15KB to flash as well. I saw thread on GitHub regarding NodeMCU (lua version) ables to use whole chip memory. Posted at 2017-04-18 by @MaBecker
The save code area is increased from 12K to 64K
I guess you mean flash memory because the ESP8266 has 64K of instruction RAM, 96 K of data RAM |
Beta Was this translation helpful? Give feedback.
-
Posted at 2017-02-12 by Robin
Sat 2017.02.11
recap:
I had working 1v84 for over two weeks running on an ESP8266-12 stand alone
I was able to make at least fifty plus project revisions and used save() ten plus times
Today I decided to attempt a new (re)flash using:
espruino_1v91.122_esp8266.tgz 2017-02-11 22:06 632K
acquired from:
http://www.espruino.com/binaries/travis/master/
referenced at:
http://forum.espruino.com/conversations/299821/#comment13460303
@MaBecker from ~02.07.2017 "You have to wait until the next release, or fetch a travis build"
ESP module is booting and can be seen in Windows 10 environment. Using WebIDE I am able to use 'Send to Espruino' icon to xfer code. Functions execute when prompted from command line.
However, save() results in immediate 'Disconnected' msg, and IDE shows orange icon in upper left. The same applies with an attempt to execute wifi.setIP(), the sole reason I performed the re-flash, in order to make use of the previously omitted setIP() function.
Have tried reflashing, but not back to 1v84 just yet. Have restarted WebIDE and browser instances with no luck.
Beta Was this translation helpful? Give feedback.
All reactions