[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 7 years, 6 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  🙂

 

 

 

[gojimmypi]

Aha! Thanks for that information. I did not know you folks even had such a tool. Apparently it is a separate download / install from the VisualGDB add-in:

http://visualgdb.com/UsbDriverTool/

As a feature request, perhaps you could put that information in the “Try installing it now?” dialog box. Having instructions on how to then roll back after the drivers are changed would be really helpful. (and in my case, would have saved hours of frustration trying to get the Segger utilities working again)

Additionally, just for completeness of this topic and the benefit of other that may come looking: the folks at Segger pointed out to me that there’s yet another cool Sysprogs Tutorial that uses the Segger GDB Server rather than needing to change the OpenOCD USB drivers:

https://visualgdb.com/tutorials/arm/stm32/

This is not just an STM32 device tutorial… as it also shows using the J-Link JTAG as a debug method rather than OpenOCD (see steps 9 and 10) thus no need to change the drivers for OpenOCD.

I had instead used this tutorial when first taking my J-Link for a test drive:

https://visualgdb.com/tutorials/arm/st-link/

It is unfortunate that so much really great information is somewhat “lost” in the tutorials. I would have never thought to look at that STM32 tutorial for alternate debug methods. Are there any plans for a wiki or other “all you ever wanted to know about VisualGDB” documentation? (or where: perhaps I’ve simply not found it)

In any case I added a supplementatory blog page on this topic:

http://gojimmypi.blogspot.com/2017/03/more-on-segger-j-link-and-visualgdb.html

Hopefully that might help others that encounter a similar problem. 🙂

Thanks again for your reply.

 

 

 

[gojimmypi]

oops, not the STM32 ST-Link Utility (that’s of course for the ST-Link/V2 debugger).  The tool I meant to say is the Segger J-Link Configuration tool for updating firmware on the J-Link

(this pesky forum – sometimes I can edit prior posts and sometimes not)

[gojimmypi]

If not a wiring problem – I wonder if perhaps the problem may be old firmware on the J-Link. See the line:

Info : J-Link ARM V8 compiled Nov 28 2014

When I first installed my J-Link, I ran the Segger STM32 ST-Link Utility and it wanted to update my firmware before even trying to use it. Here’s the result of my selftest:

C:\SysGCC\esp32\esp32-bsp\OpenOCD\bin\openocd.exe -f interface/jlink.cfg -f target/esp32.cfg -c “adapter_khz 3000”
Open On-Chip Debugger 0.9.0 (2016-11-21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport “jtag”. To override use ‘transport select <transport>’.
adapter speed: 3000 kHz
Info : No device selected, using first device.
Info : J-Link V10 compiled Jan  9 2017 17:48:51
Info : Hardware version: 10.10
Info : VTarget = 3.348 V
Info : clock speed 3000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32.cpu0: Target halted, pc=0x400D4492
Error: The ‘mww’ command must be used after ‘init’.
in procedure ‘init’
in procedure ‘ocd_bouncer’
in procedure ‘flash’
in procedure ‘ocd_bouncer’

Info : esp32.cpu1: Target halted, pc=0x400D0BB0
Info : accepting ‘telnet’ connection on tcp/4444
shutdown command invoked
Info : dropped ‘telnet’ connection

btw – coincidentally I’ve been working on the ESP32 today. It is shockingly easier to JTAG than the ESP8266.  I created my own pinout diagram and posted all my notes (including ESP32 hookup) here:

http://gojimmypi.blogspot.com/2017/03/jtag-debugging-for-esp32.html

Let’s see if this tweet shows up as a hookup pic:

https://twitter.com/gojimmypi/status/842882252866441216

Hope this helps…

 

[gojimmypi]

Yes, that worked! Thank you.  I completely uninstalled VisualGDB, rebooted and installed fresh; VisualGDB now operational in both Visual Studio 2015 and 2017.  🙂

 

 

[gojimmypi]

We will consider making a crowdfunding campaign to fix the common annoyances of the open-source ESP8266 debug tools (gdb/OpenOCD)

Sign me up!!! 🙂

https://twitter.com/gojimmypi/status/836022626665422848

 

[gojimmypi]

Yes, I’ve tried using the bootloader mode when attempting to program via JTAG, even though there was no prompt as with the GDB stub method. I’ve still not yet been successful. Given the nature of JTAG, I wasn’t really sure if this was needed or not.

fwiw – I recently tried VisualGDB with an STM32 device (specifically the STM32F103c8 found in the Smart V2):

http://wiki.stm32duino.com/index.php?title=STM32_Smart_V2.0

my setup / result pics here:

https://twitter.com/gojimmypi/status/835449862497849344

wow! It was amazingly simple to setup and debug! I’ve spent a huge amount of time trying to get this to work with the ESP8266… and just minutes with the STM32, following this OpenOCD tutorial (but with Segger J-Link, instead):

https://visualgdb.com/tutorials/arm/st-link/

I really hope you folks can get the ESP8266 (and ESP32) information you need from Espressif folks to make ESP8266 debugging as easy and robust as you’ve done with STM32.  (hard to beat a full SOC IoT device with WiFi for as little as 3 bucks).

So between this success, and the really impressive remote debugging that I was able to get working from Visual Studio to Raspberry Pi… well, VisualGDB is awesome!  🙂

[Author]

Posts