save() on espruino_1v91.122_esp8266 results in immediate Disconnected prompt

Sat 2017.02.11

recap:
I had working 1v84 for over two weeks running on an ESP8266-12 stand alone

1v84.tve_master_363580f Copyright 2015 G.Williams

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

1v91.122 Copyright 2016 G.Williams

acquired from:
http://www.espruino.com/binaries/travis/­master/

referenced at:
http://forum.espruino.com/conversations/­299821/#comment13460303
@MaBe 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.

WebIDE:

• set baudrate to 115200
  
  

flashing:

• start with erase_flash

• double check your flash settings

Sun 2017.02.12

Thank you @MaBe for your quick response.

Could you please elaborate on

"start with erase_flash"

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:

double check your flash settings

Made three more attempts at 1v91 For a sanity check, went back to 1v84

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!
>

As one can see, save() does work on this previous version. For me, 1v91 does not. Anyone else struggling with the new version?

For a second sanity check, and as I have this flash procedure down pat now, again tried 1v91
Performing the save() command still results in an immediate disconnect:

1v91.122 Copyright 2016 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
>
=undefined
>process.memory()
={ "free": 899, "usage": 801, "total": 1700, "history": 730 }
>save()
Disconnected

Engraved on chip shield:

FCC ID:2ADUI ESP-12
Model ESP8266MOD
Vendor AI THINKER

could this mean 'INITIAL FLASHING ON WINDOWS' in the link provided?
Forgive me, but search did not dig up any detail on 'erase_flash'

sorry, don't know, as I am working with esptool.py in command line.

"start with erase_flash"

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

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.

Sun 2017.02.12

@MaBe Downloaded the suggested 1v91.2150 files from https://github.com/MaBecker/esp8266/tree­/master/firmware/espruino_1v91.2150_esp8­266

but unfortunately get the same issue when attempting to save, or use setIP()

1v91.2150 Copyright 2016 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
>
=undefined
>process.memory()
={ "free": 825, "usage": 775, "total": 1600, "history": 700 }
>save()
Disconnected

Even tried a much smaller known .js source file to quell your file size surprise

1v91.2150 Copyright 2016 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
>
=undefined
>process.memory()
={ "free": 1415, "usage": 185, "total": 1600, "history": 201 }
>save()
Disconnected

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?

Sun 2017.02.12

@Ollie An extra pair of eyes will help here thank you.

that link to travis/master is holding 1.87 builds when I go look.

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?

I've flashed @MaBe 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.

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 process.memory().free when I review. Reverting to 1.87 and stable again.

The sample code I tried.

var wifi = require("Wifi");
var mqtt = require("https://github.com/olliephillip­s/tinyMQTT/blob/master/tinyMQTT.min.js")­.create("iot.eclipse.org");
var topic = "/op/test";
var message = 0;

mqtt.on("connected", function(){
  setInterval('mqtt.publish(topic, "test" + message);', 2000);
});

mqtt.on("published", function(){
  console.log("message sent");
});

mqtt.on("disconnected", function(){
  console.log("disconnected");
  mqtt.connect();
});

wifi.connect("SSID", {"password":"password"}, function(err){
  if(!err){
    console.log("Connected"); 
    mqtt.connect();
  } else {
    console.log(err); 
  }
});

Edit: Actually, you only get this on saving code, and in 1.87 too. Upload the code, let it start running, save() in the console on left, and then free starts to decline. Maybe this is not an issue since I only did this for the purpose of the test above.

Normally, code will be wrapped by E.on("init", ...) at upload before save().

Am interested to know what could be happening here though

Thanks @Ollie,

I'm grasping at straws here, as I've been following the flash instructions at: http://www.espruino.com/ESP8266_Flashing­

python "../esptool/esptool.py" --port COM3 --baud 115200 write_flash --flash_freq 80m --flash_mode qio --flash_size 32m 0x0000 boot_v1.6.bin 0x1000 espruino_esp8266_user1.bin 0x3FC000 esp_init_data_default.bin 0x3FE000 blank.bin

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?

My command string is very similar. Have you run erase_flash as suggested? That wipes everything and is a good idea when moving between versions.

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.

Mac - and I used a nodeMCU with ESP8266-12 onboard. How are you powering your ESP8266-12, is it standalone?

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.

@Ollie

Yes, that was very bad calling process.memory() and watch leaking .... it is fixed in 1v88 https://github.com/espruino/Espruino/blo­b/master/ChangeLog#L100

Release 1v91 work fine for all the ESPs I am having on my desk.....

I do not believe that this is a Espruino issue, would say it is more a how to thing and environment setup.

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

Hi @Robin, the flash recipe you quoted above does not look right, for 1v91 it's...

*** To flash a 4MB esp8266 (e.g. esp-12) using the serial port use:
esptool.py --port [/dev/ttyUSB0|COM1] --baud 115200 write_flash \
  --flash_freq 80m --flash_mode qio --flash_size 32m \
  0x0000 "boot_v1.6.bin" 0x1000 espruino_esp8266_user1.bin \
  0x3FC000 esp_init_data_default.bin 0x37E000 blank.bin

Also, how do you know the flash recipe for travis builds? The link to travis binaries doesn't include any flash instructions?

Thanks
Rob

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.

18 stevie4711 1v90.09 ". . . . But I got the disconnect on save()"
19 dklinkman 1v90.12 "Same here. I get the disconnects on save periodically"
20 stevie4711 "The more you use save() the more often it happens"
21 dklinkman 1v90.12 "If I try the puck disconnects."
30 Joakim 1v91 " . . . but disconnections on save() and . . . "
32 Adam79 " . . . and trying to save the code getting disconnects."
38 Gordon "and save() which worked fine before is now broken."

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/espruin­o_1v87_esp8266/
boot_v1.4(b1).bin 2016-09-13 10:55 2.7K

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!
>

Interestingly, I couldn't get wifi enabled (connected) on 1v88 and abandoned this version
http://www.espruino.com/binaries/espruin­o_1v88_esp8266/
boot_v1.6.bin 2016-11-10 11:25 3.8K

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

http://www.espruino.com/binaries/espruin­o_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.

Hi,
I'm running into same issue.
I have 1v91 firmware on NodeMCU (ESP-12) with 4MB of flash. But I cannot save more than 12KB of code. I've trited to create MQTT thermometer. After incluring MQTT and DS12B20 modules my ESP run aout of memory.

ERROR: Too big to save to flash (14350 vs 12284 bytes)

This 2 libraries is pretty basic.
I have seen Espruino documentation where I've found that is only 12KB is reserved to save code and 3MB is unsused space.

Do I do something wrong or this is known issue?
Maybe you have some suggestions how to use that 3MB to store code?

There is some ongoing work to increase save area to 64k

• For now remove all inline comment, hope this helps

• If possible use tinyMQTT by @Ollie

Thanks for the reply.
I expeted to use up 1 or 2 MB but 64k is fine for now.

you should place the code in some flash areas and use eval or pipe.

With that new board build you will have this areas:

var freeFlash = require('Flash').getFree()
=[
      { "addr": 2097152, "length": 1048576 },    // <- 1MB
      { "addr": 3145728, "length": 262144 },     // and some smaller sections
      { "addr": 3407872, "length": 262144 },
      { "addr": 3670016, "length": 262144 },
      { "addr": 3932160, "length": 245760 }
 ]