[gojimmypi]

That seemed like a reasonable approach, although I was left wondering why system-wide environment value would not be “seen” by cmake?

In any case, it didn’t work.  (see attached). I still see the error:

Requirement files:
- C:\SysGCC\esp32\esp-idf\v5.2\tools\requirements\requirements.core.txt
Python being checked: C:\SysGCC\esp32-master\python_env\\idf5.2_py3.8_env\Scripts\python.exe
Manifest files have changed, solving dependencies.
..-- Configuring incomplete, errors occurred!
CMake Error at C:/SysGCC/esp32/esp-idf/v5.2/tools/cmake/build.cmake:544 (message):
WARNING: Component "gojimmypi/mywolfssl" not found

ERROR: Because project depends on gojimmypi/mywolfssl (^5.7.1-preview2f1)
which doesn't match any versions, version solving failed.

Call Stack (most recent call first):

Here it is in WSL using the same toolchain; first, the error is expected since there’s no release called mywolfssl

$ idf.py add-dependency "gojimmypi/mywolfssl^5.7.1-preview2f1"
Executing action: add-dependency
ERROR: Component "gojimmypi/mywolfssl" not found

Here it is setting the staging site environment variable:

gojimmypi:/mnt/c/workspace/esp32-homekit-demo-gojimmypi-pr/examples/led
$ export IDF_COMPONENT_REGISTRY_URL=https://components-staging.espressif.com
gojimmypi:/mnt/c/workspace/esp32-homekit-demo-gojimmypi-pr/examples/led
$ idf.py add-dependency "gojimmypi/mywolfssl^5.7.1-preview2f1"
Executing action: add-dependency
Successfully added dependency "gojimmypi/mywolfssl^5.7.1-preview2f1" to component "main"

It then successfully builds using the staging instance of gojimmypi/mywolfssl.

Also, after attempting to build and revisiting the IDF_COMPONENT_REGISTRY_URL=https://components-staging.espressif.com shown in the attached screen snip, when clicking on the newly created IDF_COMPONENT_REGISTRY_URL value, Visual Studio became unresponsive and restarted.

Other than this anomaly, VisualGDB is working great.

Attachments:

You must be logged in to view attached files.

[gojimmypi]

Aha! Great! Thanks for the update.

I should add this is also quite helpful for installing multiple versions of the ESP-IDF toolchain:

https://visualgdb.com/documentation/espidf/#toolchains

[gojimmypi]

In my C:\SysGCC I have manually installed C:\SysGCC\esp32-11.2 and C:\SysGCC\esp32-8.4 for the older toolchains, in addition to the default install of C:\SysGCC\esp32 which has version 12.1 of the toolchain.

Inside each of *those* directories, I have different versions of the ESP-IDF SDK, for instance:

In my C:\SysGCC\esp32\esp-idf, I performed “git clone [repo] [sdk name]” for these:

esp-idf-v5.2-beta1
master
v5.0
v5.1

That allows relatively each changing of SDK and toolchains. Be sure to delete the build directory and sdkconfig file when changing.

I’ve found that simply keeping different versions of the project file much easier than manually changing them to different SDK & toolchain versions, for example:

https://github.com/gojimmypi/wolfssl/tree/ED25519_SHA2_fix/IDE/Espressif/ESP-IDF/examples/template/VisualGDB

 

 

• This reply was modified 9 months, 1 week ago by gojimmypi.

[gojimmypi]

Hello,

I recently installed the 20231123 ESP32 Debug Methods update to VisualGDB.

The JTAG programming and debugging capabilities (ESP-IDF v5.1) seem to be working well for the ESP32-H2 now! Thank you.

There is however an oddity when pressing the “Debug – Test” button, indicating that the test failed:

Error: Error on socket 'GDB': WSAGetLastError==10054, message: An existing connection was forcibly closed by the remote host.

I’ve attached the full log for reference. So far, it seems the error can be ignored.

