[gojimmypi]

I’ve made some progress on getting the emitted VisualGDB cmake command to complete without errors, at least from a command prompt.

For one, I needed to add 2 CMake config variables in the Build Settings GUI:

IDF_TARGET = esp32c3
CCACHE_ENABLE = 1

Next, I needed to add these environment variables:

SET IDF_CCACHE_ENABLE=1
SET IDF_PATH=C:\SysGCC\esp32\esp-idf\v5.0
SET IDF_PYTHON_ENV_PATH=C:\Espressif\python_env\idf5.0_py3.8_env
SET IDF_TOOLS_PATH=C:\Espressif
SET ESP_IDF_VERSION=5.0

And last, I needed to add these to the Path:

C:\Espressif\tools\xtensa-esp-elf-gdb\11.2_20220529\xtensa-esp-elf-gdb\bin;
C:\Espressif\tools\riscv32-esp-elf-gdb\11.2_20220529\riscv32-esp-elf-gdb\bin;
C:\Espressif\tools\xtensa-esp32-elf\esp-2022r1-RC1-11.2.0\xtensa-esp32-elf\bin;
C:\Espressif\tools\xtensa-esp32s2-elf\esp-2022r1-RC1-11.2.0\xtensa-esp32s2-elf\bin;
C:\Espressif\tools\xtensa-esp32s3-elf\esp-2022r1-RC1-11.2.0\xtensa-esp32s3-elf\bin;
C:\Espressif\tools\riscv32-esp-elf\esp-2022r1-RC1-11.2.0\riscv32-esp-elf\bin;
C:\Espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;
C:\Espressif\tools\esp32s2ulp-elf\2.28.51-esp-20191205\esp32s2ulp-elf-binutils\bin;
C:\Espressif\tools\openocd-esp32\v0.11.0-esp32-20220411\openocd-esp32\bin;
C:\Espressif\tools\ninja\1.10.2\;C:\Espressif\tools\idf-exe\1.0.3\;
C:\Espressif\tools\ccache\4.3\ccache-4.3-windows-64;
C:\Espressif\tools\dfu-util\0.9\dfu-util-0.9-win64;
C:\Espressif\python_env\idf5.0_py3.8_env\Scripts;
C:\SysGCC\esp32\esp-idf\v5.0\tools;C:\Python36\;
C:\Python36\Scripts;

What is the best method for modifying the path and environment variables for CMake in VisualGDB? I saw the documentation, but I don’t know exactly where to apply that. Before I go pecking them all in, is that the “User Variables” at the bottom of the config page?

btw – I tried simply adding a called to export.bat in the “before build”… but it does exactly that: before the build, but not before cmake.

Thank you.

 

[gojimmypi]

Hi.

Yes, I completely understand. That’s fair.

I’m still hopeful that I can get this working. 🙂

I have it working using idf.py, and this text seems to indicate it should be possible:

Any project that can be built via ESP-IDF tools, can also be built with VisualGDB

I’ve opened Espressif idf-installer issue #142 in the hope that someone has an idea for a solution.

[gojimmypi]

I also encountered this error with File-New Project:  I didn’t notice that the main() lived in a file with only a .c extension.

Can’t call C++ from a .c file, but oddly the compile error was on the target class file with the .cpp, not the main file.

Error Failed to compile IoT_BBQ_STM32.c. arm-none-eabi-gcc.exe exited with code 1
Error unknown type name 'class'
Error expected '=', ',', ';', 'asm' or '__attribute__' before '{' token

 

[gojimmypi]

After adding my support ticket regarding the Prerelease 1 ESP-IDF support I noticed this topic is fairly similar – in particular the  problem with include files. Although I too, am very interested in the Arduino library support, I’ve created a sample project showing that the include file feature is in general not working as intuitively as one might expect. For more info – see this sample on GitHub:

https://github.com/gojimmypi/EmbeddedProject8

