Nano ESp32 S3 [ESP32] Problem with LittleFS data upload (uploaddfs) after struggling with firmware upload

21

I’m already responding: each new board is assigned a different COM7-9-10-11 port. I see this in both applications on the Arduino IDE, Device Manager, and PlatformIO. 2. Nothing else is connected to the computer except the mouse. 3. The USB cable is new; there doesn’t seem to be a problem with it. I don’t know if it’s strictly a data transfer cable, but they’ve been broken many times, so it seems okay. Other ports report the same errors. In my opinion, I simply can’t get this board to work properly. I reset the UI and start uploading. This sample doesn’t appear on the Arduino IDE with the same hardware.

I I really don’t know what it depends on because sometimes the code wins beautifully and sometimes not, but definitely more times no than yes..

It compiles the code correctly every time, as evidenced by the success messages. Now I can send a message of the full upload process. I’ll paste it in, maybe you’ll notice something there, because I’m already doing it on my own.

22

The smartphone screenshot you posted indicates that PlatformIO is attempting to connect via COM11 because it was manually specified.
However, you stated that “each new board is assigned a different COM7-9-10-11 port.”
If that is the case, why did you manually specify COM11 (i.e., in platformio.ini)?
For instance, if the connection is actually on COM7, you should either specify COM7 in platformio.ini or—as I suggested—not specify a port in platformio.ini at all.
I believe there is a contradiction in your post.

23

I specified port com11 because that was automatically assigned to the new board. In the Arduino IDE, the previous board was assigned port com9, the one we discussed yesterday. I managed to upload the code and website files, but I hadn’t yet configured the buttons. When I returned to the topic, the files wouldn’t upload, displaying errors 1 and 2. In the Platformini file, I changed the code from auto to the specific port assigned to the board, e.g., com9 or com11, but neither the file nor the code would upload. There’s a small, specific problem here, but I can’t pinpoint it.

If I had to define it precisely, I’d say it will upload if it wants to, and if not, it won’t. Previously, it would upload several times each time, and then something would go wrong. I’m learning this too.

24

I see—that is certainly a rather unusual situation. I apologize; I haven’t encountered that myself, so I hadn’t imagined such a scenario.

By the way, have you tried using “Auto”?
You simply need to comment out the upload_port=XXXX line in your platformio.ini file, so please give that a try.

25

yes, I tried auto, I even tried not to add any, let it choose by default, that I got confused about what I tried and what I didn’t try..

It’s definitely not like you just insert the disc, click it and it loads, but when it works out, it’s nice..

26

You’re right—it really makes no sense…
Have you tried restarting Windows?
Given the current situation, there isn’t a specific technical reason to think that would fix it, but the behavior is so strange that it might be worth a try if you are able to restart the OS.
Please restart the OS with the ESP32 disconnected and try using the “Auto” setting first.

27

Processing arduino_nano_esp32 (platform: espressif32; board: arduino_nano_esp32; framework: arduino)

----------------------------------------------------

Verbose mode can be enabled via `-v, --verbose` option

CONFIGURATION: Redirecting...

PLATFORM: Espressif 32 (7.0.1) > Arduino Nano ESP32

HARDWARE: ESP32S3 240MHz, 320KB RAM, 16MB Flash

DEBUG: Current (cmsis-dap) External (cmsis-dap, dfu, esp-bridge, esp-builtin, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)

PACKAGES:

  • framework-arduinoespressif32 @ 3.20017.241212+sha.dcc1105b

  • tool-dfuutil-arduino @ 1.11.0

  • tool-esptoolpy @ 2.41100.0 (4.11.0)

  • tool-mkfatfs @ 2.0.1

  • tool-mklittlefs @ 1.203.210628 (2.3)

  • tool-mkspiffs @ 2.230.0 (2.30)

  • tool-openocd-esp32 @ 2.1100.20220706 (11.0)

  • toolchain-riscv32-esp @ 8.4.0+2021r2-patch5

  • toolchain-xtensa-esp32s3 @ 8.4.0+2021r2-patch5

