why os.listdir return ENODEV

[xianping016]

the out put:

sd?c匊gn焏og溿?c8剣lrl;lx髇??dcg銃?莃岓og?og?lo;嚊踘鉲l`x鹢?;寽溿?#g銃d弴b岓og?ogl o;菦?鞊`8鹢?;劀溿??€b'銃?b岓og$`?'od`gs徾搊#c$`;摏gccl`d溸|?;snc帉$?b靌c鋵湝汔臏?c噇sdll軣<?s{o#弻d軓p?c靹#鋵湝??c?莇sd?d湠|?;soc帉l潲滗俠?c淠軠???c?cl勩{揹膌?靌`你;?靌?$`屻s抣彑{$弬sl専銊cl刢s<?x?揷bc禧g飥gn?dl嚆l鋸erforming initial setup
Traceback (most recent call last):
File "_boot.py", line 10, 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

#4 ets_task(4010035c, 3, 3fff62f0, 4)
MicroPython v1.8.2-19-gc3f519a on 2016-07-18; ESP module with ESP8266
Type "help()" for more information.
>>> import os
>>> os.listdir()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 19] ENODEV

[deshipu]

What does it say when you do ' import port_diag'?

[pythoncoder]

@deshipu There's a pattern here with more than one user encountering the following error message when using ESP8266 in AP mode:

Code: Select all

File "_boot.py", line 10, in <module>
File "inisetup.py", line 37, in setup
File "inisetup.py", line 9, in wifi
OSError: can't set AP config

It was also reported here by @cpranzl, after a soft reset http://forum.micropython.org/viewtopic.php?f=16&t=2132

[fdushin]

I have been having this issue on one of my ESP-12's, which I have wired up manually to a CP2102 (from MacOS). I have not had the same issue with my ESP-01 (also manually wired) or my Wemos D1 (ESP-12).

I am wondering if I am using esptool.py correctly, because I have had a different set of symptoms, depending on how I flash the device. In the case that reproduces this case, I built MicroPythin from source, using the latest sources from GitHub:

[code]
MicroPython v1.8.2-40-g0d22177 on 2016-07-23; ESP module with ESP8266
[/code]

[code]
>>> import os
>>> os.listdir()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 19] ENODEV
>>> import port_diag
FlashROM:
Flash ID: 1640e0 (Vendor: e0 Device: 4016)
Flash bootloader data:
Byte @2: 00
Byte @3: 20 (Flash size: 1MB Flash freq: 40MHZ)

Networking:
STA ifconfig: ('0.0.0.0', '0.0.0.0', '0.0.0.0', '208.67.222.222')
AP ifconfig: ('192.168.4.1', '255.255.255.0', '192.168.4.1', '208.67.222.222')
Free WiFi driver buffers of type:
0: 8
1: 0
2: 8
3: 4
4: 7
lwIP PCBs:
Active PCB states:
Listen PCB states:
TIME-WAIT PCB states:
[/code]

In some other cases, I flashed using esp8266-2016-07-20-v1.8.2-19-gc3f519a.bin from the MicroPython web site, and I got either

[code]
FAT filesystem appears to be corrupted. If you had important data there, you
may want to make a flash snapshot to try to recover it. Otherwise, perform
factory reprogramming of MicroPython firmware (completely erase flash, followed
by firmware programming).
[/code]

at boot, or other times MicroPython has booted but I get garbage out of os.listdir():

[code]
>>> import os
>>> os.listdir()
['\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\x00\x00', '\x00\x00\x00\x00\x00\x00\x00\x00.\x00\]
[/code]

Clearly I am doing something wrong. I've read that the file system is positioned somewhere after the firmware image, so I don't know if it's getting over-written or simply not initialized when I run esptool?

[mflmartin]

I had the exact same problem. Flashing v1.8.2-40-g0d22177 version solved the issue. I even created a bug in the repo, but I closed it after flashing this version solved my problem.

Did you flash: v1.8.2-40-g0d22177 and got the same problem?

Did you do a python esptool.py -p COM6 erase_flash , before flashing the new one?

I think there must be a pattern. Also I was considering that the culprit could be my FDTI TTL2USB. Some use counterfeit chips and have problems with closing, so you have to disconnect it from USB it and reconnect it before flashing, or something will likely fail.

I have this model:

http://img.banggood.com/thumb/view/uplo ... %20(1).jpg

(I bought it in Amazon, and it seemed legit, but I am unsure. I checked everything and it seems that the serial number is not a fake one, but I am doubting it. I am waiting for a friend to bring me an adafruit or sparkfun alternative).

So, just in case, follow this to test:

1) Connect the **FT232RL FTDI USB To TTL** to usb
2) Put the esp in boot-loader mode
3) erase_flash with esptool

**4) Disconnect the **FT232RL FTDI USB To TTL** from usb, and reconnect it**

5) Remove power from ESP-8266 and put it back (Just disconnect GND, wait 1 second, reconnect GND.)
I assume you are NOT powering the esp from the FT232RL, because some can not supply enought mA, so the esp8266 tend to fail).

6) Put the ESP-8266 into bootloader mode
7) Flash micropython v1.8.2-40-g0d22177


Any difference?

[deshipu]

What is the exact command you use for flashing? In particular, what flash size do you specify?

[fdushin]

Okay, I don't know why it worked, but it did work this time. I am pretty sure I had tried all of these steps before, but I couldn't get it to work. But this time, it seems to have.

(Also, I am using a CP2102 chipset, as that seems to have a signed driver for MacOS. I can use the CH3400 which comes with the Wemos D1 on a Linux VM, but the drivers for that chip don't appear to be signed. Or if they are, the signer is not certified by Apple)

But using the CP2102 on MacOS:

[code]
shell$ esptool.py --port=/dev/tty.SLAB_USBtoUART flash_id
Connecting...
Manufacturer: e0
Device: 4016
[/code]

Gives me what I interpret (googling) to be a 4MB chip (32 megabits).

[code]
> esptool.py --port=/dev/tty.SLAB_USBtoUART erase_flash
Connecting...
Erasing flash (this may take a while)...
[/code]

works (and it doesn't take a while)

And

[code]
> esptool.py --port=/dev/tty.SLAB_USBtoUART write_flash --flash_size=32m 0 esp8266-2016-07-23-v
1.8.2-40-g0d22177.bin
Connecting...
Erasing flash...
Took 2.20s to erase flash block
Wrote 508928 bytes at 0x00000000 in 57.0 seconds (71.5 kbit/s)...

Leaving...
[/code]

Gave me an image that boots with a file system!

[code]
?#4 ets_task(40100368, 3, 3fff62f0, 4)
could not open file 'main.py' for reading

MicroPython v1.8.2-40-g0d22177 on 2016-07-23; ESP module with ESP8266
Type "help()" for more information.
>>> import os
>>> os.listdir()
['boot.py']
[/code]

Sorry for the false alarm! I clearly must have done something wrong before, but I am fairly certain that at least one of the tries did the above (and yes, I'd been running erase_flash every time). Perhaps I did not use 32m with that particular image. I'd tried a few, and I'd previously been erroneously using 8m, thinking I had a 1MB card.

Thanks, and sorry I can't get the [code] markup to work...

[jms]

Folks,

My experience is that the esptool really isn't up to the job. I don't particularly know or care why. It's so flaky it won't even start the job without very particular timing of pressing the reset button and when it did succeed the result was a fast flashing blued LED.

Please try the Windows GUI "NODEMCU FIRMWARE PROGRAMMER" instead and see if that works better.

[deshipu]

My experience is that esptool.py is doing perfectly fine job, however, you have to specify the flash size larger then 512kB, for instance with "--flash_size=8m", because the firmware you are flashing is larger than that.

[fdufnews]

I have experienced problem with flash_erase that gave me corrupted file system.
Sometimes, esptools --port /dev/ttyUSB0 erase_flash
immediately returns to prompt after the sequence
Connecting...
Erasing flash (this may take a while)...
is printed (it doesn't take a while has fdushin said)
Some other times it takes around 5 seconds for the erase to end and in that cases the files system is good.
May be it is not the root cause but I have noticed that when I put the ESP in flash mode prior to sending the command I have more fails than sending the command and immediately putting the ESP in flash mode.