OSError: [Errno 19] ENODEV

[A622266]

I have an ESP32S3 DevKit C

I am trying to install micropython. I am connected by USB to the 'UART' port on /dev/ttyUSB0.
I erased the flash with:

esptool.py --chip esp32s3 --port /dev/ttyUSB0 erase_flash

This appeared to run correctly.
I then tried to flash micropython to the board with:

esptool.py --chip esp32s3 --port /dev/ttyUSB0 write_flash -z 0 GENERIC_S3-20220618-v1.19.1.bin

This also appeared to run correctly.
However, when running mpremote, I don't think the filesystem was loaded:

mpremote u0 ls

And the result is:

ls:

If I try to copy a file to the uC:

mpremote u0 cp main.py : 

I get the subject error.
I also tried the above procedure using the other USB port on the eval board, and using /dev/ttyACM0. However, I am unable to establish a connection to the board to flash the device.
Any thoughts on how I can correctly flash the device?

[bixb922]

Have you tried the SPIRAM octal version? https://micropython.org/download/GENERIC_S3_SPIRAM_OCT/

[mattytrentini]

As @bixb922 mentioned, you may need a version that has uses Octal SPI to connect to the flash device. You can check your specific board by looking up the ESP32-S3-DevKitC-1 Ordering Information where all eight versions of the DevKitC are listed. OT=Octal, QD=Quad (supported by the standard, non-"OCT" build).

[A622266]

Thanks for the replies @bixb922 and @mattytrentini . My specific device is ESP32-S3-DevKitC-1-N32R8V, which according to the table, suggests that I need a version with Octal SPI. I tried a complete erasure of the flash, followed by flashing SPIRAM Octal for the ESP32. Unfortunately I get the same behavior. I did note that there is not a released version of this binary.

[scruss]

I did note that there is not a released version of this binary.

That's only because specific board support for this variant happened after the v1.19.1 (2022-06-18) cut-off date

[mattytrentini]

It had to be the N32R8V! I have one myself and you've reminded me that I needed to look in to why the MicroPython build was failing to mount the filesystem.

There are a couple of problems. The main issue is that CONFIG_ESPTOOLPY_OCT_FLASH=y needs to be added to the sdkconfig.board. If you make that change and build your own firmware you'll find that the filesystem will mount correctly.

However, GENERIC_S3_SPIRAM_OCT is only configured for 8MB flash - it'll mount on any devices with >8MB flash but you won't be able to access more than the 8MB.

So. you can also configure 32MB flash. You need to change the partition file (to use the existing partitions-32MiB.csv) and set CONFIG_ESPTOOLPY_FLASHSIZE_32MB=y. Then the full 32MB will be available.

Finally, you also need to ensure you're building with an ESP-IDF of v4.4.2 or later (I used v4.4.4).

I was able to confirm all of this works:

MPY: soft reboot
MicroPython v1.19.1-1008-gc046b23ea-dirty on 2023-04-11; ESP32S3 module (spiram octal) with ESP32S3
Type "help()" for more information.
>>> import os
>>> fs_stat = os.statvfs('/')
>>> print(f"File system size {fs_stat[0] * fs_stat[2]:,}")
File system size 31,457,280

I've attached a locally-built firmware that you can use without having to build this yourself. 😄

I'll try to start integrating this into MicroPython so these builds can start to appear in the download manager.

[ZacharyInDallas]

I've attached a locally-built firmware that you can use without having to build this yourself. 😄

I have the same board with the same problem. I tried using mattytrentini's changes to sdkconfig.board but that did not work. I tried using the firmware he built and linked to, and that does work. I'm not sure how my build is different than his. My sdkconfig.board file is:

CONFIG_FLASHMODE_QIO=y
CONFIG_ESPTOOLPY_FLASHFREQ_80M=y
CONFIG_ESPTOOLPY_FLASHSIZE_DETECT=y
CONFIG_ESPTOOLPY_AFTER_NORESET=y
CONFIG_ESPTOOLPY_OCT_FLASH=y

CONFIG_SPIRAM_MEMTEST=

CONFIG_ESPTOOLPY_FLASHSIZE_4MB=
CONFIG_ESPTOOLPY_FLASHSIZE_8MB=
CONFIG_ESPTOOLPY_FLASHSIZE_32MB=y
CONFIG_PARTITION_TABLE_CUSTOM=y
CONFIG_PARTITION_TABLE_CUSTOM_FILENAME="partitions-32MiB.csv"

When I build it I get:

Partitions defined in 'XXX/micropython/ports/esp32/partitions-32MiB.csv' occupy 32.0MB of flash (33554432 bytes) which does not fit in configured flash size 4MB. Change the flash size in menuconfig under the 'Serial Flasher Config' menu.

As far as I know, all changes should only be in sdkconfig.board.

[Amundw99]

Same proble here ... massive problems ... where do I find the sdkconfig.board file?

[Amundw99]

I tested as you described @mattytrentini

import os
fs_stat = os.statvfs('/')
print(f"File system size {fs_stat[0] * fs_stat[2]:,}")
File system size 0

[glenn20]

If you have a firmware that works, but is configured only for 8M (or 4MB) of flash, you migth want to try a new tool I have built which lets you change the flash size on a micropython firmware file OR change the flash size on an existing ESP32 device with micropython firmware flashed onto it: https://github.com/glenn20/mp-image-tool-esp32.

