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
Model ESP8266MOD
Vendor AI THINKER
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
1v84.tve_master_363580f Copyright 2015 G.Williams
WARNING: the esp8266 port is in beta!
Flash map 4MB:512/512, manuf 0xe0 chip 0x4016
>
=undefined
>process.memory()
={ "free": 639, "usage": 761, "total": 1400, "history": 517 }
>save()
=undefined
Erasing Flash.....
Writing...............
ERROR: Too big to save to flash (13092 vs 12284 bytes)
Deleting command history and trying again...
Erasing Flash.....
Writing..........
Compressed 22400 bytes to 7668
Checking...
Done!
>
Uncaught [object Object]
at line 1 col 6
wifi.connect(
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
Note that the code.js content is never saved to the ESP8266
While stuck at 1v89 will have to purchase more ESP-12 modules in order to rule out vendor related issues. @Gordon I still find it curious that the same disconnect event occurs following a save() on the puck (a month ago) device also.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
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
Model ESP8266MOD
Vendor AI THINKER
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/
boot_v1.4(b1).bin 2016-09-13 10:55 2.7K
Interestingly, I couldn't get wifi enabled (connected) on 1v88 and abandoned this version
http://www.espruino.com/binaries/espruino_1v88_esp8266/
boot_v1.6.bin 2016-11-10 11:25 3.8K
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
Note that the code.js content is never saved to the ESP8266
http://www.espruino.com/binaries/espruino_1v90_esp8266/
boot_v1.6.bin 2016-12-16 14:56 3.8K
http://www.espruino.com/binaries/travis/bfeb548ef8d2241d25f2c78f1b999d8077c67b8c/
espruino_1v91.122_esp8266.tgz 2017-02-12 02:20 632K
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. @Gordon I still find it curious that the same disconnect event occurs following a save() on the puck (a month ago) device also.