- Rebooting...
- I (10) boot: ESP-IDF v4.1-beta2-141-g84b51781c-dirty 2nd stage bootloader
- I (10) boot: compile time 15:55:17
- I (10) boot: chip revision: 1
- I (14) boot_comm: chip revision: 1, min. bootloader chip revision: 0
- I (21) qio_mode: Enabling default flash chip QIO
- I (26) boot.esp32: SPI Speed : 80MHz
- I (31) boot.esp32: SPI Mode : QIO
- I (35) boot.esp32: SPI Flash Size : 8MB
- I (40) boot: Enabling RNG early entropy source...
- I (45) boot: Partition Table:
- I (49) boot: ## Label Usage Type ST Offset Length
- I (56) boot: 0 nvs_fw WiFi data 01 02 00009000 00004000
- I (64) boot: 1 otadata OTA data 01 00 0000d000 00002000
- I (71) boot: 2 phy_init RF data 01 01 0000f000 00001000
- I (79) boot: 3 firmware factory app 00 00 00010000 000d0000
- I (86) boot: 4 apptable Unknown data 01 fe 000e0000 00020000
- I (94) boot: 5 ogo-shell OTA app 00 10 00100000 000bd000
- I (101) boot: 6 nvs WiFi data 01 02 001bd000 00003000
- I (109) boot: End of partition table
- I (113) boot_comm: chip revision: 1, min. application chip revision: 0
- I (120) esp_image: segment 0: paddr=0x00100020 vaddr=0x3f400020 size=0x23588 (144776) map
- I (171) esp_image: segment 1: paddr=0x001235b0 vaddr=0x3ffb0000 size=0x03080 ( 12416) load
- I (175) esp_image: segment 2: paddr=0x00126638 vaddr=0x40080000 size=0x00400 ( 1024) load
- 0x40080000: _WindowOverflow4 at /home/users/clusetic/esp/esp-idf/components/freertos/xtensa_vectors.S:1778
- I (178) esp_image: segment 3: paddr=0x00126a40 vaddr=0x40080400 size=0x095d0 ( 38352) load
- 0x40080400: _init at ??:?
- I (200) esp_image: segment 4: paddr=0x00130018 vaddr=0x400d0018 size=0x5ad58 (372056) map
- I (309) esp_image: segment 5: paddr=0x0018ad78 vaddr=0x400899d0 size=0x05228 ( 21032) load
- 0x400899d0: uxQueueMessagesWaiting at /home/users/clusetic/esp/esp-idf/components/freertos/queue.c:1752 (discriminator 1)
- I (316) esp_image: segment 6: paddr=0x0018ffa8 vaddr=0x400c0000 size=0x0006c ( 108) load
- I (325) boot: Loaded app from partition at offset 0x100000
- I (325) boot: Disabling RNG early entropy source...
- I (327) spiram: Found 4095MBit SPI RAM device
- I (332) spiram: SPI RAM mode: flash 80m sram 80m
- I (337) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
- I (345) cpu_start: Pro cpu up.
- I (348) cpu_start: Starting app cpu, entry point is 0x400813d4
- 0x400813d4: call_start_cpu0 at /home/users/clusetic/esp/esp-idf/components/esp32/cpu_start.c:156
- I (350) cpu_start: App cpu up.
- I (359) heap_init: Initializing. RAM available for dynamic allocation:
- I (366) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
- I (372) heap_init: At 3FFB55D8 len 0002AA28 (170 KiB): DRAM
- I (378) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
- I (384) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
- I (391) heap_init: At 4008EBF8 len 00011408 (69 KiB): IRAM
- I (397) cpu_start: Pro cpu start user code
- I (402) spiram: Adding pool of 0K of external SPI memory to heap allocator
- E (409) cpu_start: External RAM could not be added to heap!
- abort() was called at PC 0x4008138e on core 0
- 0x4008138e: call_start_cpu1 at /home/users/clusetic/esp/esp-idf/components/esp32/cpu_start.c:294
- Backtrace: 0x40089767:0x3ffe3bf0 0x40089a99:0x3ffe3c10 0x4008138e:0x3ffe3c30 0x400815af:0x3ffe3c60 0x4007976a:0x3ffe3c80 0x40079bd9:0x3ffe3cc0 0x40080761:0x3ffe3df0 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20
- 0x40089767: xQueueGiveFromISR at /home/users/clusetic/esp/esp-idf/components/freertos/queue.c:1430
- 0x40089a99: prvDeleteTLS at /home/users/clusetic/esp/esp-idf/components/freertos/tasks.c:3925
- 0x4008138e: call_start_cpu1 at /home/users/clusetic/esp/esp-idf/components/esp32/cpu_start.c:294
- 0x400815af: esp_crosscore_int_send at /home/users/clusetic/esp/esp-idf/components/esp32/crosscore_int.c:103
ESP32-WROVER modules from different batches
ESP32-WROVER modules from different batches
I have hardware design based around ESP32 and SD card(among others). User selects application from SD card that preloads into ESP32. The problem is that some apps don't start because they can't initialize external PSRAM, others that don't use external PSRAM work fine. There is UART output attached.
The problem is that I have two batches of ESP32 modules. Old from TME.com and new from digikey.com. On old batch everything works fine(PSRAM initializes), but on new it fails to do so. Hardware(PCB) and software is identical for New and Old batch. There are pics of old and new batch modules, old modules are the ones with IPX connector. Markings are identical, except for "XX0H64" marking on new batch modules.
Are those modules interchangeable?
Are new batch modules genuine?
The problem is that I have two batches of ESP32 modules. Old from TME.com and new from digikey.com. On old batch everything works fine(PSRAM initializes), but on new it fails to do so. Hardware(PCB) and software is identical for New and Old batch. There are pics of old and new batch modules, old modules are the ones with IPX connector. Markings are identical, except for "XX0H64" marking on new batch modules.
Are those modules interchangeable?
Are new batch modules genuine?
- Attachments
-
- Pics_ESP32.zip
- (5.39 MiB) Downloaded 447 times
-
- Posts: 9769
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-WROVER modules from different batches
Can you post the log from the device where PSRAM initialization fails? There are multiple WROVER modules and some have 4MB PSRAM and some 8MB PSRAM. If the selection of PSRAM in esp-idf is hardcoded to one of the types, running the code on a board with the other will not work. Same if ESP-IDF is too old to know about the 8MB chip. The -64 marking on the newer modules hints at 8MB (=64MBit) of PSRAM, so this may be the issue you're having.
Re: ESP32-WROVER modules from different batches
Hello, Sprite.
I did FASTRD with flash download tool v3.8.5 on both batches, and they both read:
flash vendor:
C8h : GD
flash devID:
4017h
QUAD;64Mbit
crystal:
40 Mhz
Pictures of the log are attached, as are pics of modules with removed shield. If you look those pics you will see the same marking on PSRAM "ESP-PSRAM64H" indicating same version. Older batch of modules was bought at the end of 2019, and newer was bought few weeks ago.
I did FASTRD with flash download tool v3.8.5 on both batches, and they both read:
flash vendor:
C8h : GD
flash devID:
4017h
QUAD;64Mbit
crystal:
40 Mhz
Pictures of the log are attached, as are pics of modules with removed shield. If you look those pics you will see the same marking on PSRAM "ESP-PSRAM64H" indicating same version. Older batch of modules was bought at the end of 2019, and newer was bought few weeks ago.
- Attachments
-
- Pic of old PSRAM marking
- Old_Psram.jpg (375.71 KiB) Viewed 8213 times
-
- FAIL log output
- NewBatchOutput.png (96.25 KiB) Viewed 8213 times
-
- Pic of new PSRAM marking
- New_Psram.jpg (348.97 KiB) Viewed 8213 times
-
- Posts: 9769
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-WROVER modules from different batches
That is strange... ESP-IDF 3.1 is a bit old, though; do you have the same issue when you recompile with the latest ESP-IDF 3.3 version?
Re: ESP32-WROVER modules from different batches
Hi, I have tried to compile with ESP-IDF v4.1, but with no luck. Sill same problem.
Re: ESP32-WROVER modules from different batches
Hi, guys any ideas? Still stuck with the same problem.
-
- Posts: 9769
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-WROVER modules from different batches
Not really... I assume that you have this issue with multiple modules, so it's not just one module that acts up? Can you post the schematic of the board the thing is in? If not, is there anything connected to pin 17, 18, 19-22 of the module? Are the NC pins of the module tied to anything?
Re: ESP32-WROVER modules from different batches
I know about one situation, where on wrover E module client has problems with PSRAM.
Sometimes, very often actually, after restart PSRAM is having problem to pass initialization test. I am suspecting hardware problem.
Sometimes, very often actually, after restart PSRAM is having problem to pass initialization test. I am suspecting hardware problem.
Re: ESP32-WROVER modules from different batches
Look into the following
Should be 8mb
Should not be 0
Code: Select all
spiram: Found 4095MBit SPI RAM device
Code: Select all
Adding pool of 0K of external SPI memory to heap allocator
Re: ESP32-WROVER modules from different batches
Thx for help guys but still no luck.
@ESP_Sprite
Yep, all those pins are not connected.
@chegewara
Similar problem here. Same code works on identical board with old modules and not on ones with new modules. I am using WROVER-B veriants.
@WiFive
Yes there is the problem(with PSRAM). ESP32-WROVER has 8MB of RAM but it can only use 4MB. Tried this: [thingpulse.com/esp32-how-to-use-psram] and I can access PSRAM on both modules(new and old) and they are the same size. The problem is with specific application that does not work even when compiled with new ESP-IDF v4.1. Guess I will have to look at the source code and debug it from there.
@ESP_Sprite
Yep, all those pins are not connected.
@chegewara
Similar problem here. Same code works on identical board with old modules and not on ones with new modules. I am using WROVER-B veriants.
@WiFive
Yes there is the problem(with PSRAM). ESP32-WROVER has 8MB of RAM but it can only use 4MB. Tried this: [thingpulse.com/esp32-how-to-use-psram] and I can access PSRAM on both modules(new and old) and they are the same size. The problem is with specific application that does not work even when compiled with new ESP-IDF v4.1. Guess I will have to look at the source code and debug it from there.
Who is online
Users browsing this forum: No registered users and 55 guests