Thoughts on the ALB32-WROVER modules?

[cmorgan]

I'm starting to bump into flash size limits here with about .8MB of application. Much of that is system libraries, newlib, mbedtls, wifi libraries etc. I came across the ALB32-WROVER, https://www.analoglamb.com/product/alb3 ... 2mb-psram/, does anyone have experience with these modules? Is this a good approach if more flash is needed?

These guys look like the only ones making a larger sized module which is surprising. I would imagine for the slight increase in cost that a new version of the esp-wrover-32 could have 8MB of flash and 8MB of psram as well. Thoughts?

Chris

[WiFive]

A 128mbit wrover was rumored, not sure about wroom

Since wrover is $4, $6 for 128mbit + 32mbit psram would be ok.

[loboris]

I've tested ALB32-WROVER with 8MB Flash & 4MB SPIRAM and couldn't find any difference compared to ESP32-WROVER.
The only "problem" is it has ESP32 rev 0, it was promissed the next batch will be with rev 1 ESP32.
SPIRAM works without problem.

[WiFive]

SPIRAM works without problem.

https://github.com/espressif/esp-idf/bl ... icon_bug.c

[loboris]

SPIRAM works without problem.

https://github.com/espressif/esp-idf/bl ... icon_bug.c

I've run the tests and on ALB32-WROVER the test runs exactly the same as on ESP32-WROVER, all test passes.

There is no test_psram_silicon_bug.c in latest esp-idf master.
spiram is tested with test_spiram_cache_flush.c.

Acctually the last test Running Spiram memcmp weirdness at 80MHz... fails with

Code: Select all

MALLOC_CAP_8BIT critical leak: Before 4479416 bytes free, After 4348312 bytes free (delta 131104)
/home/LoBo2_Razno/ESP32/esp-idf_test/tools/unit-test-app/components/unity/./unity_platform.c:82:Spiram memcmp weirdness at 80MHz:FAIL: The test leaked too much memory

The test function passes with no spiram errors detected, so the error is not spiram related.
This is the same on both tested modules.

[WiFive]

Hmm interesting

[ESP_igrr]

Please note that the cache bug in rev0 of the ESP32 is not very easy to trigger. So it is possible that the application may seem to run correctly, but there is a chance that it will fail after some time in unpredictable way.
As WiFive has mentioned, test_psram_silicon_bug.c from psram branch can be used to reproduce the bug on rev0 ESP32.

[WiFive]

Seems like a bad practice to ship these modules with rev0 + psram at all then.

[loboris]

I've contacted AnalogLamb about that issue and they promissed to replace the chip in the next batch.
At least, they put a warning ( ESP32 is REV0 Chip ) on the product page but with no information of the possible issues.
Only the 8MB Flash version is still on stock, they should probably lower the price and sell it as ALB-WROOM32.

[loboris]

Please note that the cache bug in rev0 of the ESP32 is not very easy to trigger. So it is possible that the application may seem to run correctly, but there is a chance that it will fail after some time in unpredictable way.
As WiFive has mentioned, test_psram_silicon_bug.c from psram branch can be used to reproduce the bug on rev0 ESP32.

I could not reproduce the bug running test_psram_silicon_bug.c with latest esp-idf.

I've run the psram test (test_psram_silicon_bug.c) on ALB-WROVER with ESP32 rev0 (latest esp-idf), NO ERROR:

/*
This code triggers a psram-related silicon bug in rev0 silicon. The bug is fixed in rev1 silicon.
*/

Tested with:
Flash: QIO mode @ 80MHz, SPIRAM @ 80MHz.
Flash: QIO mode @ 40MHz, SPIRAM @ 40MHz.

Code: Select all

Flashing binaries to serial port /dev/ttyUSB0 (app at offset 0x10000)...
esptool.py v2.1
Connecting......
Chip is ESP32D0WDQ6 (revision 0)
Uploading stub...
...
...

Code: Select all

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:4492
load:0x40078000,len:0
load:0x40078000,len:12976
entry 0x40078d10
I (87) spiram: SPI RAM mode: flash 80m sram 80m
I (87) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (88) cpu_start: Pro cpu up.
I (91) cpu_start: Starting app cpu, entry point is 0x40081268
0x40081268: call_start_cpu1 at /home/LoBo2_Razno/ESP32/esp-idf_test/components/esp32/./cpu_start.c:222

I (0) cpu_start: App cpu up.
I (535) spiram: SPI SRAM memory test OK
I (535) heap_init: Initializing. RAM available for dynamic allocation:
I (536) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (542) heap_init: At 3FFB57F0 len 0002A810 (170 KiB): DRAM
I (548) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (554) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (561) heap_init: At 4008EE2C len 000111D4 (68 KiB): IRAM
I (567) cpu_start: Pro cpu start user code
I (572) spiram: Adding pool of 4096K of external SPI memory to heap allocator
I (45) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.


Press ENTER to see the list of tests.
.....
[psram]
.....
Running tests matching '[psram]'...
Running PSram bug in rev0 silicon (Doom bug)...
Stack ptr 0x3ffbae08
lumpinfo ptr 0x3f80002c
Running corruption test...
/home/LoBo2_Razno/ESP32/esp-idf_test/components/esp32/test/./test_psram_silicon_bug.c:92:PSram bug in rev0 silicon (Doom bug):PASS

-----------------------
1 Tests 0 Failures 0 Ignored 
OK
Enter next test, or 'enter' to see menu

I've also run this test in a loops of 100 tests and had no errors.

Code: Select all

Running PSram bug in rev0 silicon (Doom bug)...
Stack ptr 0x3ffbade8
100 passes
/home/LoBo2_Razno/ESP32/esp-idf_test/components/esp32/test/./test_psram_silicon_bug.c:92:PSram bug in rev0 silicon (Doom bug):PASS
Test ran in 13274ms

-----------------------
1 Tests 0 Failures 0 Ignored 
OK
Enter next test, or 'enter' to see menu