Also, note that unlike other devices when doing idf.py erase-flash , the ESP32-H2 is not in a happy state when freshly erased. Error “invalid header” scrolling endlessly. In this state I am unable to JTAG debug.

Here’s an example of the console output after erase & JTAG will not work:

invalid header: 0xffffffff
invalid header: 0xfffff▒ESP-ROM:esp32h2-20221101
Build:Nov 1 2022
rst:0x7 (TG0_WDT_HPSYS),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x40011bdc
invalid header: 0xffffffff
invalid header: 0xffffffff

Upon flashing a clean, operational “hello world” (or any other app) – then the JTAG capabilities work fine.

Thank you again for this fix.

Cheers

Attachments:

You must be logged in to view attached files.

[gojimmypi]

There’s a recording of the “Getting Started with wolfSSL on the Espressif ESP32” here:

https://www.youtube.com/watch?v=CzwA3ZBZBZ8

[gojimmypi]

awesome, thank you 🙂

[gojimmypi]

ESP-IDF 5.1 has been released: https://github.com/espressif/esp-idf/releases/tag/v5.1

[gojimmypi]

I’ve setup wolfSSL as a managed component.

I’m hoping to use other components such as the esp-cryptoauthlib.

Components are added to a project like this:

idf.py add-dependency "espressif/esp-cryptoauthlib^3.5.1~1"

It appears the only thing that command does is to add/update the project idf_component.yml file.

Subsequent calls with idf.py build appear to recognize that component file, download required files to the managed_components directory, and compile everything.

However, from within the VisualGDB environment, nothing new seems to happen at compile time: The IDE does not seem to recognize the ESP Registry components in the managed_components directory.

I wasn’t able to find any VisualGDB documentation on this. It this capability supported? I’m using EDP-IDF v5.

Thank you

 

[gojimmypi]

Heads up for anyone else looking to manually enabled ESP32-C6 support before officially supported:

In addition to copy/paste (mentioned above) of a  ESP32C3 section in [SysGCC]\esp32\esp32-bsp\BSP.xml

Need to also edit C:\SysGCC\esp32\toolchain.xml

The esp-2022r1-11.2.0\riscv32-esp-elf\bin does not support the RISC-V zifencei extension, resulting in an error like:

Running CMake: C:\Users\gojimmypi\AppData\Local\VisualGDB\CMake\bin\cmake.exe ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_MAKE_PROGRAM=C:/SysGCC/esp32/tools/ninja/1.10.2/ninja.exe -DESP_PLATFORM=1 -DCCACHE_ENABLE=0 -DIDF_TARGET=esp32c6
-- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.39.1.windows.1")
-- Component directory C:/SysGCC/esp32/esp-idf/master/components/tinyusb does not contain a CMakeLists.txt file. No component will be added
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/SysGCC/esp32/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-gcc.exe
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/SysGCC/esp32/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-gcc.exe
-- Check for working C compiler: C:/SysGCC/esp32/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-gcc.exe - broken
-- Configuring incomplete, errors occurred!
CMake Error at C:/Users/gojimmypi/AppData/Local/VisualGDB/CMake/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
The C compiler

"C:/SysGCC/esp32/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-gcc.exe"

is not able to compile a simple test program.

It fails with the following output:

Change Dir: C:/workspace/wolfssl-gojimmypi/IDE/Espressif/ESP-IDF/examples/wolfssl_test/build/VisualGDB/Debug/CMakeFiles/CMakeTmp

Run Build Command(s):C:/SysGCC/esp32/tools/ninja/1.10.2/ninja.exe cmTC_30b2a && [1/2] Building C object CMakeFiles/cmTC_30b2a.dir/testCCompiler.c.obj
FAILED: CMakeFiles/cmTC_30b2a.dir/testCCompiler.c.obj
C:\SysGCC\esp32\tools\riscv32-esp-elf\esp-2022r1-11.2.0\riscv32-esp-elf\bin\riscv32-esp-elf-gcc.exe -march=rv32imc_zicsr_zifencei -o CMakeFiles/cmTC_30b2a.dir/testCCompiler.c.obj -c testCCompiler.c
Assembler messages:
Fatal error: -march=rv32imc_zicsr_zifencei: Invalid or unknown z ISA extension: 'zifencei'
ninja: build stopped: subcommand failed.

