ESP32-WROVER modules from different batches

MileBL
Posts: 5
Joined: Tue Jul 07, 2020 10:02 am

ESP32-WROVER modules from different batches

Postby MileBL » Tue Jul 07, 2020 10:35 am

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?
Attachments
Pics_ESP32.zip
(5.39 MiB) Downloaded 396 times

ESP_Sprite
Posts: 9013
Joined: Thu Nov 26, 2015 4:08 am

Re: ESP32-WROVER modules from different batches

Postby ESP_Sprite » Tue Jul 07, 2020 1:54 pm

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.

MileBL
Posts: 5
Joined: Tue Jul 07, 2020 10:02 am

Re: ESP32-WROVER modules from different batches

Postby MileBL » Wed Jul 08, 2020 12:11 pm

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.
Attachments
Old_Psram.jpg
Pic of old PSRAM marking
Old_Psram.jpg (375.71 KiB) Viewed 7478 times
NewBatchOutput.png
FAIL log output
NewBatchOutput.png (96.25 KiB) Viewed 7478 times
New_Psram.jpg
Pic of new PSRAM marking
New_Psram.jpg (348.97 KiB) Viewed 7478 times

ESP_Sprite
Posts: 9013
Joined: Thu Nov 26, 2015 4:08 am

Re: ESP32-WROVER modules from different batches

Postby ESP_Sprite » Wed Jul 08, 2020 7:58 pm

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?

MileBL
Posts: 5
Joined: Tue Jul 07, 2020 10:02 am

Re: ESP32-WROVER modules from different batches

Postby MileBL » Thu Jul 09, 2020 3:02 pm

