Latest Espruino build for Esp8266

allObjects, just to update now I don't get the garbled prompt anymore. This is after a reset of the board, but now the cursor is is frozen and nothing can be typed at the prompt. Also on connecting its not showing the regular espruino things

So you are saying: output is ok, but no input accepted?

I already had this kind of garbage when using a serial port. In my case, the device (which was not an Espruino nor an ESP8266) had a very bad clock reference, and the baudrate was not totally aligned with one of the 'standards' baudrates. Just to be sure, could you try to connect with putty with , by example, a baudrate like 115000, 114000, 115500, 116000 ?

I've the same issue as @MrBambix after flashing on a NodeMCU devkit 0.9 (ESP-12 with 4Mb flash) with

esptool.py --baud 460800 write_flash   --flash_freq 80m --flash_mode qio --flash_size 32m   0x0000 "boot_v1.4(b1).bin" 0x1000 espruino_esp8266_user1.bin 0x37E000 blank.bin

When connecting with the IDE, I got a frozen terminal in the left-hand panel with only

Connected
>

In the IDE log, I find this

[...]
Loaded code from storage.
>>> Connecting...
Set Slow Write = true
[object Object]
Connected [object Object]
Found a prompt... great!
>>> Sending...
---> "echo(0);\nconsole.log(\"<\",\"<<\",JSON.stringify(process.env),\">>\",\">\");echo(1);\n"
Sending block "echo(0);\nconsol", wait 50ms
Sent
Sending block "e.log(\"<\",\"<<\",", wait 50ms
Sent
Sending block "JSON.stringify(", wait 50ms
Sent
Sending block "process.env),\">", wait 50ms
Sent
Sending block ">\",\">\");echo(1)", wait 50ms
Sent
Sending block ";\n", wait 50ms
Sent
>>> Sent
WARNING: No result found - just got ""
Device found (connectionId=12)
>>> Connected to port /dev/ttyUSB0
Sending block "d", wait 50ms
Sent
Sending block "d", wait 50ms
Sent
Sending block "d", wait 50ms
Sent
Sending block "d", wait 50ms
Sent
Sending block "d", wait 50ms
Sent
Sending block "d", wait 50ms
Sent

Note: my board look exactly like this

As I said on the post you made on GitHub, I'd be pretty sure it's baud rate - try 115200.

I'll close the GitHub issue - the forum is the best place for these sorts of questions.

Are you on Windows? Sometimes I find after flashing you need to unplug the USB port and plug back in again.

After a flash, I usually have to do a few connect/disconnects in the ide as well.

One more on windows:
After flashing I usually open putty, reset the board, and close putty.
Now connect works (95%) ;-)

Indeed, using baud rate 115200 and the board works. Thanks.

It looks like it's time for a new experimental build! This build moves a ton of symbol table stuff to flash, freeing up gobs of RAM. The result it 1600 jsvars (instead of 1400) and >10KB of free heap ensuring you don't run out of memory if you run STA+AP and have multiple sockets open.

This build is experimental for those of you that want to play with the bleeding edge or to help test this. For a stable firmware please download an official build!

The build is available at: http://s3.voneicken.com/espruino/espruino_1v85.tve_master_cee7141_esp8266.tgz

Changes:

• 1600 jsvars
  
• >10KB heap
  
• on exception prints stack dump, see ./targets/esp8266/printstack to print stack backtrace
  
  

With this latest build, I can't get my chip to boot. It is stuck in a reboot look with the message Invalid saved code in flash!

I'm using an Adafruit feather esp8266 (ESP-12mod) and using the esp-12 settings in the README.

I can confirm that the same thing happens when I build it from source using the latest github version when running on an ESP8266-ESP12-F. In my case it loops with this output :

2nd boot version : 1.4(b1)
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000

r�Invalid saved code in flash!

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 1396, room 16 
tail 4
chksum 0x89
load 0x3ffe8000, len 776, room 4 
tail 4
chksum 0xe8
load 0x3ffe8308, len 540, room 4 
tail 8
chksum 0xc0
csum 0xc0

2nd boot version : 1.4(b1)
  SPI Speed      : 80MHz
  SPI Mode       : QIO
... etc.

Any help would be appreciated.

Ah, I saw the same but thought it was because I was upgrading from an ancient version. Init code stored in flash has become incompatible and there is not a good check for that. The solution is to erase all flash (erase_flash command to esptool.py) and flash from scratch.
But I've found another issue with my build, so a new one is coming.

@Gordon: is it time to increment FLASH_MAGIC? I'm not sure why the saved code becomes incompatible...

The instructions could just say to erase the flash when uploading - or IMO there should be a 1M image that overwrote everything, which would be a whole load easier for newbies. I don't think it should be the binary's job to detect whether it's been uploaded correctly.

I think the issue is that some pointers to functions get stored in the code, and those move around so you can pretty much guarantee that code won't work between builds... Even using a slightly different compiler version or flags would probably produce incompatible binaries with exactly the same source code - so basically you'd have to write the CRC of the binary along with FLASH_MAGIC, which seems pretty crazy.

But if you've changed the number of variables from 1400 to 1600 then chances are that's your problem :)

Also, if you use E.setBootCode (the Web IDE's new 'save on upload' feature) you won't have any problems, as it's just plain JS code...

And the new build is http://s3.voneicken.com/espruino/espruino_1v85.tve_master_66fde09_esp8266.tgz
If you get the bootloop you have to erase flash completely. Sorry.

I can confirm the latest build boots, after erasing the flash.

Thanks.

@tve 1600! :)

Flashed fine. Anything in particular to test?

This seems to have solved the issue @virtualcodewarrior reported above for me too. However, after doing a dump() (after doing a 'Send to Espruino' in the WebIDE) I see the original code that is available right after flash below my own code:

pinMode(D0, "input_pullup");
pinMode(D2, "opendrain");
pinMode(D4, "input_pullup");
pinMode(D5, "input_pullup");
pinMode(D12, "input_pullup");
pinMode(D13, "input_pullup");
pinMode(D14, "input_pullup");
pinMode(D15, "input_pullup");

How do I get rid of that?

That's where Espruino tries to reconstruct the state of the pins from what they've been set to - it's not actually code as such, it's just added by dump() so if you did digitalWrite(D2,1) it'd get remembered.

I'm surprised the pins state us input_pullup - maybe jshGetPinState isn't working properly for ESP8266?

Input_pullup is the default state the esp8266 gpio pins are put into at reset and Espruino doesn't change that.

Thanks - so either they need changing to be inputs, or more likely jsinteractive needs changing right here as it assumes that pins are normally just inputs.

Perhaps platform_config.h should have a DEFAULT_PIN_STATE definition?

Those extra 200 jsvars are a lifesaver. Amazing work. Thanks!

I have a couple of sensors running 24/7 and I'll feedback any problems I find (if any). One of the old builds was resetting after around 48-72 hours of being on, but without any large non-volatile memory to log to I don't know if it's the build or my code not handling an exception.

running some test on espruino_1v85.tve_master_cee7141_esp8266 without any errors.

1. Wifi, AP,Station and wifi.save() ....
   
2. graphics and neopixel
   
3. reset(), save(), dump()
   
4. sensor DHT22
   
5. I2C with OLED and graphics
   
6. tinyMQTT, version OlliP
   
7. analog input
   
8. http with upload data to a thingspeak channel
   
   
   

That firmware rocks, no more LUA \o/ !!!
Did you guys considered setDeepSleep for esp8266? Someone seems to have worked on that here: http://www.urbiworx.de/2016/03/espruino-for-esp8266-including-deep.html

It will make it awesome for IoT with batteries projects.