To fix this, I copied the esp-12.2.0_20230208toolchain from the Espressif-installed (latest master branch) toolchain:

C:\Users\gojimmypi\.espressif\tools\riscv32-esp-elf\esp-12.2.0_20230208

to:

C:\SysGCC\esp32\tools\riscv32-esp-elf\esp-12.2.0_20230208

and changed the C:\SysGCC\esp32\toolchain.xmlsetting:

tools\riscv32-esp-elf\esp-12.2.0_20230208\riscv32-esp-elf\bin

(the old toolchain value was esp-2022r1-11.2.0)

I also copied the ESP32c3.xml to ESP32C6.xml in

C:\SysGCC\esp32\esp32-bsp\peripherals

and edited the ESP32C6 contents.

The GDB executable file was missing, so added

riscv32-esp-elf-gdb.exe
riscv32-esp-elf-gdb-add-index

from

C:\SysGCC\esp32\tools\riscv32-esp-elf\esp-2022r1-11.2.0\riscv32-esp-elf\bin

I copied the esp32c3.cfg to esp32c6.cfg in this directory:

C:\Users\gojimmypi\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.esp32.core\share\openocd\scripts\target

and edited all of the “C3” to “C6” values in the new esp32c6.cfg file.

I’m very close to having JTAG working, with this Error: Unknown target type esp32c6

C:\Users\gojimmypi\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.esp32.core\bin\openocd.exe -c "gdb_port 59108" -c "telnet_port 59106" -f interface/esp_usb_jtag_c6.cfg -c "adapter_khz 40000" -f target/esp32c6.cfg -c "echo VisualGDB_OpenOCD_Ready"
Open On-Chip Debugger 0.10.0 (2022-05-03)
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
Info : esp_usb_jtag: VID set to 0x303a and PID to 0x1001
Info : esp_usb_jtag: capabilities descriptor set to 0x2000
adapter speed: 40000 kHz

DEPRECATED! use 'adapter speed' not 'adapter_khz'
adapter speed: 40000 kHz

Warn : Transport "jtag" was already selected
target/esp32c6.cfg:96: Error: Unknown target type esp32c6, try one of arm7tdmi, arm9tdmi, arm920t, arm720t, arm966e, arm946e, arm926ejs, fa526, feroceon, dragonite, xscale, cortex_m, cortex_a, cortex_r4, arm11, ls1_sap, mips_m4k, avr, dsp563xx, dsp5680xx, testee, avr32_ap7k, hla_target, nds32_v2, nds32_v3, nds32_v3m, esp32, esp32s2, esp32s3, esp32c3, or1k, quark_x10xx, quark_d20xx, stm8, riscv, mem_ap, esirisc, arcv2, aarch64, or mips_mips64
in procedure 'script'
at file "embedded:startup.tcl", line 26
at file "target/esp32c6.cfg", line 96

Line 96 is the “else” here:

if { $_RTOS == "none" } {
target create $_TARGETNAME esp32c6 -chain-position $_TAPNAME
} else {
target create $_TARGETNAME esp32c6 -chain-position $_TAPNAME -rtos $_RTOS
}

So I’m able to compile and program via COM port in Visual Studio, but I don’t yet have GDB/JTAG working.

Any tips on resolving the Error: Unknown target type esp32c6 at target create $_TARGETNAME esp32c6?

My ESP32-C6 vgdbproj project file is here.

• This reply was modified 1 year, 8 months ago by gojimmypi.
• This reply was modified 1 year, 8 months ago by gojimmypi.
• This reply was modified 1 year, 8 months ago by gojimmypi.

[gojimmypi]

Hi,

