why os.listdir return ENODEV

[fdushin]

Okay, I may have spoken too soon. I was able to flash my ESP-12 successfully, and I was even able to do an `os.listdir()` successfully. But I was unable to create a new file, and in fact any attempt to create a file with that image crashed micro python.

I was able to reproduce this on another ESP-12 and from a Linux workstation using a friend's FTDI UART connector, instead of my CP2102. We even tried replacing the 4MB flash with a 1MB flash off a dead ESP-01, but the results were the same.

I tried pre-imaging the ESP-12 with an image I created that is all `0xFF`, as well as one created that is all `0x00`, on the off chance that the micro python image is reading garbage after the image. But that seemed to have no effect. (I do not know where the '/' file system resides in flash, in relationship to the written image, but in retrospect that's probably a silly idea).

I was finally able to get a micro python image to work by backing up a micro python image I have installed on my ESP-01, and writing that 1MB image to my ESP-12 (using the replaced 1MB flash). I know that's sort of cheating, and I'd like to be able to get to the bottom of why I can't seem to properly flash my ESP-12 (or at least end up with a FAT file system once the flash completes). So if there is any information I can provide that would help diagnose this issue, please let me know!

I would not be at all surprised if any of this is due to my general lack of EE skills. I'm a software guy.

[deshipu]

As I understand, it's a bare ESP-12 module you are using. How are you powering it? If you power it directly from the CP2102, then that's not nearly enough current -- the ESP-12 needs up to 300mA at times, and that will make the voltage drop. The microcontroller itself is not that sensitive to voltage changes, but most of the flash chips are -- so you can get corruption that way.

Please make sure you are powering your ESP-12 module from a stable source of 3.3V that can give at least 300mA of current.

[fdushin]

Yeah thanks for that. I am using a separate power supply for the ESP-12 (and ESP-01), which provides 3.3v and can be driven off USB or a wall wart (I've tried both USB and wall wart power, just in case one was not providing continuous power). Some details of how I have set things up are at:

http://blog.dushin.net/2016/07/getting- ... n-the-mac/
http://blog.dushin.net/2016/07/running- ... e-esp8266/

Interesting thing is that I have seen some questions in this forum that seem to point to the same issue -- corruption of some form of the vFAT file system (e.g., causing webrepl to fail to write its configuration file).

[warren]

OK this has affected me now as well - but I think I know why it happened. This is the output I get when I flash the board:

Code: Select all

Performing initial setup
Traceback (most recent call last):
  File "_boot.py", line 11, in <module>
  File "inisetup.py", line 37, in setup
  File "inisetup.py", line 9, in wifi
OSError: can't set AP config
could not open file 'boot.py' for reading
could not open file 'main.py' for reading

MicroPython v1.8.2-49-gf2f761c on 2016-07-26; ESP module with ESP8266
Type "help()" for more information.
>>> 
>>> 

The board is a Huzzah. It is being powered by the 5volts from my USB. I have an inline voltage/current monitor - it is 4.95 volts.
I am flashing it by doing what pfalcon said ( in this post: viewtopic.php?f=16&t=2135#p12236 )
The flash command I am using is:

Code: Select all

"make PORT=/dev/ttyUSB0 deploy"

It's a completely new clone of micropython from Github this afternoon - I have made NO modifications to the modules for flashing etc - in other words 'plain vanilla'.

Now my potential 'clue' is this. This Huzzah is the board I used for the extreme memory testing I started yesterday. It didn't fall over at all - it reached nearly 50,000 write/read/delete cycles. Prior to doing that test, the flashing on that board was 100% - literally. Since I switched to only using the "make PORT=/dev/ttyUSB0 deploy" command, ALL my flashing has been 100% (on three different boards).

I am using the same hardware configuration etc - the ONLY difference is that prior to this attempt to flash it, the board was subjected to extreme memory stressing...

The test did not result in a file system corruption, but my instincts are that it messed up the flash... I read somewhere that the AP config stuff is stored at the END of the flash - so maybe sometimes this area (usually out of the range of the firmware) gets screwed up.

This does seem to imply that flashing new firmware does not itself completely return the board to a pristine state...right?

So we do need to find a solid workaround to situations where the AP config gets screwed up - in fact, that test ought to be in the 'initial setup' that the firmware does IMHO...

[pfalcon]

To sum stuff (yep, this needs to be compiled into complete instructions):

• You have to use --flash_size=8m or more when flashing MicroPython binary.
• --flash_size= parameter accepts size in megabits (not megabytes), and that's known confusion point.
• Using --flash_size=8m is ok, MicroPython has Flash autodetection feature which "resize" filesystem to take advantage of more than 8MBit (1MByte) flash.
• Using --flash_size=4m on a flash bigger than 512K, or not using --flash_size parameter at all is NOT OK, as it will corrupt MicroPython firmware.
• Use --verify switch in the latest (1.1+) esptool.py
• esptool.py is *the* tool to do ESP8266/ESP8285 (soon ESP32) programming, available since early days of ESP8266 hacking. You're welcome to use any other tool, but if something goes wrong, please use esptool.py before reporting anything.
• Unfortunately, lately (1.1) esptool.py was switched to a different, not so stable/tested (by faster) programming routine. esptool.py maintainer received its criticism for that. However, in my account, it works a bit differently, but still stable and good enough. If you face any issues, please report them upstream: https://github.com/themadinventor/esptool
• If nothing else works, a currently known reason is power problems of a module (not the amperage of power, but its quality).

Finally, for curious, erasing flash does take time, it's just lately it is done asynchronously (esptool.py returns before waiting for erase to be complete). If you immediately after erase run e.g. programming, you'll see that it indeed waits awhile before starting the actual programming.

[fdushin]

Thanks for that summary, @pfalcon -- very helpful to know.

[warren]

To sum stuff (yep, this needs to be compiled into complete instructions):

• You have to use --flash_size=8m or more when flashing MicroPython binary.

pfalcon, I am confused!

I was originally using the style of flashing command:

Code: Select all

esptool.py -p /dev/ttyUSB0 --baud 115200  write_flash --flash_size=8m 0 blah-blah-blah.bin

I 'inherited' this from the Adafuit tutorial. Using this command I achieved maybe 60% successful flashes...

But then in a previous post on this topic ( viewtopic.php?f=16&t=2135#p12236) you said:

That's why we say to everyone: please follow the official instructions as specified in the README: https://github.com/micropython/micropyt ... er/esp8266 . If it says that flashing should be done with "make deploy", that's how it should be done. (emphasis mine)

So I switched to your 'make deploy' style command - and immediately got 100% success. Every time on three different ESP boards.

But now your advice implies using the more expansive command again...

What is the difference between these ways of invoking flashing?

Surely if everyone simply sticks to the docs, uses 'make deploy' - they will never have to exercise the discretion of deciding which flash size...? Or am I missing something really obvious?

Thanks

[pfalcon]

pfalcon, I am confused!

Surely if everyone simply sticks to the docs, uses 'make deploy' - they will never have to exercise the discretion of deciding which flash size...? Or am I missing something really obvious?

Well, that's what happens when few related, but different topics are discussed on a forum. There're 2 cases:

1. If you build ESP8266 port from source, just follow source code README, which gives clear and concise instructions. So yes, just use "make deploy".
2. A separate issue was brought, how to install binary releases. This is in general described in the MicroPython docs, http://docs.micropython.org/en/latest/e ... e-firmware .

There're some issues pop up, so when they will be figured well enough, docs will be updated (unless other solution found).

I'd also like to say explicitly that neither Damien nor me faced any issues with filesystem creation/workings, so we're trying to separate possible hardware/power issues from a software/flashing process bug. Not specifying --flash_size is something which could cause random problems. I anticipated that, and submitted https://github.com/themadinventor/esptool/issues/105 quite some time ago, but it actually was pretty calm until recently, when there's indeed a surge in filesystem-related issue reports (and then we can't tell for sure if it's HW or SW issues).

[warren]

There're 2 cases:
1. If you build ESP8266 port from source, [snip]
2. A separate issue was brought, how to install binary releases. [snip]

Thanks - that makes sense.

A suggestion: I'm sure it would be relatively easy to insert the option in the command line for 'make deploy' such that you could specify the .bin file you wish to flash...

Then users could still use the simple 'make deploy' without the need to make choices about baud rate/flash size. If no bin is specified it defaults to firmware-combined.bin.

But if you want to burn something else (e.g. a latest binary), you just specify it on the command line:

Code: Select all

make deploy --file latest.bin

My personal feeling on behalf of many potential newbies is that anything that can be done to reduce the *apparent* choices when flashing can only help.

Thanks

[fdushin]

I think that deploying a pre-built firmware image shouldn't require a full source tree (as well as a build of the esp-open-sdk). Yes, anyone who wants to peruse the source and build their own images should be able to do that, but it shouldn't be necessary. So I am more +1 for having instructions for installing images via esptool and the command line.

Perhaps there are more reports of issues now because more people are using the pre-built images, instead of the make files. Also maybe more newbies (like me!).