Copyright © https://mongoose-os.com

Mongoose OS Forum

frame

Use more than 4MB on ESP32 WROVER module

mamuespmamuesp Germany/Northern coast
edited June 29 in Mongoose OS

Well, I described my problem on Gitter, but there was no response yet, so I will explain it here, perhaps someone may help me.

The problem: I have a ESP32 app which adds an extra 256K file system s described in the documenttion, and it works fine. Now I have an ESP32 WROVER module which comes with 16MB, and and I have no chance to use the memory above 4MB. This is strange, because the mos tool (and/or flasher) detects the 16MB as you may see here:

Connecting to https://mongoose.cloud, user test
Uploading sources (31974 bytes)
Firmware saved to build/fw.zip
Loaded Heydo-MQTT-GO/esp32 version 1.0 (20180628-164828/???)
Opening /dev/cu.SLAB_USBtoUART @ 115200...
Connecting to ESP32 ROM, attempt 1 of 10...
Connecting to ESP32 ROM, attempt 2 of 10...
  Connected, chip: ESP32D0WDQ6 R1
Running flasher @ 0...
  Flasher is running
==> Flash size: 16777216, params: 0x0240 (dio,128m,40m)
Deduping...
    16384 @ 0x9000 -> 8192
     8192 @ 0xd000 -> 4096
...

... but as I increase the value of the file system size in this line above 256K (even in 256K sized values)

build_vars:
 ESP_IDF_EXTRA_PARTITION: fs_ext,data,spiffs,,256K 

... this error pops up:

Partitions defined in '/mongoose-os/fw/platforms/esp32/src/partitions_mgos.csv' occupy <xyz> of flash (<xyz> bytes) which does not fit in configured flash size 4MB. Change the flash size in menuconfig under the 'Serial Flasher Config' menu. 

