- This topic has 14 replies, 2 voices, and was last updated 5 years, 6 months ago by
.
-
Posts
-
I have installed the 5.4 preview 5 of VisualGDB into Visual Studio 2017. Thank you for an excellent environment for developing and testing ESP32 projects. All ESP32 developers should be using VisualGDB. I can very easily build and JTAG debug ESP32 projects based on IDF Makefiles. No hassle. Just works.
Given there is already support in VisualGDB for CMake, it should be straight forward to be able to build ESP32 projects that already use CMake. However, the Import Wizard for VisualGDB only expects IDF style Makefiles.
Specifically, I would like to build nanoFramework project for ESP32 devices. The nanoFramework also targets various STM32 CPUs and other embedded systems can be added. If there was an easy option to use VisualGDB, then I am sure you would persuade additional developers to buy VisualGDB as it is so much more productive that VSCode (which has no memory or disassembly)
The main GitHub is found here: https://github.com/nanoframework/nf-interpreter
My fork has a VS2017 branch that builds using regular CMake support in VS2017.
See https://github.com/doingnz/nf-interpreter/tree/vs2017.In the short term, can you suggest how I should proceed to easily setup a project system to build nanoFramework and debug with VisualGDB (JTAG) targeting ESP32 CPU?
Espressif are also moving away from Makefiles to CMake (https://docs.espressif.com/projects/esp-idf/en/latest/get-started-cmake/index.html) adding to the push towards supporting CMake for ESp32 in VisualGDB.
All help appreciated.
Hi,
We are indeed working on fully supporting CMake-based ESP-IDF projects, however this support is not 100% feature-complete yet. Please feel free to try the following VisualGDB and toolchain builds:
- http://sysprogs.com/files/tmp/VisualGDB-5.4.5.2446.msi
- http://sysprogs.com/files/gnutoolchains/esp32/esp32-gcc5.2.0-r13.exe
Simply select CMake in the ESP-IDF project wizard (ensure you are using the new toolchain) and VisualGDB will create a CMake-based ESP-IDF project. You should be able to build it, debug it and use IntelliSense out-of-the-box, however the Solution Explorer will show the raw CMake targets (that are somewhat confusing with ESP-IDF) rather than meaningful app/bootloader/components and also adding new sources or changing target properties would result in potentially breaking edits of ESP-IDF build scripts (VisualGDB is not yet aware of the ESP-IDF-specific semantics for controlling target properties and will instead use the generic CMake semantics).
Feel free to try the builds above and feel free to post any feedback here.
thank you for the prompt support. 🙂
I can install the updated VisualGDB easily.
I struggled to install the gnutoolchain r13. Install stopped with Access Denied error. I was able to complete the install by renaming the existing SysGCC to SysGCCr12 before running the installer.
I will now try a CMake build….
I am getting an unexpected error after it first load the new project. I used the wizard to generate a CMake “hello World’ sample.
C:\Projects\esp\EmbeddedProject2\EmbeddedProject2\EmbeddedProject2.vgdbproj: active configuration changed to Debug
System.ComponentModel.Win32Exception (0x80004005): Access is denied
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start()
at o91.d_2()
at d21.u()
at yd1.m2(Boolean b, Boolean a)
-- Building empty aws_iot component due to configurationThe sample did successfully Build->Build Solution…
Initially I could not find the hello_world_main.c in solution explorer (see screen shot), but could manually using File menu to navigate to the file on disk. I could then set a break point and single step the compiled sample on a WROVER via JTAG. Nice!
Please see the attached screen shot .. the folders displayed in Solution Explorer are a little confused with several levels of ‘..’ folders. On expanding the heiracy, I could also find the missing hello_world_main.c file.
I have now tried to build the nanoFramework project. As there is no CMake project import in the current build of VisualGDB, I first created a dummy hello_world project. I then copied the folders with the nanoFramework source files and the root CMakeLists.txt into the newly minted hello-world project folder.
The nanoFramework CMakeLists.txt expects several variables to be defined. In Visual Studio Code this is achieved auto-magically with a cmake-variants.json file the cmake extension imports. To provide the same settings within VisualGDB cmake build environment, I created a file called settings.cmake with a list of cmake set(…) commands and added include(cmake.settings) at the top of the original CMakeLists.txt
e.g. start of file looked like
set(TARGET_SERIES "ESP32")
set(USE_FPU "TRUE")
set(RTOS "FREERTOS")
set(SWO_OUTPUT "OFF")
set(NF_BUILD_RTM "OFF")
...I could build most of nanoFramework without error. However, please can you have a look at the support for the VERSION definitions within a cmake project definition. Please see CMake document here
e.g. add the following lines to any sample project. e.g. the regular hello-world sample.
set(BUILD_VERSION "0.9.99.999")
project(hello-world VERSION ${BUILD_VERSION})
message(STATUS "Building hello_world version ${PROJECT_VERSION}.")
configure_file("target_os.h.in" "target_os.h" @ONLY)define a
target_os.h.infile with lines as follows#define VERSION_MAJOR @PROJECT_VERSION_MAJOR@U
#define VERSION_MINOR @PROJECT_VERSION_MINOR@U
#define VERSION_BUILD @PROJECT_VERSION_PATCH@U
#define VERSION_REVISION @PROJECT_VERSION_TWEAK@Uor in place of PROJECT, it should be ok to use the project name. e.g.
#define VERSION_MAJOR @hello_world_VERSION_MAJOR@Uthe generated file ends up with
#define VERSION_MAJOR U
#define VERSION_MINOR U
#define VERSION_BUILD U
#define VERSION_REVISION Uwhen we expect it to have
#define VERSION_MAJOR 0
#define VERSION_MINOR 9
#define VERSION_BUILD 99
#define VERSION_REVISION 999the CMakeLists.txt output is also missing the PROJECT_VERSION info from the line
message(STATUS "Building hello_world version ${PROJECT_VERSION}.")Ideas?
Thanks for making a great product! very nearly there for cmake support for ESP32.
I can for now fake the version by changing the definition in the .in file and replace the default U with something that lets it compile. Next thing I need to overcome is linking the as built IDF. The nanoFramework by default expects to use a pre-built library.
How do you expect to handle per project settings for VisualGDB and CMake going forward?
VS2017 uses a file called CMakeSettings.json
VSCode uses a file called cmake-variants.json
regular CMake does not appear to have a concept of project settings, but a cache can be initialized with -C <settings> command line parameter
I have suggested a per project file called settings.cmake and then a project uses include(settings.cmake) at the top of the CMakeLists.txt. The format of the settings.cmake is just regular CMake statements. This approach should work for any build environment and be platform independent. The VisualGDB CMake import could look for the files used by VS2017 and VSCode and import them to settings.cmake.
I am asking so that I can start moving towards the approach VisualGDB will ulitmately use for CMamke based ESP32 projects going forward. Ideally would work for all Embedded CMake build targets as projects like nanoFramework can target multiple embedded CPUs and a uniform approach to configuring a build would be nice. I can imagine settings-esp32.cmake, settings-stm32.cmake etc…. Anyway I am interested in your thoughts as I am a newbie to cmake and visualgdb.
Hi,
Sorry for the delay. First of all, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.5.2448.msi. We will considerably improve the usability of the CMake-based ESP-IDF projects – the Solution Explorer will now show more meaningful component structure, the VisualGDB Project Properties will let you edit the KConfig variables and manage checkouts, and the context menu commands for opening terminal and programming FLASH memory will work just like for the regular non-CMake projects.
Please still refrain from adding/removing/renaming sources via Solution Explorer as this logic does not yet support ESP IDF-specific semantics.
Also if you are encountering many “Access Denied” errors, your antivirus might be blocking some of the tools checked by VisualGDB. Please double-check your antivirus logs.
The regular CMake indeed doesn’t provide any special files for storing options. You can pass the options via the CMake command line using the -DNAME=VALUE syntax. VisualGDB stores the command-line arguments it will pass to CMake in the .vgdbsettings files and provides convenient GUI for editing them (right-click on the project in Solution Explorer -> VisualGDB Project Properties). To make it easier, we have added a new setting for specifying those variables directly: VisualGDB Project Properties -> CMake Project Settings -> Extra CMake Configuration Variables.
If you would like to find an IDE-invariant way of storing this settings, we would advise continuing your approach with defining them in a separate .cmake file via the set() commands. It’s hard to say why the ${PROJECT_VERSION} variable would not get handled properly, but dumping it via message() from several places inside the CMake files might help pinpoint the exact place where it gets overridden.
Let us know if you have any further questions and we will be happy to help.
Thank you for the updated VisualGDB. The folder layout is fixed.
I have confirmed the problem with ${PROJECT_VERSION} remains. You can reproduce it by creating a standard hello-world example with the new cmake VisualGDB. Then use the following CMakeLists.txt (i.e. use a version of project(…) that attempts to set PROJECT_VERSION.
# The following lines of boilerplate have to be in your project's
# CMakeLists in this exact order for cmake to work correctly
cmake_minimum_required(VERSION 3.5)include($ENV{IDF_PATH}/tools/cmake/project.cmake)
#project(hello-world)set(BUILD_VERSION "0.9.99.999")
message(STATUS "###############################")
project(hello-world VERSION ${BUILD_VERSION})
message(STATUS "Building hello_world version ${PROJECT_VERSION}.")
message(STATUS "###############################")
set(PROJECT_VERSION "0.9.99.999")
message(STATUS "Building hello_world version ${PROJECT_VERSION}.")The ##### help to mark the output range of interest. You can see from the above there are no statements in the CMakeLists.txt to set ${PROJECT_VERSION} between the two lines of ######### characters. message(…) is depending on the CMake system to set ${PROJECT_VERSION}. The output below shows there is no version information as PROJECT_VERSION has not been set. The subsequent set will define the PROJECT_VERSION and it will then be reported correctly in the output.
Is it possible a PROJECT_VERSION is being set in a Windows Environment that is discard as part of the process of VisualGDB launching CMake?
Reconfiguring project due to missing Makefile...
Found Git: C:/SysGCC/esp32/usr/bin/git.exe (found version "2.15.0")
###############################
-- Building empty aws_iot component due to configuration
Component names: main app_trace xtensa-debug-module app_update spi_flash bootloader_support mbedtls lwip vfs ethernet tcpip_adapter micro-ecc aws_iot jsmn bootloader bt nvs_flash coap console cxx driver esp-tls nghttp esp32 log pthread smartconfig_ack wpa_supplicant esp_adc_cal esp_http_client esp_https_ota esptool_py expat fatfs wear_levelling sdmmc freertos heap idf_test json libsodium mdns newlib openssl partition_table soc spiffs ulp
Component paths: C:/Projects/esp/EmbeddedProject4/EmbeddedProject4/main;C:/SysGCC/esp32/esp-idf/v3.1/components/app_trace;C:/SysGCC/esp32/esp-idf/v3.1/components/xtensa-debug-module;C:/SysGCC/esp32/esp-idf/v3.1/components/app_update;C:/SysGCC/esp32/esp-idf/v3.1/components/spi_flash;C:/SysGCC/esp32/esp-idf/v3.1/components/bootloader_support;C:/SysGCC/esp32/esp-idf/v3.1/components/mbedtls;C:/SysGCC/esp32/esp-idf/v3.1/components/lwip;C:/SysGCC/esp32/esp-idf/v3.1/components/vfs;C:/SysGCC/esp32/esp-idf/v3.1/components/ethernet;C:/SysGCC/esp32/esp-idf/v3.1/components/tcpip_adapter;C:/SysGCC/esp32/esp-idf/v3.1/components/micro-ecc;C:/SysGCC/esp32/esp-idf/v3.1/components/aws_iot;C:/SysGCC/esp32/esp-idf/v3.1/components/jsmn;C:/SysGCC/esp32/esp-idf/v3.1/components/bootloader;C:/SysGCC/esp32/esp-idf/v3.1/components/bt;C:/SysGCC/esp32/esp-idf/v3.1/components/nvs_flash;C:/SysGCC/esp32/esp-idf/v3.1/components/coap;C:/SysGCC/esp32/esp-idf/v3.1/components/console;C:/SysGCC/esp32/esp-idf/v3.1/components/cxx;C:/SysGCC/esp32/esp-idf/v3.1/components/driver;C:/SysGCC/esp32/esp-idf/v3.1/components/esp-tls;C:/SysGCC/esp32/esp-idf/v3.1/components/nghttp;C:/SysGCC/esp32/esp-idf/v3.1/components/esp32;C:/SysGCC/esp32/esp-idf/v3.1/components/log;C:/SysGCC/esp32/esp-idf/v3.1/components/pthread;C:/SysGCC/esp32/esp-idf/v3.1/components/smartconfig_ack;C:/SysGCC/esp32/esp-idf/v3.1/components/wpa_supplicant;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_adc_cal;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_http_client;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_https_ota;C:/SysGCC/esp32/esp-idf/v3.1/components/esptool_py;C:/SysGCC/esp32/esp-idf/v3.1/components/expat;C:/SysGCC/esp32/esp-idf/v3.1/components/fatfs;C:/SysGCC/esp32/esp-idf/v3.1/components/wear_levelling;C:/SysGCC/esp32/esp-idf/v3.1/components/sdmmc;C:/SysGCC/esp32/esp-idf/v3.1/components/freertos;C:/SysGCC/esp32/esp-idf/v3.1/components/heap;C:/SysGCC/esp32/esp-idf/v3.1/components/idf_test;C:/SysGCC/esp32/esp-idf/v3.1/components/json;C:/SysGCC/esp32/esp-idf/v3.1/components/libsodium;C:/SysGCC/esp32/esp-idf/v3.1/components/mdns;C:/SysGCC/esp32/esp-idf/v3.1/components/newlib;C:/SysGCC/esp32/esp-idf/v3.1/components/openssl;C:/SysGCC/esp32/esp-idf/v3.1/components/partition_table;C:/SysGCC/esp32/esp-idf/v3.1/components/soc;C:/SysGCC/esp32/esp-idf/v3.1/components/spiffs;C:/SysGCC/esp32/esp-idf/v3.1/components/ulp
The ASM compiler identification is GNU
Found assembler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
The C compiler identification is GNU 5.2.0
The CXX compiler identification is GNU 5.2.0
Check for working C compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
Check for working C compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Detecting C compile features
Detecting C compile features - done
Check for working CXX compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe
Check for working CXX compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
Building empty aws_iot component due to configuration
Adding linker script C:/Projects/esp/EmbeddedProject4/EmbeddedProject4/VisualGDB/Debug/esp32/esp32_out.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.common.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.peripherals.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.libgcc.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.spiram_incompatible_fns.ld
Component libraries: ;main;app_trace;xtensa-debug-module;app_update;spi_flash;bootloader_support;mbedtls;lwip;vfs;ethernet;tcpip_adapter;micro-ecc;aws_iot;jsmn;bt;nvs_flash;coap;console;cxx;driver;esp-tls;nghttp;esp32;log;pthread;smartconfig_ack;wpa_supplicant;esp_adc_cal;esp_http_client;esp_https_ota;expat;fatfs;wear_levelling;sdmmc;freertos;heap;idf_test;json;libsodium;mdns;newlib;openssl;soc;spiffs;ulp
Building hello_world version .
###############################
Building hello_world version 0.9.99.999.
Configuring doneHi,
Thanks, we have indeed managed to reproduce this, however it looks like a problem specific to ESP-IDF (regular VisualGDB Linux projects built with CMake work as expected).
Could you quickly recheck whether it reproduces in your setup when running the normal Windows CMake manually or via idf.py? If not, we should be able to analyze the differences on our side and ensure it works as well. If it doesn’t work outside VisualGDB either, it’s likely caused by some constructs inside ESP-IDF itself (e.g. multiple project() definitions) and we would advise either experimenting with internal ESP-IDF definitions, or simply defining PROJECT_VERSION explicitly.
Hi,
Just wanted to share an updated build: http://sysprogs.com/files/tmp/VisualGDB-5.4.5.2451.msi
It now properly supports adding/removing components and source files just like the regular ESP-IDF projects (i.e. it will update the correct ESP-IDF-specific statements, so you won’t need to worry about that). It is still missing support for target property editing, however it should be more convenient than the previous build if you are actively experimenting with the new ESP-IDF.
Thank you for the updated VisualGBD… I have installed it and will play.
Regarding the project(….) statement, it works correctly with regular CMake in VS2017 and building an ESP32 / IDF version of nanoFramework.
With the Build Version defined in the VS2017 recognised CMakeSettings.json as
"variables": [
{
"name": "BUILD_VERSION",
"value": "0.9.99.999"
},and the following in CMakeLists.txt
# set default version
if(NOT BUILD_VERSION)
set(BUILD_VERSION 0.0.0.0)
endif()
project(nanoFramework VERSION ${BUILD_VERSION})
<h6>#################
message(STATUS "######################################################################################")
message(STATUS "Building nanoFramework version ${PROJECT_VERSION} using build type '${CMAKE_BUILD_TYPE}'.")
message(STATUS "Source directory is '${PROJECT_SOURCE_DIR}'.")
message(STATUS "Build directory is '${PROJECT_BINARY_DIR}'.")
message(STATUS "Toolchain is '${TOOLCHAIN}'.")
message(STATUS "######################################################################################")
#######################</h6>
the output is the expected1> -- ######################################################################################
1> -- Building nanoFramework version 0.9.99.999 using build type 'Debug'.
1> -- Source directory is 'C:/Projects/esp/nf-interpreter'.
1> -- Build directory is 'C:/Projects/esp/nf-interpreter/build'.
1> -- Toolchain is 'GCC'.
1> -- ######################################################################################Hi,
Thanks for checking this. As another quick test, could you try using the same CMakeLists.txt and defining BUILD_VERSION via VisualGDB Project Properties -> CMake Build -> CMake Configuration Variables? Does it result in a different outcome?
the step on September 29, 2018 at 05:28 where BUILD_VERSION is set in CMakeSettings.json is not a VisualGDB project. It uses a regular VS2017 folder+ CMAKE project. Not sure how you want me to test? There are no VisualGDB settings? It is a folder project.
I made a hello-world sample. Modified the CMakeLists.txt to the following
# The following lines of boilerplate have to be in your project's
# CMakeLists in this exact order for cmake to work correctly
cmake_minimum_required(VERSION 3.5)include($ENV{IDF_PATH}/tools/cmake/project.cmake)set(BUILD_VERSION 0.9.99.999)
set(PROJECT_VERSION 1.2.3.4)# set default version
if(NOT BUILD_VERSION)
set(BUILD_VERSION 0.0.0.0)
endif()
message(STATUS "BUILD_VERSION=${BUILD_VERSION}")
message(STATUS "PROJECT_VERSION=${PROJECT_VERSION}")
message(STATUS "######################################################################################")
project(nanoFramework VERSION ${BUILD_VERSION})
message(STATUS "BUILD_VERSION=${BUILD_VERSION}")
message(STATUS "PROJECT_VERSION=${PROJECT_VERSION}")
message(STATUS "######################################################################################")
message(STATUS "Building nanoFramework version ${PROJECT_VERSION} using build type '${CMAKE_BUILD_TYPE}'.")
message(STATUS "Source directory is '${PROJECT_SOURCE_DIR}'.")
message(STATUS "Build directory is '${PROJECT_BINARY_DIR}'.")
message(STATUS "Toolchain is '${TOOLCHAIN}'.")
message(STATUS "######################################################################################")Then on clean and rebuild the initial output shows that both PROJECT_VERSION and BUILD_VERSION are set initially, but PROJECT_VERSION gets cleared when project(…) statement is executed. There is a lot that happens as a result of the project(….) statement between the “#####” just before and after the project(…) statement.
------ Rebuild All started: Project: nanoFramework, Configuration: Debug VisualGDB ------
Removing C:\Projects\esp\EmbeddedProject5\EmbeddedProject5/VisualGDB/Debug...
Reconfiguring project due to missing Makefile...
Found Git: C:/SysGCC/esp32/usr/bin/git.exe (found version "2.15.0")
BUILD_VERSION=0.9.99.999
PROJECT_VERSION=1.2.3.4
######################################################################################
-- Building empty aws_iot component due to configuration
Component names: main app_trace xtensa-debug-module app_update spi_flash bootloader_support mbedtls lwip vfs ethernet tcpip_adapter micro-ecc aws_iot jsmn bootloader bt nvs_flash coap console cxx driver esp-tls nghttp esp32 log pthread smartconfig_ack wpa_supplicant esp_adc_cal esp_http_client esp_https_ota esptool_py expat fatfs wear_levelling sdmmc freertos heap idf_test json libsodium mdns newlib openssl partition_table soc spiffs ulp
Component paths: C:/Projects/esp/EmbeddedProject5/EmbeddedProject5/main;C:/SysGCC/esp32/esp-idf/v3.1/components/app_trace;C:/SysGCC/esp32/esp-idf/v3.1/components/xtensa-debug-module;C:/SysGCC/esp32/esp-idf/v3.1/components/app_update;C:/SysGCC/esp32/esp-idf/v3.1/components/spi_flash;C:/SysGCC/esp32/esp-idf/v3.1/components/bootloader_support;C:/SysGCC/esp32/esp-idf/v3.1/components/mbedtls;C:/SysGCC/esp32/esp-idf/v3.1/components/lwip;C:/SysGCC/esp32/esp-idf/v3.1/components/vfs;C:/SysGCC/esp32/esp-idf/v3.1/components/ethernet;C:/SysGCC/esp32/esp-idf/v3.1/components/tcpip_adapter;C:/SysGCC/esp32/esp-idf/v3.1/components/micro-ecc;C:/SysGCC/esp32/esp-idf/v3.1/components/aws_iot;C:/SysGCC/esp32/esp-idf/v3.1/components/jsmn;C:/SysGCC/esp32/esp-idf/v3.1/components/bootloader;C:/SysGCC/esp32/esp-idf/v3.1/components/bt;C:/SysGCC/esp32/esp-idf/v3.1/components/nvs_flash;C:/SysGCC/esp32/esp-idf/v3.1/components/coap;C:/SysGCC/esp32/esp-idf/v3.1/components/console;C:/SysGCC/esp32/esp-idf/v3.1/components/cxx;C:/SysGCC/esp32/esp-idf/v3.1/components/driver;C:/SysGCC/esp32/esp-idf/v3.1/components/esp-tls;C:/SysGCC/esp32/esp-idf/v3.1/components/nghttp;C:/SysGCC/esp32/esp-idf/v3.1/components/esp32;C:/SysGCC/esp32/esp-idf/v3.1/components/log;C:/SysGCC/esp32/esp-idf/v3.1/components/pthread;C:/SysGCC/esp32/esp-idf/v3.1/components/smartconfig_ack;C:/SysGCC/esp32/esp-idf/v3.1/components/wpa_supplicant;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_adc_cal;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_http_client;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_https_ota;C:/SysGCC/esp32/esp-idf/v3.1/components/esptool_py;C:/SysGCC/esp32/esp-idf/v3.1/components/expat;C:/SysGCC/esp32/esp-idf/v3.1/components/fatfs;C:/SysGCC/esp32/esp-idf/v3.1/components/wear_levelling;C:/SysGCC/esp32/esp-idf/v3.1/components/sdmmc;C:/SysGCC/esp32/esp-idf/v3.1/components/freertos;C:/SysGCC/esp32/esp-idf/v3.1/components/heap;C:/SysGCC/esp32/esp-idf/v3.1/components/idf_test;C:/SysGCC/esp32/esp-idf/v3.1/components/json;C:/SysGCC/esp32/esp-idf/v3.1/components/libsodium;C:/SysGCC/esp32/esp-idf/v3.1/components/mdns;C:/SysGCC/esp32/esp-idf/v3.1/components/newlib;C:/SysGCC/esp32/esp-idf/v3.1/components/openssl;C:/SysGCC/esp32/esp-idf/v3.1/components/partition_table;C:/SysGCC/esp32/esp-idf/v3.1/components/soc;C:/SysGCC/esp32/esp-idf/v3.1/components/spiffs;C:/SysGCC/esp32/esp-idf/v3.1/components/ulp
The ASM compiler identification is GNU
Found assembler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
The C compiler identification is GNU 5.2.0
The CXX compiler identification is GNU 5.2.0
Check for working C compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
Check for working C compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Detecting C compile features
Detecting C compile features - done
Check for working CXX compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe
Check for working CXX compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
Building empty aws_iot component due to configuration
Adding linker script C:/Projects/esp/EmbeddedProject5/EmbeddedProject5/VisualGDB/Debug/esp32/esp32_out.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.common.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.peripherals.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.libgcc.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.spiram_incompatible_fns.ld
Component libraries: ;main;app_trace;xtensa-debug-module;app_update;spi_flash;bootloader_support;mbedtls;lwip;vfs;ethernet;tcpip_adapter;micro-ecc;aws_iot;jsmn;bt;nvs_flash;coap;console;cxx;driver;esp-tls;nghttp;esp32;log;pthread;smartconfig_ack;wpa_supplicant;esp_adc_cal;esp_http_client;esp_https_ota;expat;fatfs;wear_levelling;sdmmc;freertos;heap;idf_test;json;libsodium;mdns;newlib;openssl;soc;spiffs;ulp
BUILD_VERSION=0.9.99.999
PROJECT_VERSION=
######################################################################################
Building nanoFramework version using build type 'DEBUG'.
Source directory is 'C:/Projects/esp/EmbeddedProject5/EmbeddedProject5'.
Build directory is 'C:/Projects/esp/EmbeddedProject5/EmbeddedProject5/VisualGDB/Debug'.
Toolchain is ''.
######################################################################################
Configuring done
Generating doneHi,
Sorry for the confusion. We have rechecked the repro steps you mentioned and were able to reproduce them, however we also reproduced them when building the project from command line outside VisualGDB (using idf.py), so the problem is likely caused by some other difference between the 2 projects.
Please try building the modified “hello, world” project using the regular VS CMake interface. Does it still work as expected?
If yes, please try building the project manually from an MSYS2 shell using the CMake version from VisualGDB (under %LOCALAPPDATA%\VisualGDB\CMake) and then using the CMake version used by Visual Studio. If this produces different results, please let us know the CMake version used by the regular VS.
P.S. VisualGDB now officially supports CMake-based ESP-IDF projects. Please consider updating to v5.4 Preview 6.
Just wanted to share an update: we have added a CMake script debugger to VisualGDB 5.4 Preview 7, so you can easily step through ESP-IDF’s CMakeLists to quickly understand what is going on (see the announcement). In our experiments, the project() command is actually redefined by the IDF itself, in a way that does not use the VERSION argument. If it worked under the regular Visual Studio, you might have used a different ESP-IDF build that did not redefine it, or have patched it yourself.
- You must be logged in to reply to this topic.