[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?

[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?

 

[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?

 

[Author]

Posts