Thanks for the reply. Yes, the ESP32-C6 is pretty cool. I got myESP32-C6-DevKitC-1-N8 Development Board off Amazon for just $9, although it now says “unavailable”:  https://www.amazon.com/dp/B0BRMSDR4R

Looks like Adafruit has some in stock:  https://www.adafruit.com/product/5672

Thanks for the tips on the BSP file, I’ll give that a try. Things are working great from commandline. I have all the wolfSSL encryption tests passing. See https://github.com/wolfSSL/wolfssl/issues/6163

There was a little bit of wonkiness on my V0.0 board with the [hold boot, tap reset, release boot] to actually program.

Note in particular there’s a --preview option:
idf.py -p /dev/ttyS8 --preview set-target esp32c6 build flash

I’ve attached a couple of pics from the insert that came with my board. See also: https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/api-guides/jtag-debugging/tips-and-quirks.html

 

• This reply was modified 1 year, 8 months ago by gojimmypi.

Attachments:

You must be logged in to view attached files.

[gojimmypi]

Things only went sideways for me after I installed the update noted in #33523  – although I probably installed it before the edited comment about needing VisualGDB-5.6.109.4769.msi

My step-by-step was documented in #33578 and admittedly I am using the VisualGDB Espressif toolchains for Visual Studio *also* from DOS/Linux(WSL) command prompts. I understand that the non-Visual Studio use is outside the scope of support for VisualGDB, but this is tremendously helpful to test and validate ESP-IDF projects that are shared with non-VisualGDB users.

In the end, the uninstall and reinstall was although successful, not actually needed nor the root cause of the command-line IDF build problems in DOS/WSL as noted in the GitHub issue referred to in #33589.

I really did try to install the IDF v5 toolchain fresh. I didn’t merge toolchains, and have no idea how it was that they went missing. I did have a SysGCC directory backup from a couple of months ago.

I also did not know that the Visual GDB extension is supposed to be uninstalled via Windows “Add/Remove Programs”. Typically I have used the Visual Studio Extension manager for Visual Studio Extensions. Noted for future reference.

I didn’t get a chance to update things here: I do have everything working again, although only for the 4.x toolchains; I’ve not yet tried to update to ESP-IDF v5. I think I’ll do that on a VM or other computer.

The only reason I sent the message offline was to give you a heads up that a couple more releases (unfortunately all called “5.0”) were since released and may fix things for others:

https://github.com/espressif/idf-installer/releases/tag/offline-5.0

Thanks again for your assistance.

[gojimmypi]

Hey  @PaulMartinsen and others interested in the ESP-IDF v5: there was a new offline IDF release overnight. Unfortunately still called “5.0”

Release Release offline-5.0 · espressif/idf-installer (github.com)

I’m not sure if this is referenced directly by the VisualGDB toolchain install, or if a copy is used.

Also: see this link regarding <a class=”Link–secondary markdown-title” title=”Tools: bugfix wrong format of idf-env.json, KeyError: ‘idfSelectedId’

Closes https://github.com/espressif/esp-idf/issues/9837&#8243; href=”https://github.com/espressif/esp-idf/commit/77569c24b98401083f936599e4c94950867a2e22&#8243; data-pjax=”true”>KeyError: ‘idfSelectedId’  if anyone other than me also uses the VisualGDB toolchains to test from DOS/Linux(WSL)

https://github.com/espressif/esp-idf/issues/9837#issuecomment-1362618035

 

[gojimmypi]

Resolution: run admin command prompt to create a placeholder license.rtf file in the directory noted in dialog box: just a single space, non-blank file.

(in my case: C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\ENTERPRISE\COMMON7\IDE\EXTENSIONS\SYSPROGS\VISUALGDB\license.rtf)

Disabled VsualGDB extension and then ran Visual Studio extension remover. It didn’t actually remove the extension upon completion; I ended up also running Windows “Add or Remove a Program” to remove the new VisualGDB so that I could install the older version.

Note that one of the problems caused by the ESP-IDF v5 install was apparently seen in prior versions. The solution that helped me here was to remove the WSL ~/.espressif folder installed by the ESP-IDF v5 install.sh.

