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:

  • did you get anywhere with the PSRAM?

  • mamuespmamuesp Germany/Northern coast
    edited August 15

    Yes, of course, it's in heavy use ...

    I added the following lines in mos.yml:

          build_vars:
            ESP_IDF_SDKCONFIG_OPTS: >
              ${build_vars.ESP_IDF_SDKCONFIG_OPTS}
              CONFIG_SPIRAM_SUPPORT=y
              CONFIG_SPIRAM_BOOT_INIT=y
              CONFIG_SPIRAM_CACHE_WORKAROUND=y
              CONFIG_SPI_MASTER_IN_IRAM=y
              CONFIG_SPIRAM_USE_CAPS_ALLOC=
    

    then after the next build, I found a huge amount of useable RAM in the device ... :wink: ... works fine. The CONFIG_SPI_MASTER_IN_IRAM=y could perhaps be let aside, the others are needed. With the last one it is regulated, how the RAM will be integrated in the system. With this settings, it's just added to the internal RAM and may be allocated via standard malloc().

  • good to know, thanks. I'll give that a try.

Sign In or Register to comment.