ESP32/Arduino problems

[pdpruyne@gmail.com]

Trying to try out VisualGdb.  Tired of arduino/platformio, looking to find a real dev environment for microcontroller software development, ESP32’s.

I am professional developer, longtime VisualStudio user, win11pro, vs2022.  Just downloaded and installed VisualGdb.   My immediate goal: get the debugger running.

Throughout this, when informed “You don’t have XXX installed, Install it?” I always picked Install, saw no errors reported, was allowed to proceed after each install step.  Anything un-mentioned below, was left at its supplied default.

————————————

Thought I’d start with something easy, this is what happens, tried a couple of rounds, same same:

1. picked “new arduino project”
2. (Project Type)    picked “create a new blinking led project”
3. (Arduino Device)   picked  “Nologo ESP32C3 Super Mini” ,  picked “Com 25”
4. (Debug Method – Debug using)
   1. from Usb Devices list, picked  “usb-ESP32S3/ESP32Cx built-in JTAG”
      1. (Debug Method – Test)  Fails with pop-up, “USB Composite Device does not appear to have WinUSB driver installed.”  That is correct.  Abandoned path, been down zadig ratholes before.
   2. from Debug Methods list, picked “OpenOCD”
      1. (Debug Method – Test)  Test Works!
5. Picked finish

Presto, looks good, a project, a source file.  I pick File/Save-All .

1. I notice banner “The currently selected Arduino platform produces binaries without debug information…”  I pick “Fix Build Settings”.  Momentary progress bars, then banner disappears.
2. I select Build, project builds ok.
3. I hunt around, find “Program FLASH Memory”, works fine, board starts blinking.  Sweet!
4. Feeling bold, I try F5
   1. VS swaps into its debugging colors, the various debugging sub-windows appear
   2. Get a big pop-up  “Debugging failed”
      1. GDB Session output :Your VisualGDB trial expires in 30 days!
         C:\Users\pdp\AppData\Local\Arduino15\packages\esp32\tools\esp-rv32\2302\bin\\riscv32-esp-elf-gdb –interpreter mi “C:/Usr/Iot/SysProgs/ApBl1/Output/Nologo_ESP32C3_Super_Mini/Debug/ApBl1.ino.elf”
         -gdb-version 
      2. Exception details: VisualGDB version: 6.0.105.5243
         —————— le3+l2 ——————
         le3+l2: GDB session exited prematurely. Please verify that the project is built, the selected GDB binary exists and the working directory is specified correctly. If GDB reports an internal error, try updating GDB or erasing the target’s FLASH memory using external tools.
         at le3.q()
         at p63.t_2()
         at VisualGDB.GDBDebugEngine.x1(pa3 a, j1 b)
         trace=[le3.q:5068, p63.t_2:39, VisualGDB.GDBDebugEngine.x1:69]
      3. openocd details: Info : Listening on port 6666 for tcl connections
         Info : Listening on port 51087 for telnet connections
         Info : esp_usb_jtag: serial (7C:2C:67:D1:7F:B8)
         Info : esp_usb_jtag: Device found. Base speed 40000KHz, div range 1 to 255
         Info : clock speed 3076 kHz
         Info : JTAG tap: esp32c3.cpu tap/device found: 0x00005c25 (mfg: 0x612 (Espressif Systems), part: 0x0005, ver: 0x0)
         Info : [esp32c3] datacount=2 progbufsize=16
         Info : [esp32c3] Examined RISC-V core; found 1 harts
         Info : [esp32c3] XLEN=32, misa=0x40101104
         Info : starting gdb server for esp32c3 on 51089
         Info : Listening on port 51089 for gdb connections
5. Tried putting the board into “boot mode”, holding boot while pressing reset, same result

I followed the example here: https://visualgdb.com/tutorials/arduino/esp32/

My steps differ only in how the jtag is connected.  I feel like the successful debug-method test result validates the choices I made.  The successful flash programming, and the board-doing-the-blink, also argue that things must be pretty-close.

How should I proceed?  What have I missed?

[support]

Hi,

Please try running the gdb executable shown in the message (C:\Users\pdp\AppData\Local\Arduino15\packages\esp32\tools\esp-rv32\2302\bin\\riscv32-esp-elf-gdb) manually. Arduino package vendors sometimes forget to ship required libraries with their packages, leading to this type of error.

[pdpruyne@gmail.com]

Hi.  Thanks for the quick response.

You got it first try.  That binary is indeed missing in that location.

Oddly, I find a binary (riscv32-esp-elf-gdb.exe) in 6 different paths.

The first in a directory structure installed by VisualGdb as part of the process of trying the steps in my post.

1. C:\SysGCC\esp32\tools\riscv32-esp-elf-gdb\14.2_20240403\riscv32-esp-elf-gdb\bin
2. C:\Usr\Espressif\tools\riscv32-esp-elf-gdb\14.2_20240403\riscv32-esp-elf-gdb\bin
3. C:\Users\pdp\.platformio\packages\tool-riscv32-esp-elf-gdb\bin
4. C:\Users\pdp\.platformio\packages\toolchain-riscv32-esp\bin
5. C:\Users\pdp\AppData\Local\Arduino15\packages\esp32\tools\riscv32-esp-elf-gdb\12.1_20231023\bin
6. C:\Usr\Ard15\packages\esp32\tools\riscv32-esp-elf-gdb\12.1_20231023\bin