I realize it is not a Sysprogs supported feature at this time, but it is incredibly handy to test a VisualGDB project also in DOS and Linux/WSL ESP-IDF command prompt all on one machine, all with the exact same toolchain and ESP-IDF library.

[gojimmypi]

I did find a solution for this:

Deleted the ~/.espressif folder and re-ran the ./install.sh in /mnt/c/SysGCC/esp32/esp-idf/v4.4.2

I don’t yet have this working for the ESP-IDF v5, but at least my old toolchains for VisualGDB from a command prompt are working again.

[gojimmypi]

I’m revisiting this today. The ESP-IDF v5 is still not working properly for me.  I installed v5 the Visual Studio and tried to load cmake & build. Saw this error:

Running CMake: C:\Users\gojimmypi\AppData\Local\VisualGDB\CMake\bin\cmake.exe ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_MAKE_PROGRAM=c:/sysgcc/esp32/tools/ninja/1.10.2/ninja.exe -DESP_PLATFORM=1 -DCCACHE_ENABLE=0
-- Building ESP-IDF components for target esp32
-- Checking Python dependencies...
Python requirements are satisfied.
Constraint file: C:\Users\gojimmypi\.espressif\espidf.constraints.v5.0.txt
Requirement files:
- C:\SysGCC\esp32\esp-idf\v5.0\tools\requirements\requirements.core.txt
Python being checked: C:\Users\gojimmypi\.espressif\python_env\idf5.0_py3.8_env\Scripts\python.exe
CMake Error at C:/SysGCC/esp32/esp-idf/v5.0/tools/cmake/build.cmake:519 (message):
C:\SysGCC\esp32\esp-idf\v5.0\python-env\Scripts\python.exe: Error while
finding module specification for 'idf_component_manager.prepare_components'
(ModuleNotFoundError: No module named 'idf_component_manager')

Call Stack (most recent call first):
C:/SysGCC/esp32/esp-idf/v5.0/tools/cmake/project.cmake:440 (idf_build_process)
CMakeLists.txt:12 (project)

So I tried from commandline in WSL:

0 $ . /mnt/c/SysGCC/esp32/esp-idf/v5.0/export.sh
Resetting IDF_PATH from '/mnt/c/SysGCC/esp32/esp-idf/v4.4.2' to '/mnt/c/SysGCC/esp32/esp-idf/v5.0'
Detecting the Python interpreter
Checking "python3" ...
Python 3.8.10
"python3" has been detected
Checking Python compatibility
Checking other ESP-IDF version.
WARNING: No IDF variables to remove from environment found. Deactivation of previous esp-idf version was not successful.
Adding ESP-IDF tools to PATH...
ERROR: tool xtensa-esp-elf-gdb has no installed versions. Please run '/mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh' to install it.
ERROR: tool riscv32-esp-elf-gdb has no installed versions. Please run '/mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh' to install it.
ERROR: tool xtensa-esp32-elf has no installed versions. Please run '/mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh' to install it.
An unsupported version of tool xtensa-esp32-elf was found in PATH: esp-2021r2-patch3-8.4.0.
ERROR: tool xtensa-esp32s2-elf has no installed versions. Please run '/mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh' to install it.
An unsupported version of tool xtensa-esp32s2-elf was found in PATH: esp-2021r2-patch3-8.4.0.
ERROR: tool xtensa-esp32s3-elf has no installed versions. Please run '/mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh' to install it.
An unsupported version of tool xtensa-esp32s3-elf was found in PATH: esp-2021r2-patch3-8.4.0.
ERROR: tool riscv32-esp-elf has no installed versions. Please run '/mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh' to install it.
An unsupported version of tool riscv32-esp-elf was found in PATH: esp-2021r2-patch3-8.4.0.
ERROR: tool esp32ulp-elf has no installed versions. Please run '/mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh' to install it.
An unsupported version of tool esp32ulp-elf was found in PATH: 2.28.51.
Using a supported version of tool cmake found in PATH: 3.16.3.
However the recommended version is 3.24.0.
ERROR: tool openocd-esp32 has no installed versions. Please run '/mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh' to install it.
An unsupported version of tool openocd-esp32 was found in PATH: v0.11.0-esp32-20220411.
ERROR: tool esp-rom-elfs has no installed versions. Please run '/mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh' to install it.

