Forum Replies Created
-
Posts
-
Sorry, the first issue looks like you are trying to debug an STM32 device that is not supported by OpenOCD yet. Ynfortunately, OpenOCD relies on a hardcoded list of STM32 device IDs in order to detect the FLASH parameters. ST usually contributes push requests to the OpenOCD repository providing the updates, and then our packaging system picks them up, but that typically takes a few months since a new device is released.
It is also hard to say why the external NOR FLASH driver would be failing. If it’s using our OpenOCD FLASH driver plugin system, we can suggest a few things to check. However if it is something that comes with OpenOCD, our best advice would be to build a debug build of OpenOCD from sources and try stepping through it in order to understand what is going on.
Another option would be to switch from ST-Link to Segger J-Link. It is more expensive than ST-Link, however it allows Segger to maintain and regularly update their own proprietary replacement to OpenOCD that does not have many of the USB driver issues known to OpenOCD and also typically introduces support to new devices much faster than open-source tools like OpenOCD. VisualGDB supports both OpenOCD and the Segger J-Link debug stack the same way, so simply select J-Link in the Debug Settings once you plug it in and VisualGDB will switch the existing project to use it.
Arduino libraries use a rather specific sematics (including one header file automatically pulls the entire library) and hence only work out-of-the-box with the Arduino project builder. This is fully supported and works out-of-the-box when using the Arduino Project Subsystem.
The ESP-IDF projects are based on a different framework that is not 100% compatible with the Arduino ecosystem. It is possible to add the Arduino core to ESP-IDF projects because Espressif has specifically designed their ESP32 core to be both a valid Arduino core and a valid ESP-IDF component that can be imported into ESP-IDF projects. This does not mean that any Arduino library can be automatically added to ESP-IDF projects without any adjustments, because the ESP-IDF build system is still different from the Arduino build system.
In order to import an Arduino library to an ESP-IDF project, it needs to be manually converted to an ESP-IDF component. Once you have performed the conversion, you can add the component to the project by selecting Add->Existing Item in Solution Explorer->Project->Components.
Sorry, if you need help understanding the role of libraries and components in ESP-IDF projects, please contact Espressif for further support.
We can help you locate specific VisualGDB settings that correspond to specific properties of the components, however we are not able to offer help understanding the inner workings of ESP-IDF or other 3rd-party frameworks that are not directly maintained by us.
Hi,
The “debugging exited without any breakpoint hits” error was caused by incorrect propagation of CMAKE_C_FLAGS that might got cached on your side. Please try deleting the entire VisualGDB\Debug directory and rebuilding the project.
If the breakpoint still doesn’t work please try hardcoding asm(“int3”) in the main() function to trigger an unconditional breakpoint. If the breakpoint triggers, but the source code is not shown, please double-check that the build.ninja file contains the -g”, tine FLAGS statement for the main file, e.g.:
build src/CMakeFiles/openocd.dir/main.c.obj: C_COMPILER__openocd ../../src/main.c || cmake_object_order_depends_target_openocd FLAGS = -std=gnu99 -Werror=incompatible-pointer-types -g -DPKGBLDDATE=\"2019-10-08\" -DRELSTR=\"\" -DGITVERSION=\"\"Hi,
Although we have not specifically checked the inner workings of Simplicity Studio, the AXF extension does typically correspond to the regular ELF files.
Indeed, you can override the file extension via VS Project Properties, although due to the internal VS limitations the default extension needs to be the same for all project types, hence we picked the Linux-style empty extension as the default.
The “-g” option should normally not affect the linking and is only used during compilation, hence VisualGDB does not pass it to the linker. You can override this behavior via VS Project Properties -> Linker -> Command Line.
That said, the VisualGDB-level command line you mentioned is missing a linker script (the .ld file) that should be normally picked automatically once you select a device in the VisualGDB wizard. If this is a manually created stand-alone project, please ensure you have a linker script specified on the first page of VisualGDB Project Properties (and also ensure you have the -mcpu, -mfpu and -mfloat-abi passed to the linker as well, as those options affect the type of the pre-built standard C library used to link the executable).
Hi,
Sorry, the fully automatic renaming of the ESP-IDF projects is not yet supported. Hence, you would need to edit the Makefile (or CMakeLists.txt file if your are using CMake) in your project directory manually in order to rename the project. Simply search for the project name in that file, replace it and save the file. VisualGDB should automatically reload the project structure and show the new name.
Hi,
For Arduino projects please use the first page of VisualGDB Project Properties to manage preprocessor definitions and other global options.
For ESP-IDF projects please use the VS Project Properties of a specific ESP-IDF component to define exported preprocessor macros (those macros will apply to all components in a project, not just the selected component). You can access the properties of the main component via the Properties command for the project node itself.
Hi,
ESP-IDF projects do not use automatic library discovery like Arduino ones and require the libraries to be wrapped as ESP-IDF components. You can read more about the components in the ESP-IDF documentation. Once you get an understanding of the component structure you need for your project, simply use VisualGDB’s Add New Item command in the component list to create the necessary components.
Hi,
It is still on the roadmap, however it is hard to give any estimates currently, we are prioritizing a few other features over it, sorry.
Thanks for the repro. We have added this to our investigation queue, however due to the current amount of investigated issues and their priorities, it may take 2-4 weeks to fully process this.
Hi,
The .axf extension is used by the Keil compiler for the ELF files. VisualGDB follows the Linux naming convention for the built files, hence the ELF files it produces have no extension. I.e. you can find an equivalent of the AXF file for your project under the following path:<Project Directory>\VisualGDB\Debug\EmBGM13P22F512GA_Test01.
The .rsp files are used to pass the command lines of the tools, avoiding the Windows command line length limitation of 8192 characters. They do not contain any code or symbols on their own.
Sorry, it looks like you did not add “VERBOSE=1” to the GNU Make command-line arguments (see our previous reply), hence Make did not dump the gcc command lines.
Please try adding it as suggested and share the updated log that should include the exact gcc command lines used to build the code.
Hi,
Yes, simply use the Advanced Mbed Project Subsystem and you should be able to use the latest mbed version out-of-the-box.
Unfortunately, it’s hard to suggest anything specific without knowing the exact steps to reproduce the problem.
Please describe the steps required to reproduce it, starting from creating a new project (see this page) and we should be able to suggest what is going on.
Hi,
The easiest way to achieve this would be to use the CMake-based projects and add the following constructs to the CMakeLists.txt files:
if (CMAKE_BUILD_TYPE EQUAL "DEBUG") set(CONFIG_SPECIFIC_MACROS CONTROL2) endif()
and then simply add ${CONFIG_SPECIFIC_MACROS} to the regular list of preprocessor macros via VS Project Properties. This will affect both build and IntelliSense.
If it doesn’t work, please let us know and we will help you configure everything.