Hi, I have tried to compile with ESP-IDF v4.1, but with no luck. Sill same problem.
  1. Rebooting...
  2. I (10) boot: ESP-IDF v4.1-beta2-141-g84b51781c-dirty 2nd stage bootloader
  3. I (10) boot: compile time 15:55:17
  4. I (10) boot: chip revision: 1
  5. I (14) boot_comm: chip revision: 1, min. bootloader chip revision: 0
  6. I (21) qio_mode: Enabling default flash chip QIO
  7. I (26) boot.esp32: SPI Speed      : 80MHz
  8. I (31) boot.esp32: SPI Mode       : QIO
  9. I (35) boot.esp32: SPI Flash Size : 8MB
  10. I (40) boot: Enabling RNG early entropy source...
  11. I (45) boot: Partition Table:
  12. I (49) boot: ## Label            Usage          Type ST Offset   Length
  13. I (56) boot:  0 nvs_fw           WiFi data        01 02 00009000 00004000
  14. I (64) boot:  1 otadata          OTA data         01 00 0000d000 00002000
  15. I (71) boot:  2 phy_init         RF data          01 01 0000f000 00001000
  16. I (79) boot:  3 firmware         factory app      00 00 00010000 000d0000
  17. I (86) boot:  4 apptable         Unknown data     01 fe 000e0000 00020000
  18. I (94) boot:  5 ogo-shell        OTA app          00 10 00100000 000bd000
  19. I (101) boot:  6 nvs              WiFi data        01 02 001bd000 00003000
  20. I (109) boot: End of partition table
  21. I (113) boot_comm: chip revision: 1, min. application chip revision: 0
  22. I (120) esp_image: segment 0: paddr=0x00100020 vaddr=0x3f400020 size=0x23588 (144776) map
  23. I (171) esp_image: segment 1: paddr=0x001235b0 vaddr=0x3ffb0000 size=0x03080 ( 12416) load
  24. I (175) esp_image: segment 2: paddr=0x00126638 vaddr=0x40080000 size=0x00400 (  1024) load
  25. 0x40080000: _WindowOverflow4 at /home/users/clusetic/esp/esp-idf/components/freertos/xtensa_vectors.S:1778
  26.  
  27. I (178) esp_image: segment 3: paddr=0x00126a40 vaddr=0x40080400 size=0x095d0 ( 38352) load
  28. 0x40080400: _init at ??:?
  29.  
  30. I (200) esp_image: segment 4: paddr=0x00130018 vaddr=0x400d0018 size=0x5ad58 (372056) map
  31. I (309) esp_image: segment 5: paddr=0x0018ad78 vaddr=0x400899d0 size=0x05228 ( 21032) load
  32. 0x400899d0: uxQueueMessagesWaiting at /home/users/clusetic/esp/esp-idf/components/freertos/queue.c:1752 (discriminator 1)
  33.  
  34. I (316) esp_image: segment 6: paddr=0x0018ffa8 vaddr=0x400c0000 size=0x0006c (   108) load
  35. I (325) boot: Loaded app from partition at offset 0x100000
  36. I (325) boot: Disabling RNG early entropy source...
  37. I (327) spiram: Found 4095MBit SPI RAM device
  38. I (332) spiram: SPI RAM mode: flash 80m sram 80m
  39. I (337) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
  40. I (345) cpu_start: Pro cpu up.
  41. I (348) cpu_start: Starting app cpu, entry point is 0x400813d4
  42. 0x400813d4: call_start_cpu0 at /home/users/clusetic/esp/esp-idf/components/esp32/cpu_start.c:156
  43.  
  44. I (350) cpu_start: App cpu up.
  45. I (359) heap_init: Initializing. RAM available for dynamic allocation:
  46. I (366) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
  47. I (372) heap_init: At 3FFB55D8 len 0002AA28 (170 KiB): DRAM
  48. I (378) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
  49. I (384) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
  50. I (391) heap_init: At 4008EBF8 len 00011408 (69 KiB): IRAM
  51. I (397) cpu_start: Pro cpu start user code
  52. I (402) spiram: Adding pool of 0K of external SPI memory to heap allocator
  53. E (409) cpu_start: External RAM could not be added to heap!
  54. abort() was called at PC 0x4008138e on core 0
  55. 0x4008138e: call_start_cpu1 at /home/users/clusetic/esp/esp-idf/components/esp32/cpu_start.c:294
  56.  
  57.  
  58. Backtrace: 0x40089767:0x3ffe3bf0 0x40089a99:0x3ffe3c10 0x4008138e:0x3ffe3c30 0x400815af:0x3ffe3c60 0x4007976a:0x3ffe3c80 0x40079bd9:0x3ffe3cc0 0x40080761:0x3ffe3df0 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20
  59. 0x40089767: xQueueGiveFromISR at /home/users/clusetic/esp/esp-idf/components/freertos/queue.c:1430
  60.  
  61. 0x40089a99: prvDeleteTLS at /home/users/clusetic/esp/esp-idf/components/freertos/tasks.c:3925
  62.  
  63. 0x4008138e: call_start_cpu1 at /home/users/clusetic/esp/esp-idf/components/esp32/cpu_start.c:294
  64.  
  65. 0x400815af: esp_crosscore_int_send at /home/users/clusetic/esp/esp-idf/components/esp32/crosscore_int.c:103

MileBL
Posts: 5
Joined: Tue Jul 07, 2020 10:02 am

Re: ESP32-WROVER modules from different batches

Postby MileBL » Wed Jul 15, 2020 9:42 am

Hi, guys any ideas? Still stuck with the same problem.

ESP_Sprite
Posts: 9013
Joined: Thu Nov 26, 2015 4:08 am

Re: ESP32-WROVER modules from different batches

Postby ESP_Sprite » Wed Jul 15, 2020 12:58 pm

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?

chegewara
Posts: 2230
Joined: Wed Jun 14, 2017 9:00 pm

Re: ESP32-WROVER modules from different batches

Postby chegewara » Wed Jul 15, 2020 3:22 pm

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.

WiFive
Posts: 3529
Joined: Tue Dec 01, 2015 7:35 am

Re: ESP32-WROVER modules from different batches

Postby WiFive » Wed Jul 15, 2020 9:11 pm

Look into the following

Code: Select all

spiram: Found 4095MBit SPI RAM device
Should be 8mb

Code: Select all

Adding pool of 0K of external SPI memory to heap allocator
Should not be 0

MileBL
Posts: 5
Joined: Tue Jul 07, 2020 10:02 am

Re: ESP32-WROVER modules from different batches

Postby MileBL » Wed Jul 22, 2020 9:02 am

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.

Who is online

Users browsing this forum: No registered users and 57 guests