I tried a lot of things to change the configuration to 16MB (with buildvars as FLASH_SIZE or even adding SDK settings, but nothing helped.

So the question is: what do I have to do to use the full available flash size?

Addendum: as I remark now, the creating of a filesystem with FS.Mkfsfails completely on the ESP WROVER module ... even with the small size ...

Comments

  • nliviunliviu Romania
    build_vars:
      FS_SIZE: 524288
    

    creates a 512K filesystem.

    cat build/build.log |grep 524288:

      MKFS  /usr/local/bin/mkspiffs8 524288 4096 256 4096 /<path>/build/fs -> /<path>/build/objs/fw_temp/fs.img
         Image stats: size=524288, space: total=474641, used=102408, free=372233
    

    It flashes ok, but my WROVER has only 4MB

    [Jun 29 11:55:12.777] I (30) boot: ESP-IDF v3.0-r11 2nd stage bootloader
    [Jun 29 11:55:12.777] I (30) boot: compile time 08:50:39
    [Jun 29 11:55:12.777] I (32) boot: Enabling RNG early entropy source...
    [Jun 29 11:55:12.777] I (34) boot: SPI Speed      : 40MHz
    [Jun 29 11:55:12.777] I (38) boot: SPI Mode       : DIO
    [Jun 29 11:55:12.799] I (42) boot: SPI Flash Size : 4MB
    [Jun 29 11:55:12.799] E (47) flash_parts: partition 5 invalid - offset 0x390000 size 0x80000 exceeds flash chip size 0x400000
    [Jun 29 11:55:12.799] E (57) boot: Failed to verify partition table
    [Jun 29 11:55:12.799] E (62) boot: load partition table error!
    [Jun 29 11:55:12.802] user code done
    
  • nliviunliviu Romania
    build_vars:
      ESP_IDF_EXTRA_PARTITION: fs_ext,data,spiffs,,256K
    

    builds ok for me.

    [Jun 29 12:14:31.944] I (46) boot: Partition Table:
    [Jun 29 12:14:31.944] I (50) boot: ## Label            Usage          Type ST Offset   Length   Flags
    [Jun 29 12:14:31.944] I (58) boot:  0 nvs              WiFi data        01 02 00009000 00004000 00000000
    [Jun 29 12:14:31.966] I (66) boot:  1 otadata          OTA data         01 00 0000d000 00002000 00000000
    [Jun 29 12:14:31.966] I (74) boot:  2 app_0            OTA app          00 10 00010000 00180000 00000000
    [Jun 29 12:14:31.966] I (83) boot:  3 fs_0             SPIFFS           01 82 00190000 00040000 00000000
    [Jun 29 12:14:31.988] I (91) boot:  4 app_1            OTA app          00 11 001d0000 00180000 00000000
    [Jun 29 12:14:31.988] I (99) boot:  5 fs_1             SPIFFS           01 82 00350000 00040000 00000000
    [Jun 29 12:14:31.988] I (107) boot:  6 fs_ext           SPIFFS           01 82 00390000 00040000 00000000
    [Jun 29 12:14:32.010] I (116) boot: End of partition table
    
  • mamuespmamuesp Germany/Northern coast
    edited June 29

    It's unbelievable... I am the "bug sniffer" again ... :wink:

    Here's what happens:

    • If I use FS_SIZE to set the size of the file system, I can only execute the build remotely and with using the release version.
    • Both with latest and with the release version with --local flag set the following error occurs when I let the value of FS_SIZE become larger than 256K:
      make[1]: Entering directory '/opt/Espressif/esp-idf/components/bootloader/subproject'
      Building partitions from /mongoose-os/fw/platforms/esp32/src/partitions_mgos.csv...
      Partitions defined in '/mongoose-os/fw/platforms/esp32/src/partitions_mgos.csv' occupy 7.1MB of flash (7405568 bytes) which does not fit in configured flash size 4MB. Change the flash size in menuconfig under the 'Serial Flasher Config' menu.
      make: *** [/Users/mmspaeth/.mos/apps-latest/MyName-MQTT-GO/build/objs/partitions_mgos.bin] Error 2
    • With the release version and remote I can only set 2MB (2097152) as FS_SIZE to have correct results. In others cases, there might be a build processed and the FW is written, but if FS_SIZE is smaller then 4MB and greater than 2MB, the flasher crashes when verifying the written data or the system crashes when mounting the filesystem:

    Flasher error (if FS_SIZE is > 3MB)

    Connecting to https://mongoose.cloud, user test
    Uploading sources (31938 bytes)
    Firmware saved to build/fw.zip
    Loaded MyName-MQTT-GO/esp32 version 1.0 (20180629-102754/???)
    Opening /dev/cu.SLAB_USBtoUART @ 115200...
    Connecting to ESP32 ROM, attempt 1 of 10...
    Connecting to ESP32 ROM, attempt 2 of 10...
      Connected, chip: ESP32D0WDQ6 R1
    Running flasher @ 0...
      Flasher is running
    Flash size: 16777216, params: 0x0240 (dio,128m,40m)
    Deduping...
        18368 @ 0x1000 -> 6080
        16384 @ 0x9000 -> 8192
         8192 @ 0xd000 -> 0
      1001248 @ 0x10000 -> 34592
      4194304 @ 0x190000 -> 184320
    Writing...
         4096 @ 0x1000
         4096 @ 0x5000
         4096 @ 0x8000
         8192 @ 0x9000
        32768 @ 0x16000
         4096 @ 0x104000
       184320 @ 0x190000
    Wrote 236256 bytes in 8.35 seconds (221.15 KBit/sec)
    Verifying...
        18368 @ 0x1000
         3072 @ 0x8000
        16384 @ 0x9000
         8192 @ 0xd000
      1001248 @ 0x10000
      4194304 @ 0x190000
    Error: fs: failed to compute digest 4194304 @ 0x190000: error reading response packet: error reading: EOF
    

    Crash when mounting: (if FS_SIZE== 3MB)

    [Jun 29 12:30:25.244] I (28) boot: ESP-IDF v3.0-rc1-r9 2nd stage bootloader
    [Jun 29 12:30:25.244] I (28) boot: compile time 10:29:25
    [Jun 29 12:30:25.244] I (32) boot: Enabling RNG early entropy source...
    [Jun 29 12:30:25.244] I (33) boot: SPI Speed      : 40MHz
    [Jun 29 12:30:25.244] I (38) boot: SPI Mode       : DIO
    [Jun 29 12:30:25.244] I (42) boot: SPI Flash Size : 16MB
    [Jun 29 12:30:25.244] I (46) boot: Partition Table:
    [Jun 29 12:30:25.244] I (49) boot: ## Label            Usage          Type ST Offset   Length   Flags
    [Jun 29 12:30:25.244] I (57) boot:  0 nvs              WiFi data        01 02 00009000 00004000 00000000
    [Jun 29 12:30:25.244] I (65) boot:  1 otadata          OTA data         01 00 0000d000 00002000 00000000
    [Jun 29 12:30:25.244] I (74) boot:  2 app_0            OTA app          00 10 00010000 00180000 00000000
    [Jun 29 12:30:25.244] I (82) boot:  3 fs_0             SPIFFS           01 82 00190000 00300000 00000000
    [Jun 29 12:30:25.244] I (90) boot:  4 app_1            OTA app          00 11 00490000 00180000 00000000
    [Jun 29 12:30:25.244] I (98) boot:  5 fs_1             SPIFFS           01 82 00610000 00300000 00000000
    [Jun 29 12:30:25.244] I (107) boot: End of partition table
    [Jun 29 12:30:25.272] I (111) boot: OTA data 0: seq 0x00000001, st 0x10, CRC 0x157a2b85, valid? 1
    [Jun 29 12:30:25.272] I (119) boot: OTA data 1: seq 0x00000000, st 0x00, CRC 0x00000000, valid? 0
    [Jun 29 12:30:25.272] I (126) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x284fc (165116) map
    [Jun 29 12:30:25.354] I (193) esp_image: segment 1: paddr=0x00038524 vaddr=0x3ffb0000 size=0x0301c ( 12316) load
    [Jun 29 12:30:25.354] I (198) esp_image: segment 2: paddr=0x0003b548 vaddr=0x40080000 size=0x00400 (  1024) load
    [Jun 29 12:30:25.354] I (200) esp_image: segment 3: paddr=0x0003b950 vaddr=0x40080400 size=0x046c0 ( 18112) load
    [Jun 29 12:30:25.354] I (216) esp_image: segment 4: paddr=0x00040018 vaddr=0x400d0018 size=0xb803c (753724) map
    [Jun 29 12:30:25.616] I (481) esp_image: segment 5: paddr=0x000f805c vaddr=0x40084ac0 size=0x0c664 ( 50788) load
    [Jun 29 12:30:25.636] I (502) esp_image: segment 6: paddr=0x001046c8 vaddr=0x400c0000 size=0x00034 (    52) load
    [Jun 29 12:30:25.701] I (512) boot: Loaded app from partition at offset 0x10000
    [Jun 29 12:30:25.701] I (512) boot: Disabling RNG early entropy source...
    [Jun 29 12:30:25.701] I (514) cpu_start: Pro cpu up.
    [Jun 29 12:30:25.701] I (517) cpu_start: Single core mode
    [Jun 29 12:30:25.701] I (522) heap_init: Initializing. RAM available for dynamic allocation:
    [Jun 29 12:30:25.701] I (529) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
    [Jun 29 12:30:25.701] I (535) heap_init: At 3FFB97D0 len 00026830 (154 KiB): DRAM
    [Jun 29 12:30:25.701] I (541) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
    [Jun 29 12:30:25.701] I (547) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
    [Jun 29 12:30:25.701] I (554) heap_init: At 40091124 len 0000EEDC (59 KiB): IRAM
    [Jun 29 12:30:25.702] I (560) cpu_start: Pro cpu start user code
    [Jun 29 12:30:25.709] I (242) cpu_start: Starting scheduler on PRO CPU.
    [Jun 29 12:30:25.744] mgos_init2           MyName-MQTT-GO 1.0 (20180629-102931/???)
    [Jun 29 12:30:25.744] mgos_init2           Mongoose OS 2018062910 (20180629-102929/???)
    [Jun 29 12:30:25.744] mgos_init2           CPU: 160 MHz, RAM: 292832 total, 253876 free
    [Jun 29 12:30:25.744] mg_lwip_if_init      Mongoose 6.11, LwIP 1.5.0
    [Jun 29 12:30:25.744] mg_ssl_if_init       mbed TLS 2.8.0
    [Jun 29 12:30:25.744] mgos_hal_freertos_pr ESP-IDF v3.0-rc1-r9
    [Jun 29 12:30:25.749] mgos_hal_freertos_pr Boot partition: app_0; flash: 16M
    [Jun 29 12:30:25.757] mgos_vfs_dev_open    esp32part ({"label": "fs_0", "subtype": 130}) -> 0x3ffc1c0c
    [Jun 29 12:30:25.766] mgos_vfs_mount       Mount SPIFFS @ / (dev 0x3ffc1c0c, opts {"encr": false}) -> 0x3ffc1c1c
    [Jun 29 12:30:30.924] Task watchdog got triggered. The following tasks did not reset the watchdog in time:
    [Jun 29 12:30:30.924]  - mgos (CPU 0/1), backtrace: 0x40080af4 0x4008227f 0x400822da 0x40082789 0x400e615d 0x400e471a 0x40185725 0x400fe9b5 0x400feca2 0x400fdac5 0x400e58e8 0x400e3e1e 0x400e5d31 0x400e5e42 0x400e25aa 0x40082d38
    [Jun 29 12:30:30.924] 
    [Jun 29 12:30:30.924] Tasks currently running:
    [Jun 29 12:30:30.924] CPU 0: mgos
    [Jun 29 12:30:30.924] Aborting.
    [Jun 29 12:30:30.924] abort() was called at PC 0x400d1208 on core 0
    [Jun 29 12:30:30.924] 
    [Jun 29 12:30:30.924] Backtrace: 0x4008d67b 0x4008d77b 0x400d1208 0x4008166e 0x40080af1
    [Jun 29 12:30:30.924] --- BEGIN CORE DUMP ---
    

    A FS_SIZEbigger than 3MB won't work in any combination.

    That's very, very strange ... I think I'll open an issue ... And I need this to work properly ...

    Addendum: Issue opening is done! :wink:

  • nliviunliviu Romania
    build_vars:
      FS_SIZE: 3145728
      ESP_IDF_SDKCONFIG_OPTS: ${build_vars.ESP_IDF_SDKCONFIG_OPTS} CONFIG_ESPTOOLPY_FLASHSIZE_4MB=}
      ESP_IDF_SDKCONFIG_OPTS: ${build_vars.ESP_IDF_SDKCONFIG_OPTS} CONFIG_ESPTOOLPY_FLASHSIZE_16MB=y CONFIG_ESPTOOLPY_FLASHSIZE="16MB"}
    

    builds ok either local or remote with both 2.3 and latest 20180628-120416/master@0d8d3d9b.

    Maybe your local sources are not in synch with mos tool.

  • mamuespmamuesp Germany/Northern coast
    edited June 29

    Unfortunately it's the same behaviour as described above (tried these build_vars already ...). But anyway thank you for your helping attempts! :smiley:
    And no, my sources are in sync - you know, as developer I always try to eliminate potential error sources first - then I ask questions here. So before testing I cleaned my docker settings and updated the mos tool, so there had been a fresh install ... So it seems I stumbled upon a nasty bug ... It curious: it's the second time that something works on your system but not on mine ... strange.

    Addendum: there is a tiny change - mos toolbuild with these settings now also with --local and the latestversion, but the flasher fails the when flashing with FS_SIZE of 4MB ... (and so on ... as shown above).

    Addendum II: one improvement came along - with these settings I'm able to add a bigger extended filesystem. So this could be the way to a (preliminary) solution.

  • nliviunliviu Romania

    Now I'm on Debian 9.4.

  • mamuespmamuesp Germany/Northern coast

    I think I will test it on Linux too to be sure, it's not system related (... or it is ...) :wink:

  • nliviunliviu Romania

    As long as the build process is performed by a docker image, it's not system related.
    I've also got some errors sometimes, but they were related to my local source tree (modules and libs).

  • mamuespmamuesp Germany/Northern coast
    edited June 29

    As I didn't test the option to add another FS, I just tried it now and I'm able to get nearly all the space available ... So it's a useable workaround ... Thank you for your hints anyway!
    But the other behaviour in conjunction with FS_SIZE is still strange, and if it's caused by wrong settings in libraries, this will be hard to find ...

    Another thing will be this point from the ESP32 datasheet:

    How might the addtional PSRAM be accessed? But one step after another ... :wink:

  • mamuespmamuesp Germany/Northern coast
    edited June 29

    Now I may define a bigger FS as additional fs_ext, but the mkfs command fails:

    mmspaeth@Mac-Pro:~/.mos/apps-latest/Heydo-MQTT-GO$ mos call FS.Mkfs '{"dev_type": "esp32part", "dev_opts": "{\"label\": \"fs_ext\"}", "fs_type": "SPIFFS"}'
    Error: remote error 500: mkfs failed
    

    The partition ist set, and no FS is created, so it should work ...

    [Jun 29 16:15:38.145] I (30) boot: ESP-IDF v3.0-r11 2nd stage bootloader
    [Jun 29 16:15:38.145] I (30) boot: compile time 14:15:03
    [Jun 29 16:15:38.145] I (34) boot: Enabling RNG early entropy source...
    [Jun 29 16:15:38.145] I (35) boot: SPI Speed      : 40MHz
    [Jun 29 16:15:38.145] I (39) boot: SPI Mode       : DIO
    [Jun 29 16:15:38.145] I (43) boot: SPI Flash Size : 16MB
    [Jun 29 16:15:38.145] I (47) boot: Partition Table:
    [Jun 29 16:15:38.145] I (51) boot: ## Label            Usage          Type ST Offset   Length   Flags
    [Jun 29 16:15:38.145] I (59) boot:  0 nvs              WiFi data        01 02 00009000 00004000 00000000
    [Jun 29 16:15:38.145] I (67) boot:  1 otadata          OTA data         01 00 0000d000 00002000 00000000
    [Jun 29 16:15:38.145] I (75) boot:  2 app_0            OTA app          00 10 00010000 00180000 00000000
    [Jun 29 16:15:38.145] I (83) boot:  3 fs_0             SPIFFS           01 82 00190000 00040000 00000000
    [Jun 29 16:15:38.145] I (92) boot:  4 app_1            OTA app          00 11 001d0000 00180000 00000000
    [Jun 29 16:15:38.145] I (100) boot:  5 fs_1             SPIFFS           01 82 00350000 00040000 00000000
    [Jun 29 16:15:38.145] I (108) boot:  6 fs_ext           SPIFFS           01 82 00390000 00c00000 00000000
    [Jun 29 16:15:38.181] I (117) boot: End of partition table
    

    (banging the head against the wall) :wink:

    ... more detailed log:

    [Jun 29 16:42:21.461] mg_rpc_handle_reques FS.Mkfs via MQTT 
    [Jun 29 16:42:21.470] mgos_vfs_dev_open    esp32part ({"label": "fs_ext"}) -> 0x3ffcd10c
    [Jun 29 16:42:21.477] mgos_vfs_mkfs        Create SPIFFS (dev 0x3ffcd10c, opts )
    [Jun 29 16:42:21.503] mgos_vfs_fs_spiffs_m addr 0x0 size 12582912 bs 4096 ps 256 es 4096 nfd 10 encr 0 =>
    [Jun 29 16:42:21.509] mgos_vfs_mkfs        FS SPIFFS : create failed
    [Jun 29 16:42:21.514] mgos_vfs_dev_close   0x3ffcd10c refs 0
    
  • nliviunliviu Romania
    edited June 29

    My results with ESP_IDF_EXTRA_PARTITION: fs_ext,data,spiffs,,256K
    2.3

    mos update release
    rm -rf build/ deps/
    mos build --local  --platform esp32 --clean
    mos flash --esp-erase-chip
    

    FS.Mkfs '{"dev_type": "esp32part", "dev_opts": "{\"label\": \"fs_ext\"}", "fs_type": "SPIFFS"}'

    Jun 29 20:35:51.874] mg_rpc_handle_reques FS.Mkfs via WS_in 192.168.1.10:49929
    [Jun 29 20:35:51.881] mgos_vfs_dev_open    esp32part ({"label": "fs_ext"}) -> 0x3ffb9a2c
    [Jun 29 20:35:51.888] mgos_vfs_mkfs        Create SPIFFS (dev 0x3ffb9a2c, opts )
    

    FS.Mount '{"dev_type": "esp32part", "dev_opts": "{\"label\": \"fs_ext\"}", "fs_type": "SPIFFS", "path": "/mnt"}'

    [Jun 29 20:37:11.257] mgos_vfs_dev_open    esp32part ({"label": "fs_ext"}) -> 0x3ffba1c8
    [Jun 29 20:37:11.264] mgos_vfs_mount       Mount SPIFFS @ /mnt (dev 0x3ffba1c8, opts ) -> 0x3ffba1d8
    [Jun 29 20:37:11.346] mgos_vfs_mount       /mnt: size 233681, used: 0, free: 233681
    

    latest

    rm -rf build/ deps/
    mos update latest
    mos build --local  --platform esp32 --clean
    mos flash --esp-erase-chip
    

    FS.Mkfs '{"dev_type": "esp32part", "dev_opts": "{\"label\": \"fs_ext\"}", "fs_type": "SPIFFS"}'

    [Jun 29 20:30:50.648] mgos_vfs_dev_open    esp32part ({"label": "fs_ext"}) -> 0x3ffb9ec0
    [Jun 29 20:30:50.655] mgos_vfs_mkfs        Create SPIFFS (dev 0x3ffb9ec0, opts )
    [Jun 29 20:30:50.663] mgos_vfs_fs_spiffs_m addr 0x0 size 262144 bs 4096 ps 256 es 4096 nfd 10 encr 0 =>
    [Jun 29 20:30:50.669] mgos_vfs_mkfs        FS SPIFFS : create failed
    

    The partition is created in both 2.3 and latest, but it looks like something happened when moving parts of the core code into libraries.

  • mamuespmamuesp Germany/Northern coast
    edited July 2

    Just for info: setting the watchdog timeout up to 30s or 60s in the mongoose-os source after a hint from @rojer helped me to be able to add bigger fs_ext filesystems and call FS.Mkfs and FS.Mount successfully. It's weird that mounting a 8MB SPIFF partition will need really 30s to finish .... Perhaps I may look into using FAT, if MOS supports this. Could be faster.

    Unfortunately the FS_SIZE problems remains, more than 2MB aren't possible without errors here. But with the additional filesystem I have a workaround. And it works with the latest version as well.

  • nliviunliviu Romania

    What do you mean by "I have a workaround"?

  • mamuespmamuesp Germany/Northern coast

    Well, I may use the now a little slow to mount but useable fs_ext partition as /mnt - but it would be nice to integrate a bigger file system with the FW. With a little effort the fs_extsolution works as well for now. It's obvious that if I had a bigger FS_SIZE instead, I could just add the directory with the files I need (mainly for web server use) just unter the filesystementry in YAML, but I'm ok dealing with the fact that I have to copy these files on the fs_ext partition manually to the device. As a flashing process won't touch these files, this is only needed when flashing for the first time or when files on the fs_ext partition are changed. Of course the timeout value has to be set to the higher value so the mounting will work - there has to be a solution which is acceptable for all. Perhaps the timeout could be augmented when booting and decreased after this ... I proposed that it would be helpful if the value could be dynamically configured.

  • nliviunliviu Romania

    Ok. I understand now.

    I managed to mount the fs_ext only with the following scenario:

    mos update release
    rm -rf build deps
    mos build --local
    mos flash --esp-erase-chip
    ...
    mos update latest
    rm -rf build deps
    mos build --local
    mos flash
    

    If I mos flash --esp-erase-chip after updating to latest, mkfs will fail.

  • nliviunliviu Romania
    edited July 3

    This commit fixed it.

    [Jul  3 17:47:48.993] mount_ext_fs         path=/ext, dev_type=esp32part, dev_opts={label: "fs_ext"}, fs_type=SPIFFS, fs_opts=null
    [Jul  3 17:47:49.002] mgos_vfs_dev_open    esp32part ({label: "fs_ext"}) -> 0x3ffc1d18
    [Jul  3 17:47:49.009] mgos_vfs_mount       Mount SPIFFS @ /ext (dev 0x3ffc1d18, opts ) -> 0x3ffc1d28
    [Jul  3 17:47:49.018] mgos_vfs_fs_spiffs_m addr 0x0 size 262144 bs 4096 ps 256 es 4096 nfd 10 encr 0 => -10025
    [Jul  3 17:47:49.027] mgos_vfs_fs_spiffs_m SPIFFS mount failed
    [Jul  3 17:47:49.031] mgos_vfs_mount       FS SPIFFS : mount failed
    [Jul  3 17:47:49.034] mount_ext_fs         mgos_vfs_mount FAILED! Try mgos_vfs_mkfs.
    [Jul  3 17:47:49.044] mgos_vfs_dev_open    esp32part ({label: "fs_ext"}) -> 0x3ffc1d28
    [Jul  3 17:47:49.050] mgos_vfs_mkfs        Create SPIFFS (dev 0x3ffc1d28, opts )
    [Jul  3 17:47:49.054] mgos_vfs_fs_spiffs_m addr 0x0 size 262144 bs 4096 ps 256 es 4096 nfd 10 encr 0 => -10025
    [Jul  3 17:47:50.281] mount_ext_fs         mgos_vfs_mkfs OK. Try mgos_vfs_mount again!
    [Jul  3 17:47:50.288] mgos_vfs_dev_open    esp32part ({label: "fs_ext"}) -> 0x3ffc1d28
    [Jul  3 17:47:50.295] mgos_vfs_mount       Mount SPIFFS @ /ext (dev 0x3ffc1d28, opts ) -> 0x3ffc1d38
    [Jul  3 17:47:50.371] mgos_vfs_mount       /ext: size 233681, used: 0, free: 233681
    
  • mamuespmamuesp Germany/Northern coast

    Yeah, and I believe the SPIFFS handling became faster ... and LFS is useable too .. so we are making progress! :smile:

Sign In or Register to comment.