LDF: Library Dependency Finder → Library Dependency Finder (LDF) — PlatformIO latest documentation

LDF Modes: Finder ~ chain, Compatibility ~ soft

Found 36 compatible libraries

Scanning dependencies…

Dependency Graph

|-- Adafruit GFX Library @ 1.12.6

|-- Adafruit SSD1306 @ 2.5.17

|-- EEPROM @ 2.0.0

|-- LittleFS @ 2.0.0

|-- WebServer @ 2.0.0

|-- WiFi @ 2.0.0

|-- Wire @ 2.0.0

Building in release mode

Retrieving maximum program size .pio\build\arduino_nano_esp32\firmware.elf

Checking size .pio\build\arduino_nano_esp32\firmware.elf

Advanced Memory Usage is available via “PlatformIO Home > Project Inspect”

RAM: [== ] 17.7% (used 57928 bytes from 327680 bytes)

Flash: [=== ] 26.6% (used 835885 bytes from 3145728 bytes)

Configuring upload protocol…

AVAILABLE: cmsis-dap, dfu, esp-bridge, esp-builtin, esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa

CURRENT: upload_protocol = esptool

Looking for upload port…

Using manually specified: COM11

Uploading .pio\build\arduino_nano_esp32\firmware.bin

esptool.py v4.11.0

Serial port COM11

Connecting…

A serial exception error occurred: Cannot configure port, something went wrong. Original message: OSError(22, ‘Określono nieistniejące urządzenie.’, None, 433)

Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers.

For troubleshooting steps visit: Troubleshooting - ESP32 - — esptool latest documentation

*** [upload] Error 1

=========== [FAILED] Took 12.11 seconds ===========

* The terminal process “C:\Users\Dell\.platformio\penv\Scripts\platformio.exe ‘run’, ‘–target’, ‘upload’, ‘–upload-port’, ‘COM11’” terminated with exit code: 1.

* Terminal will be reused by tasks, press any key to close it.

Processing arduino_nano_esp32 (platform: espressif32; board: arduino_nano_esp32; framework: arduino)

----------------------------------------------------

Verbose mode can be enabled via `-v, --verbose` option

CONFIGURATION: Redirecting...

PLATFORM: Espressif 32 (7.0.1) > Arduino Nano ESP32

HARDWARE: ESP32S3 240MHz, 320KB RAM, 16MB Flash

DEBUG: Current (cmsis-dap) External (cmsis-dap, dfu, esp-bridge, esp-builtin, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)

PACKAGES:

  • framework-arduinoespressif32 @ 3.20017.241212+sha.dcc1105b

  • tool-dfuutil-arduino @ 1.11.0

  • tool-esptoolpy @ 2.41100.0 (4.11.0)

  • tool-mkfatfs @ 2.0.1

  • tool-mklittlefs @ 1.203.210628 (2.3)

  • tool-mkspiffs @ 2.230.0 (2.30)

  • tool-openocd-esp32 @ 2.1100.20220706 (11.0)

  • toolchain-riscv32-esp @ 8.4.0+2021r2-patch5

  • toolchain-xtensa-esp32s3 @ 8.4.0+2021r2-patch5

LDF: Library Dependency Finder → Library Dependency Finder (LDF) — PlatformIO latest documentation

LDF Modes: Finder ~ chain, Compatibility ~ soft

Found 36 compatible libraries

Scanning dependencies…

Dependency Graph

|-- Adafruit GFX Library @ 1.12.6

|-- Adafruit SSD1306 @ 2.5.17

|-- EEPROM @ 2.0.0

|-- LittleFS @ 2.0.0

|-- WebServer @ 2.0.0

|-- WiFi @ 2.0.0

|-- Wire @ 2.0.0

Building in release mode

Building FS image from ‘data’ directory to .pio\build\arduino_nano_esp32\littlefs.bin

/assets/images/Tetris_ESP32.WEBP

