ESP32 PSRAM support
Re: ESP32 PSRAM support
txs Ivan,
will take a small time(day) frame, i come back to this with the log you need.
best wishes
rudi
will take a small time(day) frame, i come back to this with the log you need.
best wishes
rudi
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
Re: ESP32 PSRAM support
rudi ;-) wrote:@ESP_Stanza
@johnlee
@ESP_igrr
please help to this never ending story now
Q: why this exampe run on Wrover 32MBit_1.8/32MBit_1.8 modul ( SoC Rev 0 )
but not on the custom 64MBit_wide/32MBit_1.8 ( SoC Rev 0 )
Q: the 64MBit is wide flash ( 1.8 .. 3.6 V ) and works with 1.8 and 3.3 - is there a problem with 1.8 driven wide flash and combine 1.8 psram?
Q: we use Lyontek PSRAM, is there a magic key for psram ( ESP-PSRAM32 ) ID and if this not match the PSRAM is not supported?
Q: is there a hidden/not knowed detail on HDK that we not know? ( missing the edited wrover shematic file - can u post now ? )
Q: we need the HDK wrover shematic with BOM like the WROOM32 modul.
best wishes
rudi
Hi guys,
as you know I've tried to get pSRAM working using Lyontek's modules.
Now I found this line in the ESP-IDF:
Code: Select all
if (((id >> PSRAM_MFG_ID_S) & PSRAM_MFG_ID_M) != PSRAM_MFG_ID_ESPRESSIF) {
return ESP_FAIL;
}
Source: https://github.com/espressif/esp-idf/bl ... ram.c#L529
This might explain why it wasn't working.
I feel like Espressif must have been aware of this?
I'm willing to give you the benefit of the doubt, but please understand that I feel mislead.
Can you please clarify the situation?
Do you want to restrict the compatible modules for some reason that I'm not aware of?
I'd really appreciate your feedback here.
best wishes
rudi
edit:
Log from my Special Bootloader Code with PSRAM Support
you see ESP-PSRAM32 Match ...
for (secure reason the first 2 byte i maked "black"
same firmware on lyontek:
Code: Select all
--- idf_monitor on /dev/ttyUSB0 115200 --- --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H --- 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:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0008,len:4 load:0x3fff000c,len:4540 load:0x40078000,len:12428 ho 0 tail 12 room 4 load:0x40080000,len:268 0x40080000: _iram_start at ??:? entry 0x40080034 0x40080034: _iram_start at ??:? I (47) boot: ALB-ESP32x64[0]-IDF v2.0-rc1-892-gded1cd3-dirty 2nd stage bootloader I (47) boot: compile date Jul 6 2017 I (54) boot: compile time 19:12:31 I (66) boot: by rudi ;-) TEST-SOP-OK? : I (7871) boot: input now character h I (11913) boot: Enabling RNG early entropy source... I (11913) boot: SPI Speed : 40MHz I (11913) boot: SPI Mode : DIO I (11922) boot: SPI Flash Size : 8MB I (11935) boot: Partition Table: I (11947) boot: ## Label Usage Type ST Offset Length I (11971) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (11994) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (12018) boot: 2 factory factory app 00 00 00010000 00100000 I (12042) boot: End of partition table I (12056) boot: Disabling RNG early entropy source... I (12073) boot: Loading app partition at offset 00010000 I (12611) boot: segment 0: paddr=0x00010018 vaddr=0x00000000 size=0x0ffe8 ( 65512) I (12612) boot: segment 1: paddr=0x00020008 vaddr=0x3f400010 size=0x071b0 ( 29104) map I (12629) boot: segment 2: paddr=0x000271c0 vaddr=0x3ffb0000 size=0x022f4 ( 8948) load I (12660) boot: segment 3: paddr=0x000294bc vaddr=0x40080000 size=0x00400 ( 1024) load 0x40080000: _iram_start at ??:? I (12683) boot: segment 4: paddr=0x000298c4 vaddr=0x40080400 size=0x14a34 ( 84532) load I (12750) boot: segment 5: paddr=0x0003e300 vaddr=0x400c0000 size=0x00000 ( 0) load I (12751) boot: segment 6: paddr=0x0003e308 vaddr=0x00000000 size=0x01d00 ( 7424) I (12769) boot: segment 7: paddr=0x00040010 vaddr=0x400d0018 size=0x2aba8 (175016) map 0x400d0018: _flash_cache_start at ??:? PSRAM enable was here: 1 we start now to test the psram, press key [0] : Read PSRAM ID Now, press key [1] :Guru Meditation Error of type IllegalInstruction occurred on core 0. Exception was unhandled. Register dump: PC : 0x400d1b6d PS : 0x00060530 A0 : 0x80082599 A1 : 0x3ffe3be0 0x400d1b6d: psram_read_id at /mnt/Share/psram/esp-idf-psram/components/esp32/./psram.c:347 A2 : 0x3ffe3c30 A3 : 0x00000023 A4 : 0x00000004 A5 : 0x00000000 A6 : 0x00000000 A7 : 0xfffffffe A8 : 0x00000001 A9 : 0x3ffe3b90 A10 : 0x00000001 A11 : 0x00000000 A12 : 0x00000034 A13 : 0x00000000 A14 : 0x00000000 A15 : 0x00000004 SAR : 0x00000017 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x40094c1c LEND : 0x40094c4a LCOUNT : 0xffffffff 0x40094c1c: memset at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memset.S:127 0x40094c4a: memset at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memset.S:171 Backtrace: 0x400d1b6d:0x3ffe3be0 0x40082599:0x3ffe3c30 0x40080f62:0x3ffe3c60 0x40078861:0x3ffe3ca0 0x40078a88:0x3ffe3cd0 0x40079160:0x3ffe3d50 0x40080109:0x3ffe3e70 0x40007c34:0x3ffe3eb0 0x40000740:0x3ffe3f20 0x400d1b6d: psram_read_id at /mnt/Share/psram/esp-idf-psram/components/esp32/./psram.c:347 0x40082599: esp_restart_noos at /mnt/Share/psram/esp-idf-psram/components/esp32/./system_api.c:338 0x40080f62: call_start_cpu0 at /mnt/Share/psram/esp-idf-psram/components/esp32/./cpu_start.c:200 (discriminator 1) 0x40080109: _WindowOverflow12 at ??:? Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0008,len:4 load:0xcf3f00c3,len:4195567 1162 mmu set 00010000, pos 00010000 1162 mmu set 00020000, pos 00020000 1162 mmu set 00030000, pos 00030000 1162 mmu set 00040000, pos 00040000 1162 mmu set 00050000, pos 00050000 1162 mmu set 00060000, pos 00060000 1162 mmu set 00070000, pos 00070000 1162 mmu set 00080000, pos 00080000 1162 mmu set 00090000, pos 00090000 1162 mmu set 000a0000, pos 000a0000 1162 mmu set 000b0000, pos 000b0000 1162 mmu set 000c0000, pos 000c0000 1162 mmu set 000d0000, pos 000d0000 1162 mmu set 000e0000, pos 000e0000 1162 mmu set 000f0000, pos 000f0000 1162 mmu set 00100000, pos 00100000 1162 mmu set 00110000, pos 00110000 1162 mmu set 00120000, pos 00120000 1162 mmu set 00130000, pos 00130000 1162 mmu set 00140000, pos 00140000 1162 mmu set 00150000, pos 00150000 1162 mmu set 00160000, pos 00160000 1162 mmu set 00170000, pos 00170000 1162 mmu set 00180000, pos 00180000 1162 mmu set 00190000, pos 00190000 ets Jun 8 2016 00:22:57 rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0008,len:4 load:0x3fff000c,len:4540 load:0x40078000,len:12428 ho 0 tail 12 room 4 load:0x40080000,len:268 0x40080000: _iram_start at ??:? entry 0x40080034 0x40080034: _iram_start at ??:? I (47) boot: ALB-ESP32x64[0]-IDF v2.0-rc1-892-gded1cd3-dirty 2nd stage bootloader I (47) boot: compile date Jul 6 2017 I (54) boot: compile time 19:12:31 I (66) boot: by rudi ;-) TEST-SOP-OK?
i am not more sure that "debug" works correctly
:
i will make a new fully example from scratch at weekend
that you can test by self too
cause you have Lyontek PSRAM now since last friday officially in the house
thanks for your understand
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
-
- Posts: 9761
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32 PSRAM support
I'm willing to give you an answer on this, but after the last fiasco, I want to be very very clear about one thing: Officially, we do NOT support any other chip than the ESP32 PSRAM. This means that officially we do NOT give out ANY support for this chip, at least not on this forum. That also means that any support you DO get is entirely given out of goodwill of the engineers hanging around this forum, not fact-checked, and can be wrong in any or all aspects. It also means that if you put this into a design and it doesn't work, it's not our problem.
Okay, with that said: the psram ID check is not the problem here. The bits of the ID that the code checks happens to be the same between the Lyontek PSRAM and the ESP32-PSRAM chip. Feel free to put a ets_printf when the check fails: you will not see it in the output.
I actually retrieved one of the Lyontek chips (didn't knew we had those) and reworked one of my ESP_Wrover_kit modules to take that instead of the module that was on there. With flash and PSRAM clocked at 40MHz, I have no problems and a stably-running Doom, and that is with the public psram esp-idf tree and Doom sources. With the flash running at 80MHz, the chip was less stable, it crashed within a few seconds where an ESP32-PSRAM would at the very least run for much longer.
Okay, with that said: the psram ID check is not the problem here. The bits of the ID that the code checks happens to be the same between the Lyontek PSRAM and the ESP32-PSRAM chip. Feel free to put a ets_printf when the check fails: you will not see it in the output.
I actually retrieved one of the Lyontek chips (didn't knew we had those) and reworked one of my ESP_Wrover_kit modules to take that instead of the module that was on there. With flash and PSRAM clocked at 40MHz, I have no problems and a stably-running Doom, and that is with the public psram esp-idf tree and Doom sources. With the flash running at 80MHz, the chip was less stable, it crashed within a few seconds where an ESP32-PSRAM would at the very least run for much longer.
Re: ESP32 PSRAM support
ok thank you -ESP_Sprite wrote:I'm willing to give you an answer on this, but after the last fiasco, I want to be very very clear about one thing: Officially, we do NOT support any other chip than the ESP32 PSRAM. This means that officially we do NOT give out ANY support for this chip, at least not on this forum. That also means that any support you DO get is entirely given out of goodwill of the engineers hanging around this forum, not fact-checked, and can be wrong in any or all aspects. It also means that if you put this into a design and it doesn't work, it's not our problem.
Okay, with that said: the psram ID check is not the problem here. The bits of the ID that the code checks happens to be the same between the Lyontek PSRAM and the ESP32-PSRAM chip. Feel free to put a ets_printf when the check fails: you will not see it in the output.
I actually retrieved one of the Lyontek chips (didn't knew we had those) and reworked one of my ESP_Wrover_kit modules to take that instead of the module that was on there. With flash and PSRAM clocked at 40MHz, I have no problems and a stably-running Doom, and that is with the public psram esp-idf tree and Doom sources. With the flash running at 80MHz, the chip was less stable, it crashed within a few seconds where an ESP32-PSRAM would at the very least run for much longer.
jeroen you tested on wrover kit on wrover modul with orig spi flash and lyontek psram successfull doom?
can you confirm this ( perhabs i missunderstand english )
can you say which SoC Rev you used on this?
can it be, that ESP-PSRAM32 works with Rev0 ( like in this demo )
and Lyontek not?
ok, can you share the knowledge:
we use this: ( psram64 is only a placeholder we use 32Mbit ) are sure, there is 10K on CS ( gpio 16 ) ?
cause :
When read the psram, The pin GPIO16( psram_CS) should be low right, but always high.
thank you for your time and efforts on this
best wishes
rudi
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
-
- Posts: 9761
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32 PSRAM support
No, this test is done on a Rev1, with psram-as-malloc-able-memory. Aside from that, yes - normal Wrover module, got rid of the esp32-psram, soldered in the Lyontek part in the same footprint.
At a glance, the schematic looks about right. My guess is that the 10K is only there so the RAM chip doesn't get accidentally enabled when the ESP32 is still booting up and GPIO16 is still Hi-Z.
Just curious: Is there a specific reason you need to have Rev0 working?
At a glance, the schematic looks about right. My guess is that the 10K is only there so the RAM chip doesn't get accidentally enabled when the ESP32 is still booting up and GPIO16 is still Hi-Z.
Just curious: Is there a specific reason you need to have Rev0 working?
Re: ESP32 PSRAM support
Ok - thank you - then it must go.ESP_Sprite wrote:No, this test is done on a Rev1, with psram-as-malloc-able-memory. Aside from that, yes - normal Wrover module, got rid of the esp32-psram, soldered in the Lyontek part in the same footprint.
Yes - I see and think so too.ESP_Sprite wrote: At a glance, the schematic looks about right. My guess is that the 10K is only there so the RAM chip doesn't get accidentally enabled when the ESP32 is still booting up and GPIO16 is still Hi-Z.
Not really Jeroen - it's just like that.ESP_Sprite wrote: Just curious: Is there a specific reason you need to have Rev0 working?
That Espressif at the earliest end August / Mid September (according to their information) again SoC Rev1 has available.
edit:
the wrover modul is also earliest available end of augus/ mid september then here
the psram are also not available, earliest end of august/ mid september
( sales " Eacen", and espressif itself )
I have the FW on Rev0 (Wrover) and Rev1 (Wrover) tried and runs.
Same firmware with Lyontek - and it breaks down,
In the moment when spi_enable (call read_id).
The Bootloader is loading well
and the communication over "user echo" works too
so spi flash is ok ( it is a wide range spi flash )
I just do not understand why it runs with ESP-PSRAM32
But with lyontek not. Same firmware, same SOC revision
The Lyontek module is located 10000 km away from here
and comes next days with express here -
But that should not be the reason
edit: i have the modul just in time not in the hand jeroen
that is the problem. but comes with express the next days.
Ok - with you it runs - ( lyontek on wrover modul soc rev1 on wrover kit )
Which gives me the hope that it must run on SoC REV1,
I am working on the weekend again and again and then give a report here.
thank you for your time and efforts
best wishes
rudi
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
Re: ESP32 PSRAM support
ok jeroenESP_Sprite wrote: i actually retrieved one of the Lyontek chips (didn't knew we had those) and reworked one of my ESP_Wrover_kit modules to take that instead of the module that was on there. With flash and PSRAM clocked at 40MHz, I have no problems and a stably-running Doom, and that is with the public psram esp-idf tree and Doom sources.
can you please -unofficially- run onetimes my firmware on your HW and post the LOG?
this firmware runs well on
ESP32 Wrover Rev0
ESP32 Wrover Rev1 on Wrover Kit V3
same FW runs not on a
Custom Board with the shematic i posted
and PSRAM from lyontek and wideflash
thank you.
best wishes
rudi
simple flash it like it is to 0x0
( it is only named as zip for the upload )
CRC32: 0D176E0E
CRC64: 994BD03EB3F6A190
SHA256: 309D417F1216C47BB5AE73802567F39169A5A784F7BDE890A5C4CA2534A59DFD
SHA1: A62A3DC51B38BABFF082D6CF64791F6DD31AA77A
BLAKE2sp: 34A9E5F8E933AE3854590E895E1FE15C3A9526053CEF844FF00D20B42365BFC1
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
Re: ESP32 PSRAM support
I didn't hear about those dates yet.rudi ;-) wrote: That Espressif at the earliest end August / Mid September (according to their information) again SoC Rev1 has available.
edit:
the wrover modul is also earliest available end of augus/ mid september then here
the psram are also not available, earliest end of august/ mid september
( sales " Eacen", and espressif itself )
Re: ESP32 PSRAM support
WiFive wrote:I didn't hear about those dates yet.rudi ;-) wrote: That Espressif at the earliest end August / Mid September (according to their information) again SoC Rev1 has available.
edit:
the wrover modul is also earliest available end of augus/ mid september then here
the psram are also not available, earliest end of august/ mid september
( sales " Eacen", and espressif itself )
not?
it is allways if you have good idea and want start 100k things...
so our kickstarter projects is paused since 1. june
... and if there is no change in the thinking over support in this - -
then better we close the things before we go online with campagne..
here i give you support in this:
hi ivan
i saw your postings on twitter -
nice, feel free decent to help further us with an test with this firmware i posted
and please post the log -
if there is all ok with your saying in the tweet about ID check pass then this must run on yours with Lyontek psram too
that the firmware is ok says
- runs on wrover rev0 with ESP-PSRAM32
- runs on wrover rev1 with ESP-PSRAM32
- runs on wrover rev0 with ESP-PSRAM32 on wrover kit v2
- runs on wrover rev1 with ESP-PSRAM32 on wrover kit v3
so -
i think the firmware is not the problem
thank you for your support
best wishes
rudi
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
Re: ESP32 PSRAM support
@WiFive
that is the reason why we search for alternates, and lyontek is great product too.
Stanley ( Lyontek ) was at espressif last friday and want help - not sure why or what the success was
or they start with lyontek too --
i ask me allways -
why my firmware not runs on this?
so - the best would be
that jeroen and ivan test the firmware one time
cause they havy runing lyontek hardware they say
for compare that the firmware is ok
they can test too
on wrover rev0 / rev1 and so on
cause here runs this on this.
if then the test is ok on they hardware
then i know, my friend in china has make a mistake in Hardware ( i do not believe - cause he ist the best of the best in this )
so there are only two choices then
test it - or not
it would help for all - if they shortley can test onetime and post the log
edit:
and cause we learned it the past, that "only if we pay you get the service you need"
make me please an offer
500 1000 10000 usd?
i pay for it guys
so feel free -
the last 3 years have much more money invest in this theme
so this peanuts not more much the end
thank you!
edit:
honest`?
ivan has read the thread
jeroen has read the thread
nobody downloaded the file yet
cause there is no interesst in this
is ok. stands in the toolchain - only ESP-PSRAM32 is supported.
but we want build modules and boards
and we get no psram and so on -
so ... there is then no interesst in SoC 32 too
...
i will talk with Teo next week cleartext, then we know more.
it allways the same - only if you find the blocked code
you know why it is not running -
i wounder me, if this would be in a blob lib
you do not find the true reason ever..
now the same here :
new download on psram future..
the thing do not more compile now:
so if you want history why there is something things run and not
save all things separatly -
i switch to my runing psram future back..
the doom example was the same example -
only after there was a "hey it does not run"
the finnish comes for a run...
why allways make a l l public?
...it is enough there is a code line ...that the user can see
it is not important that this run...the people have no psram .. and so on..
it is salami tactic not more.
but ok -
i respect this - there is no support given in lyontek
but then say it to stanley ( lyontek ) directly too
ok?!
bye
that is the reason why we search for alternates, and lyontek is great product too.
Stanley ( Lyontek ) was at espressif last friday and want help - not sure why or what the success was
or they start with lyontek too --
i ask me allways -
why my firmware not runs on this?
so - the best would be
that jeroen and ivan test the firmware one time
cause they havy runing lyontek hardware they say
for compare that the firmware is ok
they can test too
on wrover rev0 / rev1 and so on
cause here runs this on this.
if then the test is ok on they hardware
then i know, my friend in china has make a mistake in Hardware ( i do not believe - cause he ist the best of the best in this )
so there are only two choices then
test it - or not
it would help for all - if they shortley can test onetime and post the log
edit:
and cause we learned it the past, that "only if we pay you get the service you need"
make me please an offer
500 1000 10000 usd?
i pay for it guys
so feel free -
the last 3 years have much more money invest in this theme
so this peanuts not more much the end
thank you!
edit:
honest`?
ivan has read the thread
jeroen has read the thread
nobody downloaded the file yet
cause there is no interesst in this
is ok. stands in the toolchain - only ESP-PSRAM32 is supported.
but we want build modules and boards
and we get no psram and so on -
so ... there is then no interesst in SoC 32 too
...
i will talk with Teo next week cleartext, then we know more.
it allways the same - only if you find the blocked code
you know why it is not running -
i wounder me, if this would be in a blob lib
you do not find the true reason ever..
now the same here :
new download on psram future..
the thing do not more compile now:
so if you want history why there is something things run and not
save all things separatly -
i switch to my runing psram future back..
the doom example was the same example -
only after there was a "hey it does not run"
the finnish comes for a run...
why allways make a l l public?
...it is enough there is a code line ...that the user can see
it is not important that this run...the people have no psram .. and so on..
it is salami tactic not more.
but ok -
i respect this - there is no support given in lyontek
but then say it to stanley ( lyontek ) directly too
ok?!
bye
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
Who is online
Users browsing this forum: Baidu [Spider], MicroController and 110 guests