search

FYSETC / SdWiFiBrowser

SD WIFI PRO firmware
GNU General Public License v2.0
11 stars 9 forks source link

File binary\spiffs_8M.bin too large for flash space #5

Open Kreeblah opened 3 months ago

Kreeblah commented 3 months ago

I purchased an 8GB card from https://www.aliexpress.us/item/3256805122957973.html and attempted to flash this firmware to it to make sure it's up to date. I did this with the batch file and pre-compiled binaries in the latest release on this project.

However, during the flashing process, I received the following error:

A fatal error occurred: File binary\spiffs_8M.bin (length 1638400) at offset 6750208 will not fit in 4194304 bytes of flash. Use --flash-size argument, or change flashing address.
tiredboffin commented 2 months ago

@Kreeblah I am having exactly the same issue with my 8G card that arrived today. What is suspicious is that esptool detects the chip as "ESP32 PICO D4" with 4M flash not as "ESP32 PICO V3-02" with 8M and hence it fails to upload the binaries built for 8M chip. I noticed that README.md file has been updated recently to reflect 4M flash size (see commit https://github.com/FYSETC/SD-WIFI-PRO/commit/d785cf7d077ac60a04e3b62c0368ca231d4038b4) however it still says the chip is 8M flash on the very top of the file. I managed to quickly re-build the image using "ESP32 PICO D4" as a target and it kind of works -- I am able to connect to the board in my browser, configure SSID and password and even have managed to upload some files. However it all is extremely slow so I guess the target is also not correct and/or something else has to be changed in the sketch.

Update: the delays were caused by the web application (html and css code), once it is fixed the 4M build works more or less reliably.

Update: uploaded 4M variant to https://github.com/tiredboffin/SdWiFiBrowser. The web server seems to work fine and is more stable with esp32 v3.0.2 and the latest ESPAsyncWebServer -- no frequent reboots any more -- however the app itself is very basic.

cc46808 commented 2 weeks ago

@Kreeblah I am having exactly the same issue with my 8G card that arrived today. What is suspicious is that esptool detects the chip as "ESP32 PICO D4" with 4M flash not as "ESP32 PICO V3-02" with 8M and hence it fails to upload the binaries built for 8M chip. I noticed that README.md file has been updated recently to reflect 4M flash size (see commit FYSETC/SD-WIFI-PRO@d785cf7) however it still says the chip is 8M flash on the very top of the file. I managed to quickly re-build the image using "ESP32 PICO D4" as a target and it kind of works -- I am able to connect to the board in my browser, configure SSID and password and even have managed to upload some files. However it all is extremely slow so I guess the target is also not correct and/or something else has to be changed in the sketch.

Update: the delays were caused by the web application (html and css code), once it is fixed the 4M build works more or less reliably.

Update: uploaded 4M variant to https://github.com/tiredboffin/SdWiFiBrowser. The web server seems to work fine and is more stable with esp32 v3.0.2 and the latest ESPAsyncWebServer -- no frequent reboots any more -- however the app itself is very basic.

@tiredboffin Thank you for this! Just a quick question, I noticed when running the install-all-4M.bat the batch file fails to find boot_app0.bin

esptool write_flash: error: argument <address> <filename>: [Errno 2] No such file or directory: 'binary-4M\\boot_app0.bin'

Would the boot_app0.bin in the binary — 8M — folder work for the binary-4M as well?

tiredboffin commented 2 weeks ago

Would the boot_app0.bin in the binary — 8M — folder work for the binary-4M as well?

Yes, it will work. It comes from esp32 package ./packages/esp32/hardware/esp32/3.0.2/tools/partitions/boot_app0.bin.

I have played with the app for a couple of weeks, found it to be very unreliable in my use case and have failed to fix it. I think the root cause is that while it is based on ESPAsyncWebServer/AsyncTCP to support concurrent requests it still uses delays() and "slow" operations within http handlers and this makes tcp stack to fail and watchdog reboots esp32 too often (doing its job). I think it is fixable but that is not a trivial task.

In my use case I have only one http client talking with the card at a time so instead I have quickly crafted a sketch based on Arduino "standard" WebServer.