Flash new version 2V10 results in infinite loop

Mon 2021.09.06 - Posted 05:14pm CST - ties in with another post I'm working on

Sanity Check for Neopixel pin Require statement

The following content is most likely target'ed towards @MaBe and @Gordon although others may chime in.

https://github.com/espruino/Espruino/blo­b/master/boards/ESP8266_4MB.py

Just flashed current version 2V10 and resultant experience is not what is expected.

2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000
 ets Jan  8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 2408, room 16
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0
tail 8
chksum 0xd8
csum 0xd8
2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000

   . . .

infinite repeat of above

Unable to show results of process.env as device never boots to a stable state.

From:

http://www.espruino.com/EspruinoESP8266#­saving-code-to-flash

chip_id and flash_size	4013-4015 use
--flash_size 512KB
4016-4018 use
--flash_size 4MB-c1

My device is mfg 0xe0 4016 and I had successfully flashed several years ago:

Flash map 4MB:512/512, manuf 0xe0 chip 0x4016
>
>process.env
={
  "VERSION": "1v89",
  "BUILD_DATE": "Nov 15 2016",
  "BUILD_TIME": "12:09:35",
  "GIT_COMMIT": "ab5199458f8b54c4ea964838b41bbce348e2684­f",
  "BOARD": "ESP8266_BOARD",

Last Modified 2021.08.13

https://www.espruino.com/binaries/esprui­no_2v10_esp8266_4mb/
https://www.espruino.com/binaries/esprui­no_2v10_esp8266/

I first erased flash and re-flashed three times, each with the identical output. I then tried the 512K version just to see what might happen. Reverting back to the original link under heading 'Build Content':

Indicates two versions:

   espruino_2v00_esp8266     espruino_2v00_esp8266_4mb

and the note: 'travis build after 2018-10-23 12:00'

So, on a hunch I fetched version 2V00 and that went flawlessly.

https://www.espruino.com/binaries/esprui­no_2v00_esp8266_4mb/

At this point from mere frustration, I did not make an attempt to perform any other flash test.

--- more ---

--- cont ---

Now this is where everything gets interesting. Running on Windows10.

When I upload a previously working code block, modifying only the pin designation, the WebIDE console side locks up, with the inability to enter any content on the L-Hand console side. After many reduction attempts, I narrowed it down to the pin designator of the Neopixel require statement:

const pinneo = NodeMCU.D3;  // GPIO0

require("neopixel").write(pinneo, [0,0,63, 55,77,0, 55,0,77]);

I also pointed this out in a separate companion post:

Sanity Check for Neopixel pin Require statement

It is quite possible that between 2V00 circa mid 2019 and 2V10 current mid 2021 that this issue was noticed and fixed.
I chose not to spend the time to attempt to find a more current working flash version.

https://www.espruino.com/ChangeLog

According to this reference:

https://www.wemos.cc/en/latest/d1/d1_min­i.html

D0 and D2 are available as general GPIO

D0	IO	GPIO16

D3	IO, 10k Pull-up	GPIO0
D4	IO, 10k Pull-up, BUILTIN_LED	GPIO2

and according to this reference:

https://randomnerdtutorials.com/esp8266-­pinout-reference-gpios/

GPIO16 may be used for deep sleep.

--- more ---

--- cont ---

Now, I had an external EEPROM in use which required I2C and SPI was in use for corresponding MOSI MISO comm. That left mw with D4 GPIO2 which is also the onboard LED which I wanted to avoid, D0 GPIO16 which might be needed for deep sleep and D3 GPIO0.

When I used const neo = NodeMCU.D3; // GPIO0 the pinMode would always remain at D0 when using dump() to reveal.

Checking:

https://github.com/espruino/Espruino/blo­b/master/targets/esp8266/jswrap_nodemcu.­c

reveals that NodeMCU","name" : "D3" is required to access GPIO0 and "NodeMCU","name" : "D0" to access GPIO16

When using digitalWrite() NodeMCU.D3 works as desired when referencing pin labeled 'D3' which is GPIO0. However, when using 'D0' GPIO16 or NodeMCU.D0 or NodeMCU.D16 (in case they were backwards)
always results in error: 'Uncaught Error: Invalid pin'

Checking using dump() shows that in either case, the referenced pin is always 'D0' despite trying to force a known state.

I did find a note: 'GPIO16 is now supported in Espruino as a D16 without watch but with all software functiontions like PWM/I2C/SPI/etc' at:

https://www.espruino.com/EspruinoESP8266­

but, for which version(s)?

So, the mfg docs imply GPIO16 is a general purpose I/O for pin D0, but it appears it is just an input. (can anyone verify?)

--- more ---

--- cont ---

Performing a reset() and then dump() reveals:

>dump()
pinMode(D0, "input_pullup", true);
digitalWrite(D2, 1);

Trying to set const pin = NodeMCU.D2; // GPIO4 for pin labeled 'D2'

results in:

>const pin = NodeMCU.D2;
=D4

but uploading

require("neopixel").write(pin, [0,0,63, 55,77,0, 55,0,77]);

or even hard coding:

require("neopixel").write(NodeMCU.D2, [0,0,63, 55,77,0, 55,0,77]);

getPinMode(NodeMCU.D2);

Hence the other post to determine which of the coding conventions is required for using neopixels on ESP8266

Sanity Check for Neopixel pin Require statement

SPI Mode : QIO

try to flash with dio

https://github.com/espruino/Espruino/blo­b/0c9a8ee0f81804d184f41c14ba67b7c2025145­37/targets/esp8266/README_flash.txt#L52

It is all about how the vendor manufactured the board, some use 4 wires (qio) and some 2 wires (dio) to communicate with the flash.

Tue 2021.09.07

Thank you @MaBe for the prompt reply and above link.

re: 'some use 4 wires (qio) and some 2 wires (dio)'

In post #1 I pointed out a successful flash years ago using "1v89"

In addition pointed out that 2V00 just went flawlessly also.

In esptool.py I am using attribute --flash_mode qio with the same format in both those cases.

Under the assumption pointed out above, I find it a bit of a stretch to now change flash modes when all that has changed on the Espruino firmware download servers is the version.

run esptool with option flash_erase and than flash again.

Can confirm that 2V10 is broken and 2V09 is working for ESP8266.

names of used test images:

espruino_2v10_esp8266_4mb_combined_4096.­bin

espruino_2v09_esp8266_4mb_combined_4096.­bin

Wed 2021.09.08

Thank you for the verification @MaBe

I only tried the individual bin, also broken:

https://www.espruino.com/binaries/esprui­­no_2v10_esp8266_4mb/