1 & 2 are identical binaries.  5 & 6 are identical binaries.  3 is about the same size as the others, while 4 is 20-times larger.

I tried the quick&dirty trick of mklink to fix the issue, trying both symbolic and hard links.  No change.

I tried copying the binary in 5 to the specified directory, no change.

Tried running the copied executable in that directory with the –help option, got no output and a negative return value.  Tried the same thing with that same executable in its original dir, worked – got help output.

Concluded the executable is somehow chaining to other executables in it’s directory.  There are a whole set of versions there, from 3.3 to 3.12.  Copied ALL of them to the specified directory,.

Debugging “started” but output window pops the msg in red “Error erasing flash with vFlashErase packet”, followed by a warning message msg in yellow “Could not set a breakpoint on main. Step into a new instance will not work”

Deleted the copied set of executables.  Tried the single “large” binary in directory 4, same result, debugging starts and pops same error messages in output window about flash erase and breakpoint setting failures.

So, I conclude quick and dirty fixes are not enough.  Any suggestions on a “clean” fix?

 

[support]

Hi,

This is something for you to figure out. The Arduino package structure is not specific to VisualGDB and it’s not up to VisualGDB to fix it. You can ask on the ESP32 forum – there are likely others that encountered the same problem.

[pdpruyne@gmail.com]

Ok, I get it.  VisualGdb has requirements and they need to be met.

I have questions then.

I have previously installed the Arduino toolchain, and likewise for PlatformIO.   I gather VisualGdb locates a likely toolchain for it’s “Arduino” needs.

How is this done?   Is it looking in specific locations?   Is there a list of specific targets I should insure are present to avoid a recurrence ?

You speak of “Arduino package vendors”.  I guess I’m asking from which source should I be looking, and what version?  Is your reference vendor not github/arduino?

I also have installed the Esspressif-IDF toolchain and Eclipse based IDE.

During VisualGdb installation a new toolchain was put into \SysGcc.   This toolchain is identical to the Esspresif-IDF toolchain.

Do I need to retain the Esspressif-IDF/Eclipse-IDE installations to use the Esspressif project type added by VisualGdb?

If I acquire a full featured Arduino toolchain, how do I make VisualGdb aware of it?  If that is a re-install of VisualGdb, how does that affect the trial status?

 

[support]

The Arduino projects are completely separate from the regular ESP-IDF projects. You can read more about them here. The ESP-IDF projects are described here.

There is no need to reinstall VisualGDB – it checks for installed packages every time you start Visual Studio. Reinstalling it does not affect the trial status.

[pdpruyne@gmail.com]

In reading the link you provided about Arduino projects, I find this statement:

“The Arduino projects are built directly using our fork of the official Arduino Builder tool. The tool automatically manages various build parameters same way it does with the regular Arduino IDE. This ensures that the output of VisualGDB Arduino projects is equivalent to the files produced by the Arduino IDE.”

The failing command line is pointing into the toolchain installed by ArduinoIDE.  That seems in conflict with the statement above about a using a fork of the Arduino Builder Tool.  Can you explain?

[Aloysius_Pendergast]

Don’t waste your time. I recently had the same problem and sought help here. I think the guys here can’t solve the problem or aren’t interested in it. Unfortunately. Because VisualGDB has the potential to become the best IDE for ESP. It is based on a good foundation: Visual Studio. That’s much better than VIC or Eclipse. Everything works fine with the IDF framework. And six months ago, everything also worked with the Arduino framework under VisualGDB. Currently, it doesn’t. They blame the Arduino framework. However, they load the corresponding frameworks themselves, which then become incompatible with the other components. I wouldn’t buy the software until they fix it. As an alternative, I am currently using Visual Micro. Also not perfect, but it works.

• This reply was modified 1 day, 2 hours ago by Aloysius_Pendergast.

[support]

The trouble with the Arduino system is that every vendor (original AVR Arduino, ESP32, STM32, etc) ships their own packages. Often, new package versions fix some bugs from the previous versions and introduce some new bugs. Each of them has their own bug tracker, their own Github repository and their own community. So any work we put into resolving these issues will get completely obsoleted when the next package version comes out. Except, then we would get more requests for help, more issues to fix, and it would quickly snowball to the point where none of the work we do actually improves VisualGDB in the long run, and is quickly obsoleted by another update. We tried it before, we really did, and it’s just not viable, sorry.

What we can reliably offer is  convenient GUI and deep integration with VS. You can configure existing package paths and not download anything new. You can choose the framework versions to download. You can decide whether to upgrade or not. You can revert to the old version if the new one is not working. We provide the GUI for all of that, but we cannot take over the maintenance work done by the package vendors. If the latest ESP32 Arduino package has broken debugging on Windows due to some missing libraries, it will remain broken until Espressif releases a fix for it.

As for our builder fork, the only modifications we introduced is accurate dumping of all GCC command lines, so VisualGDB can offer best-in-class IntelliSense that is way more accurate than any other IDE that does not have access to the underlying command lines.

As for the other IDEs, if you can confirm that the same functionality (e.g. debugging) works with another IDE on the same machine with the same versions of all libraries/packages, etc., we can help you configure VisualGDB to match that setup. But we will ask you to narrow it down to specific command lines on your own.

[Author]

Posts