Perhaps this is a feature request: to honor the Project Properties “Additional Include Files” – instead of adding as components? (although I’ve also not been able to successfully add the sample TestLibrary as a component, either.

[gojimmypi]

actually, I do know how to build them: the project builds fine in Linux. 🙂 As for Windows, I’ve been programming in Visual Studio a long time, but I’ve never once have taken a solution developed there – and compiled it from command line.  To take something like VisualGDB project in Visual Studio and compile that from command line, seems rather complex.  Addicted to IDE’s I guess. 😉  (not always a great thing to not understand the whole process when insulated with an IDE, I know).

If I had the ability to build this project on manually on Windows before import, well, I kinda would not need to import to Visual Studio. I do agree that would be useful. But I was hoping to avoid the hassle of setting up the toolchain since I thought that’s what VisualGDB import wizard would do for me.

It would be cool if VisualGDB helped with that import process, and used the toolchain specified in the wizard. But ya, I understand given an arbitrary makefile, that’s probably not a trivial process to convert. Too bad, as that would be really awesome.

fwiw – I was able to get Windows-based debugging working from VSCode (of all places!). I compile on Linux, use OpenOCD there, but connect using the VSCode GDB. It is really quite awesome:

https://gojimmypi.blogspot.com/2017/05/vscode-remote-debugging-of-embedded.html

VSCode shockingly does many of the debugging things that Visual Studio does (single step, hover text for variable values, intellisense, peek definition, and more)

Cheers

[gojimmypi]

Hi.

That sounds like a good suggestion. Could you give a little more detail on just how to do that? I guess I’ve grown so used to Visual Studio IDE right-click builds, that I’ don’t know how to do it manually from command-line. I went back to a known-good VisualGDB project that works and compiles – and even there have not been able to figure out the command-line method. I tried simply “make” from the solution and project directories… that of course returned the same “make: *** No targets specified and no makefile found.  Stop.” error.

 

[gojimmypi]

Thanks for the verification. Hopefully Visual Studio 2017 will be fixed soon. In the meantime I tried your advice with Visual Studio 2015:

Microsoft Visual Studio Enterprise 2015
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.6.01586

It does not explode, but it also does not compile. I added a few new pics here:

https://gojimmypi.blogspot.com/2017/05/converting-opendps-to-visual-studio.html

The problem appears to be the config generated:  “make: *** No targets specified and no makefile found. Stop”

The resultant build config was “win32″… so I tried both creating an “ARM” as well as “VisualGDB” config, but no luck. I then tried to “convert to stand alone project”. As expected, no change to the missing make target.

I am not familiar with VisualGDB on manually setting make targets (I would have hoped the wizard would have done that for me).

I also tried the “Project – Add VisualGDB configuration – new Windows configuration” – resulting in “Creating Windows Configuration is only supported for Windows, Linux, and native visual c++ projects”

I’ve not been able to find any documentation or perhaps a tutorial on converting existing projects… could you kindly point me in the right direction? thanks 🙂

 

 

[gojimmypi]

Hi.

back to that “initial reason” for this new thread… 🙂  … Visual Studio crashes before conversion completion:

http://gojimmypi.blogspot.com/2017/05/converting-opendps-to-visual-studio.html

I tried 3 times – crashed each time. Also tried a 4th time importing from local copy on C:\workspace\opendps  rather than that Z:\ mapped to Ubuntu. Same result.

the actual conversion / makefile issues are duplicated in my other thread here:

https://sysprogs.com/w/forums/topic/visualgdb-and-externel-makefile/

Windows 10 Version 10.0.14393 Build 14393

Visual Studio Enterprise 2017 Version 15.1 (26403.0) Release

VisualGDB   5.2

edit: Note that this same result occurs on two different computers.

• This reply was modified 8 years, 5 months ago by gojimmypi. Reason: added not on use of two different computers

[gojimmypi]

fwiw – when I’ve seen the “fast blinking” – it is because the LED shares GPIO with Tx/Rx on some devices and the device is in a reset loop. Try hooking up a serial port at 74880 baud and see if the ESP8266 is spewing reset errors. Errors are typically because of bad code, bad settings such as memory size, etc.

[gojimmypi]

(I don’t know why I can sometimes edit my prior posts, and sometimes not).

In case someone wants to do something similar:

start OpenOCD (in this case using JLink and stm32f100):

sudo openocd -f /usr/local/share/openocd/scripts/interface/jlink.cfg -f /usr/local/share/openocd/scripts/target/stm32f1x.cfg

launch GDB:

/usr/bin/arm/bin/arm-none-eabi-gdb -d ./ -f ~/workspace/STM32-ST7735-standalone/VisualGDB/Debug/STM32-ST7735

then from (gdb) prompt, select elf file (no elf extension!) and connect to OpenOCD port 3333:

file ~/workspace/STM32-ST7735-standalone/VisualGDB/Debug/STM32-ST7735
target remote localhost:3333

 

[gojimmypi]

actually, disregard: I found that the “.bin” is not the file to use… rather the same-name, no extension file:

gojimmypi@ubuntu:~/workspace/STM32-ST7735-standalone/VisualGDB$ /usr/bin/arm/bin/arm-none-eabi-gdb -d ./ -f Debug/STM32-ST7735
GNU gdb (GNU Tools for ARM Embedded Processors 6-2017-q1-update) 7.12.1.20170215-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type “show copying”
and “show warranty” for details.
This GDB was configured as “–host=x86_64-linux-gnu –target=arm-none-eabi”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/&gt;.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/&gt;.
For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from Debug/STM32-ST7735…done.

This helped:

C:\SysGCC\arm-eabi\bin\arm-eabi-readelf.exe -a STM32-ST7735

 

[gojimmypi]

Apparently VisualGDB has changed in the last 4 years since the original post… 😉

I first tried a manual import (it did not go well) before discovering there’s a Wizard.

I am trying to import this STM32F100C8 project:  https://github.com/kanflo/opendps however steps listed above are a bit different now. I use “Import preserving directory structure” after selecting the directory containing the source. The next screen is selecting the debugger (I am using ST-LinkV2)… and no other options.

The project is imported apparently successfully, however in the libopencm3 there are multiple files by the same name and different directories – which are selected at compile-time by defining the target processor. But VisualGDB gives a bunch of errors like this one:

Warning  libopencm3/lib/dispatch/vector_nvic.c, libopencm3/lib/efm32/g/vector_nvic.c, libopencm3/lib/efm32/gg/vector_nvic.c, libopencm3/lib/efm32/lg/vector_nvic.c, libopencm3/lib/efm32/tg/vector_nvic.c, libopencm3/lib/lm3s/vector_nvic.c, libopencm3/lib/lpc13xx/vector_nvic.c, libopencm3/lib/lpc17xx/vector_nvic.c, libopencm3/lib/lpc43xx/m0/vector_nvic.c, libopencm3/lib/lpc43xx/m4/vector_nvic.c, libopencm3/lib/sam/3a/vector_nvic.c, libopencm3/lib/sam/3n/vector_nvic.c, libopencm3/lib/sam/3s/vector_nvic.c, libopencm3/lib/sam/3u/vector_nvic.c, libopencm3/lib/sam/3x/vector_nvic.c, libopencm3/lib/sam/d/vector_nvic.c, libopencm3/lib/stm32/f0/vector_nvic.c, libopencm3/lib/stm32/f1/vector_nvic.c, libopencm3/lib/stm32/f2/vector_nvic.c, libopencm3/lib/stm32/f3/vector_nvic.c, libopencm3/lib/stm32/f4/vector_nvic.c, libopencm3/lib/stm32/f7/vector_nvic.c, libopencm3/lib/stm32/l0/vector_nvic.c, libopencm3/lib/stm32/l1/vector_nvic.c, libopencm3/lib/stm32/l4/vector_nvic.c and libopencm3/lib/vf6xx/vector_nvic.c share the same object file name (VisualGDB/Debug/vector_nvic.o). This will result in link-time errors. Please rename the files or change the object file names for them. opendps-import C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\gcc.targets 82

as well as a few of these errors:

Severity Code Description Project File Line Suppression State
Warning   ISO C99 requires whitespace after the macro name opendps-import c:\workspace\opendps-import\opendps-import\<command-line> 1
Error   stm32f1xx_hal_conf.h: No such file or directory opendps-import C:\Users\gojimmypi\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32F1xxxx\STM32F1xx_HAL_Driver\Inc\stm32f1xx_hal.h 48

Should this project import work? Perhaps I am not doing this correctly? Any suggestions would be greatly appreciated. 🙂

Thanks in advance…

 

 

[gojimmypi]

I’ve not used the ESP-IDF command-line, nor have I been able to find it for the ESP8266. Is it the same as this one for the ESP32? This one:

http://esp-idf.readthedocs.io/en/latest/windows-setup.html

The GitHub repository also only mentions the ESP32:

https://github.com/espressif/esp-idf

[gojimmypi]

Greetings –

Any change in the status of debugging something like say – the ESP8266 written with the Arduino toolchain app, such as those created in VisualMicro (which has very poor debugging)?  VisualGDB is an awesome product with a cool debugger, but a real bummer to not be able to use any of the Arduino code for the ESP8266.  So many of the cool libraries for displays, sensors, etc… are written for the Arduino core for ESP8266:

https://github.com/esp8266/Arduino

I could perhaps understand not supporting the Arduino *hardware* at this time (different processor and all) – but as the ESP8266 GDB support is there in VisualGDB, it would seem only a toolchain config to get VisualGDB working with ESP8266?

This may only be a fraction of your users now – but I suspect you’d have a whole new, larger audience once debugging Arduino libraries (and even hardware) was supported.

Feature Request, please! 🙂

 

 

[gojimmypi]

aha! very cool. So that’s not a VisualGDB project property, rather simply a Visual Studio one:  Select Project (Right-Click) Properties;

Configuration Properties; c/c++; Preprocessor

Pasted on the end line this:

%(ClCompile.PreprocessorDefinitions);DEBUG=1;DEBUG_DEFAULT_INTERRUPT_HANDLERS

and so now when I simply run, there’s a new automatic breakpoint here:

void __attribute__ ((weak)) SysTick_Handler() 
{
 //If you hit the breakpoint below, one of the interrupts was unhandled in your code. 
 //Define the following function in your code to handle it:
 // extern "C" void SysTick_Handler();
 asm("bkpt 255");
}

…complete with suggestion as to what to do; indeed the code in my specific case seems to have not properly implemented some sort of delay / interrupt initializer.

very cool @Sysprogs finding stray #C/#C++ undefined interrupts #VisualGDB complete with code suggestion https://t.co/PZA5BYwJPq pic.twitter.com/r0xF0TA8xB

— gojimmypi (@gojimmypi) March 26, 2017

That’s a very cool feature of VisualGDB  🙂

 

 

 

[Author]

Posts