Mark, I'll do a new build this afternoon. It's really nice we're getting more RAM on the fly. Btw, we will need a separate build config once they also fix the PSRAM bug on the core. The workaround eats some performance (not too much, but still). Regards, Michael Am 11.12.19 um 04:40 schrieb Mark Webb-Johnson:
_*Short story:*_
I suggest you set your development and production sdkconfig to:
CONFIG_SPIRAM_TYPE_AUTO=y CONFIG_SPIRAM_TYPE_ESPPSRAM32= CONFIG_SPIRAM_SIZE=-1
If you prefer menus, you can find that in 'make menuconfig': Compont config / ESP32-specific / SPI RAM config / Type of SPI RAM chip in use. Set it to Auto-detect.
_*Long story:*_
We previously used a hard-coded selection of "ESP-PSRAM32 or IS25WP032”, but that won’t work with the new ESP32-WROVER-B modules we are now using (as Espressif have discontinued the 4MB versions). Those new modules have 8MB PSRAM and are "ESP-PSRAM64 or LY68L6400”. The auto-detect setting seems to work well, and can detect and support the installed PSRAM automatically.
With this new setting, we get:
4MB PSRAM module:
I (895) psram: This chip is ESP32-D0WD I (896) spiram: Found 32MBit SPI RAM device
8MB PSRAM module:
I (882) psram: This chip is ESP32-D0WD I (882) spiram: Found 64MBit SPI RAM device
Without this auto-detect, OTA updating to our latest firmware will produce an endless loop:
I (882) psram: This chip is ESP32-D0WD E (882) spiram: Expected 4096KiB chip but found 8192KiB chip. Bailing out.. E (883) cpu_start: Failed to init external RAM! abort() was called at PC 0x400817fc on core 0
Annoyingly, the bootloader code to detect a failure to load the OTA firmware doesn’t work, so it can’t fall back to factory.
It can be recovered to factory using ESPTOOL:
esptool.py --chip esp32 --port <path-to-serial-port> --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0xd000 ota_data_initial.bin 0x8000 partitions.bin
I have built an edge release based on this, and will leave for 24 hours. If ok, I will then move that to EAP and to MAIN at the weekend. This will be 3.2.008. We need to get this out ASAP, as recipients of the new modules may do an OTA update and have issues (so far only 1, and he recovered using esptool).
@Michael: I suggest you follow with your server. Let me know the path to your new update (from SPIRAM branch) and I will test on the ESP32-WROVER-B 8MB module I have here.
Regards, Mark.
On 9 Dec 2019, at 9:42 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Our latest wifi-only modules are coming with ESP-WROVER-B module, and that includes 8MB PSRAM/SPIRAM (not 4MB, our standard so far). I have had one report from the field that factory firmware 3.2.002 works fine, but 3.2.005 crashes on boot with an error:
(824) psram: This chip is ESP32-D0WD[[0m (824) spiram: Expected 4096KiB chip but found 8192KiB chip. Bailing out..
I see we have this in our sdkconfig:
Type of SPI RAM chip in use ( ) Auto-detect (X) ESP-PSRAM32 or IS25WP032 ( ) ESP-PSRAM64 or LY68L6400
Not sure when that appeared, but I guess between 3.2.002 and 3.2.005.
The user experiencing this problem is knowledgeable (he managed to recover back to factory), so I am trying a 3.2.007 build with him, with that setting set to auto-detect.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26