Eg.

mp-image-tool-esp32 ESP32_GENERIC_S3-SPIRAM_OCT-20231005-v1.21.0.bin -f 32M --resize vfs=0 will:

• copy a new firmware file (ESP32_GENERIC_S3-SPIRAM_OCT-20231005-v1.21.0-32MB.bin) with the flash size in the firmware header set to 32M and the partition table setup for a 32M device

If you already have firmware written onto your device, you can adjust it with:

mp-image-tool-esp32 /dev/ttyUSB0 -f 32M --resize vfs=0 --erase-fs vfs will:

1. set the flash size in the firmware header to 32M;
2. resize the vfs partition in the partition table to use all the available space; and then
3. erase the first few blocks of the vfs partition
   • on next boot, micropython will rebuild the vfs filesystem to use all the new space in the vfs partition.

You can also use mp-image-tool-esp32 /dev/ttyUSB0 to see the current partition table and flash size (stored in the firmware header).

NOTE: I have not tested this with your specific device (or any device with 32M of flash), but it has worked for me with various esp32/s2/s3 devices with 4 up to 16MB of flash. (Also, I have just finished it, so please report any bugs or issues if you find them).

[shariltumin]

@Amundw99, if you manage to get REPL, please try these:

>>> import esp, esp32
>>> esp.flash_size()
16777216
>>> esp.flash_user_start()
2097152
>>> 16777216-2097152
14680064
>>> esp32.Partition('vfs')
<Partition type=1, subtype=129, address=2097152, size=14680064, label=vfs, encrypted=0>
>>> esp32.Partition('factory')
<Partition type=0, subtype=0, address=65536, size=2031616, label=factory, encrypted=0>
>>> esp32.Partition('phy_init')
<Partition type=1, subtype=1, address=61440, size=4096, label=phy_init, encrypted=0>
>>> esp32.Partition('nvs')
<Partition type=1, subtype=2, address=36864, size=24576, label=nvs, encrypted=0>
>>> 

My board is "ESP32S3-WROOM-1 N16R8". The esp.flash_size() gave 16777216 and the esp.flash_user_start() gave 2097152. This gives 16777216-2097152 which is 14680064, the size of my vfs.

Using esp32.Partition('vfs') confirms these numbers.

Now,

$ cat partitions-16MiB.csv
# Notes: the offset of the partition table itself is set in
# $IDF_PATH/components/partition_table/Kconfig.projbuild.
# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x6000,
phy_init, data, phy,     0xf000,  0x1000,
factory,  app,  factory, 0x10000, 0x1F0000,
vfs,      data, fat,     0x200000, 0xE00000,

which is also indicated by esp32.Partition(xx).

The first time I flash my board (without first erasing the flash) I get errors from the inisetup.py (fs_corrupted) loop. Do a Ctrl-C to get to REPL then manually create and mount the flash filesystem.

The 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).

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "inisetup.py", line 15, in check_bootsec
  File "inisetup.py", line 34, in fs_corrupted
KeyboardInterrupt:
>>> bdev.info()[4]
'vfs'
>>> os.VfsLfs2.mkfs(bdev)
>>> vfs = os.VfsLfs2(bdev)
>>> os.mount(vfs, "/")
(4096, 4096, 3584, 3582, 3582, 0, 0, 0, 0, 255)
>>> os.stat('/')
(16384, 0, 0, 0, 0, 0, 0, 0, 0, 0)
>>> os.listdir()
[]
>>> bdev.info()
(1, 129, 2097152, 14680064, 'vfs', False)

I hope this helps to resolve your problem.

[Amundw99]

This is what I got ....

import esp, esp32
esp.flash_size()
0

[glenn20]

@shariltumin, you can also solve this problem by erasing the first few blocks of the vfs partition. Micropython will automaticaly build a new filesystem on the next boot.

To be clear, I am talking about when micropython reports a corrupted filesystem (eg. if you forget to erase your flash before writing a new firmware with a partition table that has a vfs partition offset or size different to the previously installed image (eg. writing an OTA firmware over a non-OTA firmware).

If you know the offset of your vfs partition (eg. 0x200000 above), you can erase the first 4 blocks with:

esptool.py --port /dev/ttyUSB0 erase_region 0x200000 0x4000

then micropython will automatically create new filesystem on the next boot.

This is a bit easier if you have installed mp-image-tool-esp32:

mp-image-tool-esp32 u0 --erase-fs vfs

(It gets the correct offset to erase from the partition table on the device). It will also print out your partition table, so you can see what the offset is.

[glenn20]

@Amundw99

This is what I got ....

import esp, esp32
esp.flash_size()
0

That looks seriously broken. I know I'm sounding like a broken record spruiking the little tool I built - but, I suggest installing it and printing out the partition table of your device. It will tell you if if there is an anomaly in the partition table. It will also tell you what the detected flash size is (by querying the chip (esptool.py does that)) AND if the flash size stored in the bootloader header is different AND if the partition table is configured for a different flash size. It is possible that flash size detection is broken on your device and you just need to override it. And if any of those is wrong, it can fix it. Of course, your problem might be something else, but I can't tell at this stage.

Follow the install instructions and then mp-image-tool-esp32 /dev/ttyACM0 (or whatever port your device is attached to).