I can't connect to ESP8266's access point after flashing
Some modules may be stuck (in bootloader module specifically) after flashing. The easiest way to reinsure against it is to press Reset button after you're sure flashing is complete (err on side of waiting a bit more), or disconnect and reconnect power.
Second bump on the road is that all computers scan list of available access points only from time to time, and cache the list, so newly appearing access point won't be shown immediately (it may take up to couple of minutes). On almost every OS, the way to work that around is to disable WiFi interface briefly, and enable it again, to force AP scanning.
I entered a wrong AP password, and now my module tries to connect to AP every second, logging it to the screen, even if I reboot module
That's how ESP8266 firmware as made by Espressif works: a) AP connection parameters are stored into flash and survive a reboot; b) if ESP8266 can't connect to an AP, it keeps trying. These points are well known to and expected by any ESP8266 user with some experience, so MicroPython doesn't change them, to follow the policy of least surprise (they also make pretty good sense - if not for all applications, then for many). The output to the screen is due to debug logging enabled, as is default for git master branch or daily builds (and it's helpful, right? - without it, you wouldn't know that ESP8266 behaves like described above). It doesn't happen with release builds. The way to disable debug output is described in the documentation: http://docs.micropython.org/en/latest/e ... rd-control . If you set a wrong password, you can a) use the release version and just set a correct password; b) ignore debug output, and just type a command to set a correct one; c) disable debug output as described above and type a command to set a correct one; d) user a "sledgehammer" approach - erase flash and re-flash MicroPython.
How to transfer files to my ESP8266?
The official way is by using the WebREPL file transfer tool: http://docs.micropython.org/en/latest/e ... ive-prompt . File transfers also supported directly by WebREPL HTML client. If WebREPL file transfer doesn't work [well] for you, or you just want to try other options, there're few community-supported alternatives:
- mpfshell, http://forum.micropython.org/viewtopic.php?f=16&t=1652
- ESPlorer, http://forum.micropython.org/viewtopic.php?f=16&t=1817 (may support file transfer in future versions)
The easiest way is to erase flash completely and reflash the firmware (that's the universal recovery method for any issues). Alternatively, you can look how the WebREPL password is handled and choose any way suitable for your particular situation: https://github.com/micropython/micropyt ... l_setup.py
If I started an application via UART, then connect via WebREPL, WebREPL appears to be hung.
WebREPL on ESP8266 doesn't work like telnet/SSH with a big Unix machine. As ESP8266 is a very resource-constrained device, there's no a session per connection, there's a single session, and any connection accesses this same session. So, when you connect via WebREPL, you see your application running, If it doesn't produce any output, and doesn't accept any input, it appears to be "hung". Enter Ctrl+C to break it and get to MicroPython interactive prompt.
Is there an LED on my board?
All ESP-12 based boards (and most boards are such), have an active-low LED on GPIO2. For other boards/LEDs, consult your board manual.
"FAT filesystem appears to be corrupted" and other FlashROM access related issues
There was half a dozen of such reports, where people followed the official recommendations for troubleshooting (like using "esptool.py erase_flash", using the official firmware, etc.), but still were experiencing problems with filesystem access, or FlashROM access in general (e.g. "OSError: can't set AP config"). About all such issues were in the end tracked to power problems, or hardware problems in general (like defective/worn-out flash). Please pay extensive attention to the power supply of your module. Of importance not just output current, but other power supply parameters, like output ripple, overall noise/interference levels and patterns, etc. USB sockets of computers/laptops are usually (but not necessarily) good source of stable current to power an ESP8266 module.
(Example of investigation: https://github.com/micropython/micropython/issues/1947)