Assertion failed! and issues uploading image

[mike-s123]

Working in current Arduino IDE, latest 3.0.0 release (although .exe reports " 0.2.3-31-g295fe9b") of mklittlefs.exe (x86_64-w64-mingw32-mklittlefs-295fe9b.zip).

Using with @lorol upload tool. Target is espressif WROVER-B w/16MB flash. When trying to upload an image, it consistently (5 times in a row) stops with an error at 32%.

Reverting to the previous release ( 2.5.1-2, .exe reports "0.2.3-19-g1c43629" - x86_64-w64-mingw32-mklittlefs-1c43629.zip) allows successful uploads.

In troubleshooting this, I also discovered this, with both releases, I think I'm doing it right...

(pack up a directory)

$ ./mklittlefs.exe -b 4096 -p 256 -s 13248000 -c ./data ./foo.bin

(processes without error, now try to unpack)

$ ./mklittlefs.exe -d 5 -u ./bar ./foo.bin

(shouldn't this work to unpack?, it doesn't and, simply trying to list (./mklittlefs.exe -d 5 -l ./foo.bin) gets the same error.)

Debug output enabled

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Assertion failed!

Program: ./mklittlefs.exe
File: littlefs/lfs.c, Line 84

Expression: block < lfs->cfg->block_count

$ ./mklittlefs.exe --version

./mklittlefs.exe  version: 0.2.3-31-g295fe9b

[earlephilhower]

I've never used the uploader you specified, but on the ES8266 the FS uploader just sends bits over so even if those bits weren't a FS it would happily write them. I would imagine that the uploader you're using would so the same, so I'd check that obvious things like the FS total bnary size matches your partitions, etc.

Also, for the unpacker you need to pass in the same params as the packer. LittleFS doesn't store the settings used to create the FS inside the FS itself, so it's using defaults which were not the same that you used prior to make it.

[mike-s123]

OK, -l and -u work if I provide the info. Still have the issue with uploading, I'll open a ticket over there with @lorol But there's definitely something going on - I can switch between mklittlefs releases and the behavior consistently follows. ESP32 uploaders compress the files they're sending, perhaps something isn't getting properly compressed or escaped.

[mike-s123]

OK, this seems to be just between mklittlefs.exe and esptool.exe (2.6). Doesn't seem to involve @lorol

I created two .bins of the same directory, like this

./mklittlefs1.exe -b 4096 -p 256 -s 13565952 -c ./data ./foo1.bin

foo1.bin was created with 0.2.3-31-g295fe9b, foo2.bin created with 0.2.3-19-g1c43629. Then used pytool.exe to upload, like this:

./esptool.exe --chip esp32 --port COM10 --baud 921600 --before default_reset --after hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 16MB 3211264 ./foo2.bin

Upload works with the bin created with the older rev of mklittlefs, fails at 32% with the current rev.

[mike-s123]

Same with latest esptool.py (3.0):

winpty python esptool.py --chip esp32 --port COM10 --baud 921600 --before default_reset --after hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 16MB 3211264 ./foo1.bin
esptool.py v3.0
Serial port COM10
Connecting....
Chip is ESP32-D0WD (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: c4:4f:33:22:11:ed
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Compressed 13565952 bytes to 5801519...
Writing at 0x004d4000... (32 %)
A fatal error occurred: Timed out waiting for packet header

[earlephilhower]

If mklittlefs is generating an valid FS, then I really do have to believe it's an uploader issue. We're not having issues on the 8266 (LittleFS is the default FS now).

What might be going on is that the FS is compressing too much, so that the expansion/writing of a single compressed chunk takes too long and the uploader times out waiting for it. Is there a "don't compress" option you could try? Then it would take much longer, but the writing times of individual chunks would take the same amount of time.

[mike-s123]

Thanks, Earle. Tried with --no-compress, success. It seems to be an issue with esptool.py (they don't have a configurable timeout, either). @lorol , might want to use that option in your arduino-esp32fs-plugin.

[lorol]

Thank you for the tests. I can add --no-compress by default if it doesn't affect the total time to upload.
@mike-s123 can you please test by command line to see what is the impact?