/index.html

/style.css

Looking for upload port…

Using manually specified: auto

Uploading .pio\build\arduino_nano_esp32\littlefs.bin

esptool.py v4.11.0

Serial port auto

A fatal error occurred: Could not open auto, the port is busy or doesn’t exist.

(could not open port ‘auto’: FileNotFoundError(2, ‘Nie można odnaleźć określonego pliku.’, None, 2))

Hint: Check if the port is correct and ESP connected

*** [uploadfs] Error 2

============ [FAILED] Took 4.30 seconds ============

* The terminal process “C:\Users\Dell\.platformio\penv\Scripts\platformio.exe ‘run’, ‘–target’, ‘uploadfs’, ‘–environment’, ‘arduino_nano_esp32’” terminated with exit code: 1.

* Terminal wi

ll be reused by tasks, press any key to close it.

28

This is very very strange.

  1. The log from when you built and uploaded the program records the following:

AVAILABLE: cmsis-dap, dfu, esp-bridge, esp-builtin, esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa

CURRENT: upload_protocol = esptool
Looking for upload port…
Using manually specified: COM11
Uploading .pio\build\arduino_nano_esp32\firmware.bin
esptool.py v4.11.0
Serial port COM11
Connecting…
A serial exception error occurred: Cannot configure port, something went wrong.

This indicates that upload_port = COM11 is written in platformio.ini.

  1. The log for the file system build and upload records the following:
Looking for upload port…
Using manually specified: auto
Uploading .pio\build\arduino_nano_esp32\littlefs.bin
esptool.py v4.11.0
Serial port auto
A fatal error occurred: Could not open auto, the port is busy or doesn’t exist.

This indicates that upload_port = auto is written in platformio.ini.

Could you show me the actual platformio.ini file you just ran?

If upload_port is not specified in platformio.ini, the log should record something like this for a program build/upload, for example:

Configuring upload protocol...
AVAILABLE: cmsis-dap, esp-bridge, esp-builtin, esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esptool
Looking for upload port...
Auto-detected: COM4
Uploading .pio\build\esp32-s3-devkitc1-n8r8\firmware.bin
esptool.py v5.0.0-dev1
Serial port COM4:
Connecting...
Connected to ESP32-S3 on COM4:

My platformio.ini in this example is as follows, and upload_port is not specified. (This is just one example from my environment, so other details may differ from yours.)


[env:esp32-s3-devkitc1-n8r8]
platform = espressif32
;board = esp32-s3-devkitc1-n8r8
board = ESP32-S3-DEVKITC1-N8R8
framework = arduino
;upload_port = COM19
;monitor_port = COM3
build_flags =
-D ARDUINO_USB_MODE=1
-D ARDUINO_USB_CDC_ON_BOOT=1

If you make changes to the platformio.ini file on your GitHub,
for example, writing it simply like this should make it treat as Auto.

[env:arduino_nano_esp32]
platform = espressif32
board = arduino_nano_esp32
framework = arduino
lib_deps =
adafruit/Adafruit GFX Library
adafruit/Adafruit SSD1306
upload_protocol = esptool
; don't specify upload_port for auto detection
;upload_port = COM11 ; use COM11, this will allow you to use the original port.
board_build.filesystem = littlefs
board_build.partitions = partitions_custom.csv
monitor_speed = 115200

Request:
• Could you show me the platformio.ini that was actually referenced when you just performed these builds/uploads?

The specific location where that platformio.ini file is stored is the project folder, as indicated on GitHub, right?

29

When making copies of the last information I sent you, the platform.ini file was probably set to the COM11 port. I tried again and changed it to auto once, then back to COM11. Platform.ini is located in the project’s main directory, just like on GitHub. The last branch was added, and changes were added and committed, but not merged with main. On Man, there may be a slightly earlier version. The button_opperation-branch branch contains the most recent changes. This is where the buttons were configured compared to main and the main.cpp file.

30

