ESP8266 Community Forum

- Sun Nov 15, 2015 11:58 am #34075 I ended up in a boot loop, I have done so multiple times already, but it always got solved by simply flashing nodemcu to the esp8266 again, but this time I am out of luck.

At 9600 baud I get the normal welcome, followed by some garbage

Code: Select allNodeMCU 0.9.5 build 20150318  powered by Lua 5.1.4
?)??1???1?@H
??@H??

NodeMCU 0.9.5 build 20150318  powered by Lua 5.1.4
H!?????D??????????

NodeMCU 0.9.5 build 20150318  powered by Lua 5.1.4
,?????@H

?D???D???

NodeMCU 0.9.5 build 20150318  powered by Lua 5.1.4
??F?B?D??????????

At 115200 baud I get this

Code: Select all{l
 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x40100000, len 28740, room 16
tail 4
chksum 0xcd
load 0x3ffe8000, len 2888, room 4
tail 4
chksum 0xbc
load 0x3ffe8b50, len 15252, room 4
tail 0
chksum 0x4f
csum 0x4f
{l
 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x40100000, len 28740, room 16
tail 4
chksum 0xcd
load 0x3ffe8000, len 2888, room 4
tail 4
chksum 0xbc
load 0x3ffe8b50, len 15252, room 4
tail 0
chksum 0x4f
csum 0x4f
sd
 ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x40100000, len 28740, room 16
tail 4
chksum 0xcd
load 0x3ffe8000, len 2888, room 4
tail 4
chksum 0xbc
load 0x3ffe8b50, len 15252, room 4
tail 0
chksum 0x4f
csum 0x4f
{l

No errors from nodemcu running into a problem with my code, it just reboots. Any suggestions to what I can try?

- Sun Nov 15, 2015 1:17 pm #34084 It's init.lua which is causing the reboot by WDT?

- Sun Nov 15, 2015 2:05 pm #34092

It's init.lua which is causing the reboot by WDT?

I have no idea. Before I have been able to just flash NodeMCU again, and then I could upload new code. This time it keeps doing it, not sure if it store the init.lua after flashing NodeMCU now.

How do I make sure the lua code I send to it, has been removed?

- Sun Nov 15, 2015 3:52 pm #34107 Re-flashing the same firmware will invalidate the SPIFFS as well ... most of the time. I've also seen some rare cases where the filesystem survived this. Easiest way would be to flash a different (older, newer) version, do a file.format() there and re-flash your target firmware.
In the end, you just need to ensure that the old SPIFFS header gets overwritten somehow. Technically, it would be enough to flash blank.bin to the slot where this header is located in your case. I don't have the formula at hand, but it would be something like

Code: Select allfa = round last address used by FW to next multiple of 0x2000
flash blank.bin at fa, fa + 0x2000, fa + 0x4000, ...


Example: 0x62EA2 is last address used by FW, then fa = 0x64000. Flash blank.bin at 0x64000, check booting. If not successful, flash at 0x66000 and so on.

Hope this helps.