Geek Answers Handbook

How to recover from endless reload cycles in NodeMCU?

My NodeMCU program went into an endless reboot cycle.

My code works functionally, but any action I'm trying to do, for example. file.remove("init.lua") or even just =node.heap() , it panics and restarts, saying: PANIC: unprotected error in call to Lua API (not enough memory) .

Because of this, I cannot change any code or delete init.lua to stop the code from automatically executing.

How do i recover?

+5
source share
4 answers

I tried flashing another version of NodeMCU again, but started emitting garbage in the serial port.

Then I remembered that NodeMCU had two additional files: blank.bin and esp_init_data_default.bin .

I rolled them into 0x7E000 and 0x7C000 respectively.

They are also available as INTERNAL://BLANK and INTERNAL://DEFAULT in the NodeMCU method.

This downloaded the new NodeMCU firmware, all my files disappeared, and I left the endless reboot cycle.

+6
source

Run the following files:

0x00000.bin to 0x00000

0x10000.bin to 0x10000

And the address for esp_init_data_default.bin depends on the size of the flash module.

0x7c000 for 512 kB, modules such as ESP-01, -03, -07, etc.

0xfc000 for 1 MB, modules such as ESP8285, PSF-A85

0x1fc000 for 2 MB

0x3fc000 for 4 MB, modules such as ESP-12E, NodeMCU devkit 1.0, WeMos D1 mini

Then, after flashing these binaries, format your file system (run "file.format ()" using ESPlorer ) before flashing any other binaries.

Download link

+4
source

I just finished working with a similar problem. In my case, it was an end-user error that caused the need to force erase init.lua , but I think both problems can be solved in a similar way. (For completeness, my problem was that the init.lua was given a too short dsleep() call, as a result of which the board itself rebooted immediately after init.lua .)

I tried flashing the new NodeMCU firmware, writing blank.bin and esp_init_data_default.bin to 0x7E000 and 0x7C000 , as well as writing 0x00000.bin to 0x00000 and 0x10000.bin to 0x10000 . None of this helped in my case.

My hardware is hacking Adafruit Huzzah ESP8266 (ESP-12), with 4 MB flash.

What worked for me:

  • Download the NONOS SDK from Espressif (I used version 1.5.2 from http://bbs.espressif.com/viewtopic.php?f=46&t=1702 ).
  • Unzip it to get boot_v1.2.bin , user1.1024.new.2.bin , blank.bin and esp_init_data_default.bin (under bin / and bin / at /).
  • Run the following files in the specified memory locations:
    • boot_v1.2.bin - 0x00000
    • user1.1024.new.2.bin to 0x010000
    • esp_init_data_default.bin to 0xfc000
    • blank.bin to 0x7E000
    • Blinking note:
      • I used esptool.py 1.2.1.
      • Due to the nature of my problem, I could write changes to flash memory in programming mode (i.e. after booting from GPIO0 held before GND).
      • I found that I need to reset the board between each step (otherwise calls to esptool.py after the first will not work).
  • Erase the flash. esptool.py --port <your/port> erase_flash
  • Then I was able to write a new firmware. I used the nodeMCU 0.9.5 node to isolate the variables, but I strongly suspect that any firmware will work at this stage.
+1
source

The only thing that worked for me was the python flash tool esptool in ubuntu, windows flashtool never deleted init.lua and the reboot loop.

Commands (ubuntu):

 git clone https://github.com/themadinventor/esptool.git cd esptool python esptool.py -h ls -l /dev/tty*

nodemcu_latest.bin can be downloaded from github or anywhere.

 sudo python esptool.py -p /dev/ttyUSB0 --baud 460800 write_flash --flash_size=8m 0 nodemcu_latest.bin
0
source

More articles:


All Articles