You must be exhausted dealing with a problem that has resurfaced after you thought it was resolved; I can certainly empathize, as I have been through similar situations many times myself.

What you need to do right now is share the full content of the platformio.ini file exactly as it was when the trouble occurred, along with the complete error log generated by it.

Based on the error log, I believe your current issue boils down to a simple fact: when you switch to a different physical unit of the same board model, you are unable to successfully upload the same program or filesystem.

That is the first point that needs to be clarified.

Once you have accurately grasped the problem, the next step is to create a separate, bare-bones project—one that simply prints “Hello, World”—to verify that there are no issues uploading programs between the boards. This is a crucial step to rule out other factors and get to the heart of the issue.

You are likely in a complex situation, trying to tackle this problem while simultaneously adding features and making changes to your ongoing project.
However, focusing exclusively on this single point is vital to getting to the root of the solution.

Hang in there!
A large part of development work involves resolving situations where things don’t work as expected. It is also worth remembering that when hardware doesn’t behave as you anticipate, it is often simply doing exactly what it was instructed to do. (I am not saying that is necessarily the case here, of course.)

I believe that the universal approach to solving any problem is to repeat this cycle: grasp the details of the phenomenon → hypothesize the cause and devise a countermeasure → verify it with the actual hardware.

31

I have been able to reproduce the issue where uploading fails via the connected USB port.

Although I do not have the NanoESP32 board itself, I have set up the NanoESP32 environment and connected an ESP32-S3-DevkitC-1-N16R8 to the device’s Native USB port.

While the DevKitC board allows for a workaround using the BOOT button (which also changes the port recognized by the OS), the NanoESP32 does not support this same method due to hardware limitations; I am currently investigating and verifying alternative workarounds.
Please allow me some time to look into this.

32

I will show you what I believe to be the cause and the solution, so please try it.

[Cause]

There is a missing setting in the native USB configuration, and the USB port of the device visible from the PC does not support uploading.

[Solution]

I will show you the solution that I have confirmed.

  1. Modify platformio.ini as follows:

The following two points:

(1) Add build options
(2) Do not specify the upload port

[env:arduino_nano_esp32]
platform = espressif32
board = arduino_nano_esp32
framework = arduino
lib_deps =
adafruit/Adafruit GFX Library
adafruit/Adafruit SSD1306
upload_protocol = esptool
;upload_port = COM11 ; use COM11, this will allow you to upload to the same port.
board_build.filesystem = littlefs
board_build.partitions = partitions_custom.csv
monitor_speed = 115200
; add build option
build_flags =
-D ARDUINO_USB_MODE=1
  1. Then, we’ll temporarily break through the current state.

(1) Perform a build/upload using the normal operation (I think it’s the arrow icon).
At this point, you should get an error indicating that the port cannot be found, even though it’s connected.

This is the same as before.

(2) Though the above error still present, perform the build/upload again. (It’s important to do this consecutively.)
In my case, at this point, the USB port connection had switched to one that could upload, and I was able to upload. (The COM number changed.)

  1. Once the upload is complete and the device restarts, NanoESP32 will connect to the PC . And this time it will connect to an uploadable USB port. (This is due to the effect of -D ARDUINO_USB_MODE=1)

Regarding -D ARDUINO_USB_MODE=1, it’s a topic frequently discussed in this community, so please search for it. I just realized that this setting wasn’t present in arduino_nano_esp32.json.

33

I followed the instructions; it looks like the upload finally went through after a real struggle—though it was somewhat of a fluke—and I immediately tried uploading the filesystem, but unfortunately, I still haven’t managed to transfer the files. Of course, I was doing this on a new board, but to avoid complicating things further, I’ll just keep revisiting this step from time to time; I also changed the monitor speed to 9600 beforehand, as I’d noticed that while skimming the documentation…

I think that—aside from your meticulousness and consistency, qualities one can really learn from—the actual non-invasive process of uploading and transferring files still leaves a lot to be desired… and I still have a lot to learn.hi