Startup issue (flashreload?)

[danjohn]

I tried to pull the new enhancements (pcallx et al) on my devices, but there's a showstopper.

The dev stops working with new firmare(commit: 310faf7), when LFS comes into game:

esptool erase_flash
esptool write_flash 0 nodemcu-master-20-modules-2019-09-27-06-{timecode}-float.bin

goes up and reformats SPIFFS, then, after uploading 'lfs.img' (which proofed worked bevore):

No LFS image loaded
Formatting file system. Please wait...
> Uploading to ESP file lfs.img...Success
> =node.flashreload('lfs.img')

Crash "��r���n���l���".

• Repowering doesn't help (��r���n���l���),
• reflashing doesn't help (��r���n���l���),
• only erasing flash&reflash brings it up to communication.
  So it seems that "node.flashreload" puts the device mad. Given that 'flashreload' doesn't overwrite any firmware code, there obviousely is a code fragment in firmware that hicks up to something in LFS(?!).

I'm not sure how to track that down, as my serial isn't able to listen on 74480, I have no chance to decrypt "��r���n���l���" things.

Helping hand, anyone? Seen that bevore?

Status: Every ~5sec (HWD):

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

wdt reset
load 0x40100000, len 28320, room 16 
tail 0
chksum 0x2a
load 0x3ffe8000, len 2744, room 8 
tail 0
chksum 0x5e
load 0x3ffe8ab8, len 8, room 8 
tail 0
chksum 0xf4
csum 0xf4

NodeMCU 3.0.0.0 built on nodemcu-build.com provided by frightanic.com
	branch: dev
	commit: cb1b40fffae85cdff5c12d9264b8d8277521ff25
	release: 
	release DTS: 202006220601
	SSL: true
	build type: float
	LFS: 0x20000 bytes total capacity
	modules: adc,cron,dht,file,gpio,http,mdns,net,node,perf,rtctime,sjson,sntp,tmr,uart,websocket,wifi,tls
 build 2020-06-27 powered by Lua 5.1.4 on SDK 3.0.1-dev(fce080e)

Lua 5.1.4  Copyright (C) 1994-2011 Lua.org, PUC-Rio

as of https://github.com/nodemcu/nodemcu-firmware/archive/dev.zip 1.7.2020

[TerryE]

My first Q is have you tried recompiling your lfs.img with the current luac.cross? The Lua load function doesn't do any binary validation, so corruption could cause this type of failure.

[danjohn]

Recompiled "luac.cross" from https://github.com/nodemcu/nodemcu-firmware/archive/dev.zip, recompiled "lfs.img", works. TY for quick response!

I'm curious about this: "luac.cross -v" tells the identical signature than the version I downloaded Oct2019. Does GH repackage that *.zip every new commit, or when? "Copyright (C) 1994-2011"... :)
TY anyway!

[TerryE]

I am not sure about the whats and why but without a Minimal, Complete, and Verifiable example test case, I am left with crystal ball gazing. Sorry.

[danjohn]

Sorry, @TerryE , please re-open.
I was mislead by myself, having flashed an old image (3.0-master_20190907) for proof.

The old master works, but the problem is there when using

NodeMCU 3.0.0.0 built on nodemcu-build.com provided by frightanic.com
	branch: dev
	commit: cb1b40fffae85cdff5c12d9264b8d8277521ff25
	release: 
	release DTS: 202006220601
	SSL: true
	build type: float
	LFS: 0x20000 bytes total capacity
	modules: adc,cron,crypto,dht,encoder,file,gpio,http,mdns,net,node,perf,rtctime,sjson,sntp,tmr,uart,websocket,wifi,tls
 build 2020-06-27 20:24 powered by Lua 5.1.4 on SDK 3.0.1-dev(fce080e)
cannot open init.lua: 

as stated in OP; I'm very sorry for confusement!

Let's hopefully restart from §2.

My first Q is have you tried recompiling your lfs.img with the current luac.cross?

I compiled&used

Lua 5.1.4  Copyright (C) 1994-2011 Lua.org, PUC-Rio

as of https://github.com/nodemcu/nodemcu-firmware/archive/dev.zip 1.7.2020.
Is there a new version to have?

The problem is still as described above: The dev starts up being freshly (erased&)flashed, but enters a boot loop (wdt) after lfs.img was node.flashreloaded.

What can I provide to you to catch that one? (a swarovsky type crystal ball?:) Mem dumps?

[TerryE]

What can I provide to you to catch that one? (a swarovsky type crystal ball?:) Mem dumps?

How about a private copy of you source -- or at least as small a subset that recreates the problem. Just do a remote compile on my blog.ellisons.org.uk service and let me know. I should be able to find this because I only GC the source files daily.

[danjohn]

TY very much for your offer!

So I tried to create a minimal LFS with the problem inside -- and landed at just having _init.lua (original from GH /dev/lua_examples/lfs/_init.lua).

Terminal dump (freshly flashed fw):

Formatting file system. Please wait...
....................................................
NodeMCU 3.0.0.0 built on nodemcu-build.com provided by frightanic.com
	branch: dev
	commit: cb1b40fffae85cdff5c12d9264b8d8277521ff25
	release: 
	release DTS: 202006220601
	SSL: true
	build type: float
	LFS: 0x20000 bytes total capacity
	modules: adc,cron,crypto,dht,encoder,file,gpio,http,mdns,net,node,perf,rtctime,sjson,sntp,tmr,uart,websocket,wifi,tls
 build 2020-06-27 20:24 powered by Lua 5.1.4 on SDK 3.0.1-dev(fce080e)
cannot open init.lua: 
> Uploading to ESP file lfs0.img...Success

> =node.flashreload('lfs0.img')
LFS region updated.  Restarting.
 ets Jan  8 2013,rst cause:2, boot mode:(3,0)

load 0x40100000, len 28320, room 16 
tail 0
chksum 0x09
load 0x3ffe8000, len 2744, room 8 
tail 0
chksum 0xfd
load 0x3ffe8ab8, len 8, room 8 
tail 0
chksum 0x57
csum 0x57

...<74480 noise>...

NodeMCU 3.0.0.0 built on nodemcu-build.com provided by frightanic.com
[...]
 build 2020-06-27 20:24 powered by Lua 5.1.4 on SDK 3.0.1-dev(fce080e)
cannot open init.lua: 
attempt to call a nil value
stack traceback:
	[C]: ?
	[C]: ?

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

...reboot.

Some steps bevore, I tried a lfs with a modified _init inside; the modification was just a few prints added. That gave:

 build 2020-06-27 20:24 powered by Lua 5.1.4 on SDK 3.0.1-dev(fce080e)
error calling 'print' (attempt to call a nil value)

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

after boot (and then reboots).

As the SPIFFS is empty (so, no init.lua) I'm not sure, what mechanism tries to run the lfs _init.lua (in a system state where even print is undefined) or something nil else?
Have reread the LFS docs, obviousely missed that part again... puzzeled.

Can you reproduce my findings?