So ok, I close that session and started a new WSL and tried to run /mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh

I saw this error:

0 $ /mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh
Detecting the Python interpreter
Checking "python3" ...
Python 3.8.10
"python3" has been detected
Checking Python compatibility
Installing ESP-IDF tools
Current system platform: linux-amd64
Selected targets are: esp32s2, esp32c3, esp32c2, esp32, esp32s3, esp32h2
Installing tools: xtensa-esp-elf-gdb, riscv32-esp-elf-gdb, xtensa-esp32-elf, xtensa-esp32s2-elf, xtensa-esp32s3-elf, riscv32-esp-elf, esp32ulp-elf, openocd-esp32, esp-rom-elfs
Skipping xtensa-esp-elf-gdb@11.2_20220823 (already installed)
Skipping riscv32-esp-elf-gdb@11.2_20220823 (already installed)
Skipping xtensa-esp32-elf@esp-2022r1-11.2.0 (already installed)
Skipping xtensa-esp32s2-elf@esp-2022r1-11.2.0 (already installed)
Skipping xtensa-esp32s3-elf@esp-2022r1-11.2.0 (already installed)
Skipping riscv32-esp-elf@esp-2022r1-11.2.0 (already installed)
Skipping esp32ulp-elf@2.35_20220830 (already installed)
Skipping openocd-esp32@v0.11.0-esp32-20221026 (already installed)
Skipping esp-rom-elfs@20220823 (already installed)
Installing Python environment and packages
Creating a new Python environment in /home/gojimmypi/.espressif/python_env/idf5.0_py3.8_env
The virtual environment was not created successfully because ensurepip is not
available. On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

apt install python3.8-venv

You may need to use sudo with that command. After installing the python3-venv
package, recreate your virtual environment.

Failing command: ['/home/gojimmypi/.espressif/python_env/idf5.0_py3.8_env/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']

