- This topic has 14 replies, 3 voices, and was last updated 4 years, 9 months ago by
.
-
Posts
-
Hi,
I’m working with ESP32-WROVER module with esp-idf vers 3.1.
This module has an internal SPI PSRAM of 4MB at 1.8V.
I tried to enable it in ESP-IDF configuratio menu enabling “Support for external, SPI-connected RAM”
But compile fails:
cc1: error: unrecognized command line option ‘-mfix-esp32-psram-cache-issue’
If I use in line make menuconfig and make flash all seems work.
Then I compared sdkconfig-debug created and used by VisualGDB with sdkconfig created by make menuconfig and I noted that in the GDBfile some lines are missed:
CONFIG_SPIRAM_BOOT_INIT=y
CONFIG_SPIRAM_IGNORE_NOTFOUND=
CONFIG_SPIRAM_USE_MEMMAP=
CONFIG_SPIRAM_USE_CAPS_ALLOC=
CONFIG_SPIRAM_USE_MALLOC=y
CONFIG_SPIRAM_TYPE_ESPPSRAM32=y
CONFIG_SPIRAM_SIZE=4194304
CONFIG_SPIRAM_SPEED_40M=y
CONFIG_SPIRAM_MEMTEST=y
CONFIG_SPIRAM_CACHE_WORKAROUND=y
CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL=16384
CONFIG_WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST=
CONFIG_SPIRAM_MALLOC_RESERVE_INTERNAL=32768
CONFIG_SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY=Can you help me to use PSRAM in ESP32 WROVER module?
Thank you very much
Lisa
Hi,
No problem and thanks for reporting this. Looks like one of the components in our toolchain was using files from an earlier build. We have fixed it and published an updated toolchain. Please update to the R12 toolchain via VisualGDB Package Manager.
Hi,
I tried to update toolchain from menu Manage VisualGDB Package but it was present only R11 version.
Directly in http://gnutoolchains.com/esp32/ R12 version is available but after launch downloaded exe file I have a message of “Access is denied” from Windows so it is impossible for me to use R12 version (on my PC I have Windows 10)
I tried with R11 version and I have the same compilation error:
error: unrecognized command line option ‘-mfix-esp32-psram-cache-issue’.
I attached file with my selections to use module’s PSRAM
On sdkconfig-debug file now I find:
CONFIG_SPIRAM_SUPPORT=y
#
# SPI RAM config
#
CONFIG_SPIRAM_BOOT_INIT=y
CONFIG_SPIRAM_IGNORE_NOTFOUND=
CONFIG_SPIRAM_USE_MEMMAP=y
CONFIG_SPIRAM_USE_CAPS_ALLOC=
CONFIG_SPIRAM_USE_MALLOC=
CONFIG_SPIRAM_TYPE_ESPPSRAM32=y
CONFIG_SPIRAM_SIZE=4194304
CONFIG_SPIRAM_SPEED_40M=y
CONFIG_SPIRAM_MEMTEST=y
CONFIG_SPIRAM_CACHE_WORKAROUND=ybut I don’t succed in compiling withou error
Hi,
There was a temporary issue with the R12 file on our server, sorry about that. Please try downloading it again.
I’m sorry but today the situation doesn’t change….the same as yesterday.
It’s not possible for me to update to R12 toolchain….this version isn’t proposed in Manage VisualGBD Packages and from http://gnutoolchains.com/esp32/ link the installing of R12 creates a Windows error.
I have a collegue that is using Visual Studio Professional instead of Visual Studio Community like me and now he has R12 toolchain proposed in Manage VisualGDB Packages.
We tried to install it (R12) and he succeded in compiling with PSRAM..so effectively with R12 version is possible to work with external PSRAM.
But I don’t understand why in my Visual Studio Community 2017 version 15.7.5 it’s not possible to see the new R12 toolchain.
Hello,
I’m having a similar problem. I am using the latest toolchain and I’m trying to use the external SPI ram memory but something isn’t working quite right.
I have done all possible combinations of PSram in the visualGDB settings but I can’t get the external memory working properly.
When I run the application I can see the external memory is tested and recognized by the system, however, it always returns a null pointer when I try to use the external memory.
For example, using this configuration bellow I can check that the heap increased and I have extra memory. But when I try to do a simple test like allocating 15KB, the ESP32 return null.
#
# ESP32-specific
#
CONFIG_ESP32_DEFAULT_CPU_FREQ_80=
CONFIG_ESP32_DEFAULT_CPU_FREQ_160=
CONFIG_ESP32_DEFAULT_CPU_FREQ_240=y
CONFIG_ESP32_DEFAULT_CPU_FREQ_MHZ=240
CONFIG_SPIRAM_SUPPORT=y#
# SPI RAM config
#CONFIG_SPIRAM_BOOT_INIT=y
CONFIG_SPIRAM_IGNORE_NOTFOUND=
CONFIG_SPIRAM_USE_MEMMAP=
CONFIG_SPIRAM_USE_CAPS_ALLOC=
CONFIG_SPIRAM_USE_MALLOC=y
CONFIG_SPIRAM_TYPE_AUTO=y
CONFIG_SPIRAM_TYPE_ESPPSRAM32=
CONFIG_SPIRAM_TYPE_ESPPSRAM64=
CONFIG_SPIRAM_SIZE=-1
CONFIG_SPIRAM_SPEED_40M=
CONFIG_SPIRAM_SPEED_80M=y
CONFIG_SPIRAM_MEMTEST=y
CONFIG_SPIRAM_CACHE_WORKAROUND=y
CONFIG_SPIRAM_BANKSWITCH_ENABLE=y
CONFIG_SPIRAM_BANKSWITCH_RESERVE=8
CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL=16384
CONFIG_WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST=
CONFIG_SPIRAM_MALLOC_RESERVE_INTERNAL=32768
CONFIG_SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY=y
CONFIG_SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY=I’m using esp32-cam which has 4MB PSRAM, I just can’t use it.
When I use make menuconfig, the external memory works and I can allocate anything without any problem.
I can’t just easily import my sdkconfig from my make menuconfig. Is there a way that I can use a pre-defined sdkconfig instead of the graphical one? I have the right configuration but I can’t get the same thing from the visualGDB interface. Also, every time when I compile it, my configuration file gets overwritten.
Sorry, this looks like an issue of the ESP-IDF itself and not anything specific to VisualGDB. Please consider asking on the ESP32 forum instead.
That said, if you can confirm that the project works as expected outside VisualGDB, but doesn’t work when built with VisualGDB, we can help you configure VisualGDB to match the manual build behavior.
Hi,
That is exactly what is happing. It works without the visualgdb.
So what is the right configuration to get the PSRAM using visualgdb and be able to allocate big buffers? Using visual studio code + Espressif SDK I have no problem.
I need this working in visual studio and visualgdb because the company uses this environment.
I think there are two ways, either I use the sdkconfig created by the make config from the IDF instead the one created by visualgdb UI, or I find a way to get the same configuration file from the visualgdb UI.
Also, I noticed visual gdb supports IDF version 3.2 and the latest so far is 4.1. When do you think we can have 4.1 SDK?
No problem, we can help you set it up then. Most likely, you are using different ESP-IDF/toolchain combinations with and without VisualGDB, leading to different results.
In that case, we would advise importing the working toolchain into VisualGDB as described in this post.
If it doesn’t help, please try importing an otherwise working project into VisualGDB using the same toolchain/ESP-IDF and describe what exactly happens when you try to build it manually vs. with VisualGDB. We will then help you replicate the manual build results with VisualGDB.
Regarding supported versions, visualGDB supports ESP-IDF versions up to 4.0 (the latest official release). You can download ready-to-use toolchains together with the compatible ESP-IDF checkouts from our ESP32 toolchain download page. We will support v4.1 once it is officially listed as a stable release on the ESP-IDF releases page.
Hi,
I tried to use the release/v4.0 and I couldn’t get the blink led example compiled.
The terminal came back with this:
make: *** No rule to make target ‘check_python_dependencies’, needed by ‘defconfig’. Stop.
————————————————————-
Command exited with code 2
Executable: c:\sysgcc\esp32\usr\bin\bash.exe
Arguments: –login -c “export IDF_PATH=/esp-idf/v4.0 && export BATCH_BUILD=1 && export PATH=/mingw32/bin:/usr/bin:$PATH && export -n PYTHONHOME && export LANG=en_US && cd /c/users/me/source/repos/EmbeddedProject13/EmbeddedProject13 && make defconfig BUILD_DIR_BASE=’/c/users/me/source/repos/EmbeddedProject13/EmbeddedProject13/VisualGDBCache/EmbeddedProject13-Debug-VisualGDB/CodeSenseDir’ SDKCONFIG=’/c/users/me/source/repos/EmbeddedProject13/EmbeddedProject13/sdkconfig-debug’ V=0”
Directory:
Command-line action failed
Project configuration failed: System.IO.FileNotFoundException: Could not find file ‘c:\users\me\source\repos\EmbeddedProject13\EmbeddedProject13\sdkconfig-debug’.
File name: ‘c:\users\me\source\repos\EmbeddedProject13\EmbeddedProject13\sdkconfig-debug’
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
at kw.a.s_2(tq1 a)
at ta.l(String a)
at ta.n_2()
at uq2.g()As soon as switch back to Release/v3.2 works right away.
Please let me know if I am doing something wrong.
Also, did you have time to help me out with the external memory allocation? Or if I can keep the same sdkconfig from make menuconfig?
Most likely, you ended up with an incompatible toolchain/ESP-IDF combination. Please see this page for a detailed explanation.
Hi, I found the problem, It was a hardware issue. We are allocating the pin io16 and it is connected internally in the CS of the PSRAM.
I managed to get the VS Code + IDF V3.3 working on the same project with Visual Studio + visualgdb. That is lighting fast as I don’t need to generate any extra script and I can load only the application layer once the bootloader is settled down. Sorry for saying that but it was 10 seconds against almost 1 minute to compile a simple change and load an application.The PSRAM is working from the sdkconfig generated from visualgdb.
Thanks for your feedback.
Regarding the performance, most likely you are using a different build system and a different programming method (e.g. CMake vs. GNU Make and Serial port vs. JTAG). VisualGDB supports both build and both programming methods, and as long as you are using the same method with both IDEs, the build performance should be the same. Also MinGW-based toolchains are much faster than Cygwin-based toolchains, so please make sure you are using the same toolchain in both cases.
- You must be logged in to reply to this topic.