Traceback (most recent call last):
File "/mnt/c/SysGCC/esp32/esp-idf/v5.0/tools/idf_tools.py", line 2610, in <module>
main(sys.argv[1:])
File "/mnt/c/SysGCC/esp32/esp-idf/v5.0/tools/idf_tools.py", line 2602, in main
action_func(args)
File "/mnt/c/SysGCC/esp32/esp-idf/v5.0/tools/idf_tools.py", line 2022, in action_install_python_env
subprocess.check_call([sys.executable, '-m', 'venv',
File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m', 'venv', '--clear', '/home/gojimmypi/.espressif/python_env/idf5.0_py3.8_env']' returned non-zero exit status 1.

so ok, I ran apt install python3.8-venv

0 $ sudo apt-get install python3.8-venv
[sudo] password for gojimmypi:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
gstreamer1.0-plugins-base libc-ares2 libcdparanoia0 libgstreamer-plugins-base1.0-0 liblua5.2-0 libopus0 liborc-0.4-0
libqt5multimedia5 libqt5multimedia5-plugins libqt5multimediagsttools5 libqt5multimediawidgets5 libsbc1 libsmi2ldbl libsnappy1v5
libspandsp2 libspeexdsp1 libssh-gcrypt-4 libtheora0 libvisual-0.4-0 libwireshark-data libwireshark13 libwiretap10 libwsutil11
wireshark-common wireshark-qt
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
libpython3.8 libpython3.8-dev libpython3.8-minimal libpython3.8-stdlib python3.8 python3.8-dev python3.8-minimal
Suggested packages:
python3.8-doc
The following NEW packages will be installed:
python3.8-venv
The following packages will be upgraded:
libpython3.8 libpython3.8-dev libpython3.8-minimal libpython3.8-stdlib python3.8 python3.8-dev python3.8-minimal
7 upgraded, 1 newly installed, 0 to remove and 123 not upgraded.
Need to get 10.8 MB of archives.
After this operation, 37.9 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Ign:1 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 python3.8-dev amd64 3.8.10-0ubuntu1~20.04.5
Ign:2 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 python3.8 amd64 3.8.10-0ubuntu1~20.04.5
Ign:3 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 libpython3.8-dev amd64 3.8.10-0ubuntu1~20.04.5
Ign:4 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 libpython3.8 amd64 3.8.10-0ubuntu1~20.04.5
Ign:5 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 libpython3.8-stdlib amd64 3.8.10-0ubuntu1~20.04.5
Ign:6 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 python3.8-minimal amd64 3.8.10-0ubuntu1~20.04.5
Ign:7 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 libpython3.8-minimal amd64 3.8.10-0ubuntu1~20.04.5
Ign:8 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 python3.8-venv amd64 3.8.10-0ubuntu1~20.04.5
Err:1 http://security.ubuntu.com/ubuntu focal-updates/main amd64 python3.8-dev amd64 3.8.10-0ubuntu1~20.04.5
404 Not Found [IP: 91.189.91.38 80]
Err:2 http://security.ubuntu.com/ubuntu focal-updates/main amd64 python3.8 amd64 3.8.10-0ubuntu1~20.04.5
404 Not Found [IP: 91.189.91.38 80]
Err:3 http://security.ubuntu.com/ubuntu focal-updates/main amd64 libpython3.8-dev amd64 3.8.10-0ubuntu1~20.04.5
404 Not Found [IP: 91.189.91.38 80]
Err:4 http://security.ubuntu.com/ubuntu focal-updates/main amd64 libpython3.8 amd64 3.8.10-0ubuntu1~20.04.5
404 Not Found [IP: 91.189.91.38 80]
Err:5 http://security.ubuntu.com/ubuntu focal-updates/main amd64 libpython3.8-stdlib amd64 3.8.10-0ubuntu1~20.04.5
404 Not Found [IP: 91.189.91.38 80]
Err:6 http://security.ubuntu.com/ubuntu focal-updates/main amd64 python3.8-minimal amd64 3.8.10-0ubuntu1~20.04.5
404 Not Found [IP: 91.189.91.38 80]
Err:7 http://security.ubuntu.com/ubuntu focal-updates/main amd64 libpython3.8-minimal amd64 3.8.10-0ubuntu1~20.04.5
404 Not Found [IP: 91.189.91.38 80]
Err:8 http://security.ubuntu.com/ubuntu focal-updates/universe amd64 python3.8-venv amd64 3.8.10-0ubuntu1~20.04.5
404 Not Found [IP: 91.189.91.38 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python3.8/python3.8-dev_3.8.10-0ubuntu1~20.04.5_amd64.deb 404 Not Found [IP: 91.189.91.38 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python3.8/python3.8_3.8.10-0ubuntu1~20.04.5_amd64.deb 404 Not Found [IP: 91.189.91.38 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python3.8/libpython3.8-dev_3.8.10-0ubuntu1~20.04.5_amd64.deb 404 Not Found [IP: 91.189.91.38 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python3.8/libpython3.8_3.8.10-0ubuntu1~20.04.5_amd64.deb 404 Not Found [IP: 91.189.91.38 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python3.8/libpython3.8-stdlib_3.8.10-0ubuntu1~20.04.5_amd64.deb 404 Not Found [IP: 91.189.91.38 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python3.8/python3.8-minimal_3.8.10-0ubuntu1~20.04.5_amd64.deb 404 Not Found [IP: 91.189.91.38 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python3.8/libpython3.8-minimal_3.8.10-0ubuntu1~20.04.5_amd64.deb 404 Not Found [IP: 91.189.91.38 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/universe/p/python3.8/python3.8-venv_3.8.10-0ubuntu1~20.04.5_amd64.deb 404 Not Found [IP: 91.189.91.38 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Ran apt-get update && apt-get upgrade, and tried again to run /mnt/c/SysGCC/esp32/esp-idf/v5.0/install.sh

It seemed to be successful, so I tried to build:

-- Building ESP-IDF components for target esp32
CMake Error at /mnt/c/SysGCC/esp32/esp-idf/v5.0/tools/cmake/build.cmake:519 (message):
usage: __main__.py [-h] [--project_dir PROJECT_DIR]

[--interface_version {0,1}]
{prepare_dependencies,inject_requirements,inject_requrements}
...

__main__.py: error: argument --interface_version: invalid int value: ''

Call Stack (most recent call first):
/mnt/c/SysGCC/esp32/esp-idf/v4.4.2/tools/cmake/project.cmake:384 (idf_build_process)
CMakeLists.txt:59 (project)

-- Configuring incomplete, errors occurred!

After all this, I tried to load a know-working project in v4.4.2 and simply change to v5. I see this error in Visual Studio:

ESP-IDF path changed from C:\SysGCC\esp32\esp-idf\v4.4.2 to C:\SysGCC\esp32\esp-idf\v5.0. Deleting C:\workspace\wolfssl-bandi13\IDE\Espressif\ESP-IDF\examples\wolfssl_benchmark\build\VisualGDB\Debug...
Running CMake: C:\Users\gojimmypi\AppData\Local\VisualGDB\CMake\bin\cmake.exe ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_MAKE_PROGRAM=c:/sysgcc/esp32/tools/ninja/1.10.2/ninja.exe -DESP_PLATFORM=1 -DCCACHE_ENABLE=0 -DIDF_TARGET=esp32
-- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.38.1.windows.1")
-- The C compiler identification is GNU 8.4.0
-- The CXX compiler identification is GNU 8.4.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/SysGCC/esp32/tools/xtensa-esp32-elf/esp-2021r2-patch3/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/SysGCC/esp32/tools/xtensa-esp32-elf/esp-2021r2-patch3/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/SysGCC/esp32/tools/xtensa-esp32-elf/esp-2021r2-patch3/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building ESP-IDF components for target esp32
-- Checking Python dependencies...
Python requirements are satisfied.
Constraint file: C:\Users\gojimmypi\.espressif\espidf.constraints.v5.0.txt
Requirement files:
- C:\SysGCC\esp32\esp-idf\v5.0\tools\requirements\requirements.core.txt
Python being checked: C:\Users\gojimmypi\.espressif\python_env\idf5.0_py3.8_env\Scripts\python.exe
-- Configuring incomplete, errors occurred!
CMake Error at C:/SysGCC/esp32/esp-idf/v5.0/tools/cmake/build.cmake:519 (message):
C:\SysGCC\esp32\esp-idf\v5.0\python-env\Scripts\python.exe: Error while
finding module specification for 'idf_component_manager.prepare_components'
(ModuleNotFoundError: No module named 'idf_component_manager')

Call Stack (most recent call first):
C:/SysGCC/esp32/esp-idf/v5.0/tools/cmake/project.cmake:440 (idf_build_process)
CMakeLists.txt:12 (project)

See also "C:/workspace/wolfssl-bandi13/IDE/Espressif/ESP-IDF/examples/wolfssl_benchmark/build/VisualGDB/Debug/CMakeFiles/CMakeOutput.log".

System.Exception: CMake exited with code 1
at e43.l(n b, Object a)

========== Project Configuration Summary ==========
VisualGDB_wolfssl_benchmark configured in 00:08
========== Configuration: 1 Succeeded, 0 Failed, 0 Skipped ==========

 

I’ve otherwise had great success with prior versions of the ESP-IDF in VisualGDB.

I’m using Visual Studio 2019 16.11.21 and VisualGDB 5.6R9 (build 4769)

Please advise the exact steps that are needed to properly install Espressif ESP-IDF v5 support. Thank you.

Attachments:

You must be logged in to view attached files.

[Author]

Posts